Topics created by Jetson Nano

Hi @Jetson-Nano
Thank you for your request regarding MTTF and reliability data for the listed hardware components.

At this time, we do not publish formal MTTF/MTBF values for these products. The primary reason is that these systems (VOXL2, ESC, Flight Controller V2, Front-End Board, and Camera Modules) are delivered as development platforms intended for user-defined integration, testing, and operation. In the vast majority of use cases, overall system lifetime is dominated by application-specific factors such as mechanical stress, environmental exposure, power integrity, and crash events rather than intrinsic electronic wear-out mechanisms. As a result, standardized MTTF/MTBF metrics are not representative or particularly actionable for these platforms.

That said, the underlying silicon and design heritage for these systems is derived from high-volume mobile and embedded computing applications. These components are built on technologies that are broadly characterized for long operational lifetimes under nominal conditions, consistent with industry expectations for modern semiconductor devices.

Additionally, portions of the broader technology heritage have been evaluated in demanding environments, including public programs associated with NASA JPL (e.g., Mars Helicopter which is our design heritage, and CADRE lunar rover initiatives). However, detailed qualification data and reports from those efforts and other non-public efforts are not available for external distribution.

From a reliability perspective, our hardware is designed and validated using standard industry practices, including:

Functional validation across operating voltage and temperature ranges Environmental and stress testing at the system level (i..e: we and our customers put our drones into very demanding scenarios) Design margining consistent with mobile/embedded electronics standards, oftentimes far exceeding industry norm Production screening and quality control processes and test screening

For applications requiring higher confidence in operational lifetime, we typically recommend system-level validation under the specific mission profile, including environmental testing (thermal cycling, vibration, shock) and power/load characterization representative of the end use case.

Hope this helps.

@Jetson-Nano , since we currently have no plans to do the MIPI integration of this sensor, you always have the option to use USB connection and voxl-uvc-server to publish images via MPA. You would need to check if the sensor supports the standard UVC interface and try it out...

Alex

@Jetson-Nano ,

We have not tried QVIO with Boson, it may work (but we can't really support that). The boson output is usually a bit fuzzy, so i am not sure how the feature detection will work, but it may be ok. Disabling FFC will definitely resolve the gaps in the frame feed, but disabling the FFC will also affect the Boson image quality, which may degrade over time.

If you wanted to use any USB (thermal) camera with VIO, you would just have to use voxl-uvc-server to publish the images to mpa, so that voxl-qvio-server can subscribe to them. The only issue is that the uvc interface does not provide accurate timestamp of the camera, but it may be ok just to use the time of arrival of the frame. QVIO does estimate the time offset between the IMU and camera, so as long as the timestamp is consistently captured, it should be ok..

Alex

@Alex-Kushleyev Could you please share the pinouts of the serial console port. I am not able to find it anywhere.

@Eric-Katzfey

Thank you for reverting back. I am trying to proceed with the same approach.
I am facing some errors while going with this approach , I am trying to debug them.

Another approach :-
I am also thinking to hardcode the joystick based turtle mode to the voxl_esc.cpp.
The manual control values will be monitored and once the value of the assigned button is clicked, the turtle mode will be enabled.
Do you think it is a good approach?

@Eric-Katzfey
hey,
I observed something while the above behaviour still persists.
The modem and the camera server is showing not running while checking through the inspect services command.
I do not know whether this is related to this issue, but the voxl 2 is rebooting after sometime, the reboot is not constant and I am not able to able to find the reason for the reboot. Can everything be related to each other.
I am using the Microhard modem

Screenshot from 2025-11-10 15-27-45.png

Screenshot from 2025-11-10 15-30-27.png

@Jetson-Nano Regarding question #1, Yes, you can attach an external FC over the UART.

Hi @Jetson-Nano
Here is our info for Doodle Labs support:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
Sorry it's buried in a cable page, but it makes the case clear (we think) how to support Doodle 🙂
b1fa4a9a-f883-4566-b3e2-ae9ab14b7264-image.png

regarding probing USB signals, unless you had a USB decoder on the scope, I do not think that will prove anything useful. You may be better off running usbview:
Windows:
USBTreeView by Uwe Sieber — uwe-sieber.de/usbtreeview_e.html
It shows enumeration hierarchy, configuration descriptors, endpoints, VID/PID, power requirements, etc.
Linux equivalent:
Use usbview — it’s essentially the same utility (GTK front-end to lsusb).

Hope that helps!

@Vinny Thank you for your valuable feedback.

I’ll keep the points you mentioned in mind while doing the bench testing.

@tom Thank you for the support.

@Vinny Thank you for reverting back, I will follow the steps you mentioned along with the ESD safe method.

@Eric-Katzfey thank you for reverting back, it was very helpful, i was able to get multiple streams.

@Eric-Katzfey I am using VOXL 2 to Flight Core v2 to VOXL FPV ESC, will this change affect any performance of the flight or any other abilities.

@Eric-Katzfey Thank you for reverting back, I am able to get the turtle mode working now, The error was due to the safety parameters, once i changed it to the FPV setup, it was working.

Once again thank you for the support. It was really helpful.

@Alex-Kushleyev Thank you for reverting back.

@Jetson-Nano you could just use the CPP mavsdk instance to grab the TOF data from a MPA pipe and then leverage that to do your controls via mavsdk (I am assuming just offboard movement). You can connect over port 14551 just ensure you have localhost comms set to true in voxl-vision-hub.