ModalAI Forum

Eric Katzfey

MIPI is the physical connection to the VOXL2 board. So, yes, the "normal hires camera" is connected via mipi instead of USB. I'm trying to help you debug this. Normally, when something doesn't work, you try to narrow down the issue by trying some carefully thought out variations to see what works and what doesn't. That can determine the part that is not working. For example, if you have USB camera -> voxl-uvc-server -> voxl-streamer -> Microhard -> VLC and that is showing problems and then you switch to a stream with MIPI camera -> voxl-camera-server -> voxl-streamer -> Microhard -> VLC and that doesn't have problems then it's logical to focus on the USB camera -> voxl-uvc-server part of the pipeline as the problematic part. In your first post you mention QGC stream works and then in your last reply you said you did not test with QGC so that is confusing. And I'm not sure what your end goal is. In the first post you say "Please help to stream live video from the lepton camera through the microhard board." Then you say that it is working from ffplay. So, is that okay now? Or is ffplay not an acceptable solution for you?

Eric Katzfey

I'm confused by all of the new data. Can you summarize? You have tested with 2 different USB cameras: Lepton and c270. You have tested with 3 viewers: QGC, VLC, and ffplay. You have tested with 2 applications: voxl-uvc-server and voxl-streamer. Only one network connection: Microhard. Can you also try a MIPI camera instead of a USB camera? Then can you create a matrix saying which ones worked and which ones didn't?

Eric Katzfey

Ah, interesting, thanks for the update!

Eric Katzfey

There are likely 2 issues here. One was a floating point math fix that is in newer versions of PX4. Can you update to latest px4: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb and try again? The other issue is that sending in trajectory setpoints from your external application, even when in altitude mode, will go straight into the position controller and affect flight. So, I would only send those in when in offboard mode.

Eric Katzfey

Those warning messages don't really signify dropped Mavlink messages, it's just a by product of two separate event numbering sequences between the DSP and the Linux processor.

Eric Katzfey

Have you attempted any trouble shooting? What if you stream a connected camera with voxl-streamer, does it still do the same thing? Did you try streaming over WiFi or Ethernet? Does the voxl-uvc-server generate any error or diagnostic messages? Can you try a different USB camera (non-Lepton)? I'd recommend trying with a Logitech C270.

Vinny

Hi @greg We have not investigated or researched that image sensor.
I do not know of any plans for us to officially support it at this point.
Sorry if this is not what you wanted to hear.

Vinny

Hi,
This post is quite old now, so going to mark it as resolved. If it is not, please start a new topic in the correct category for your needs.
Thanks!

Vinny

Hi @noah-heinen,

Thanks for the very detailed write-up and troubleshooting. There is a lot of useful information here, and this is a tough challenge. I hope we can help get it resolved with you.

The first thing that stands out to us is the custom extended-length USB harness between the Doodle Labs radio and VOXL 2 Mini. Before digging further into software, ESC firmware, or platform parameters, I would focus on that physical USB connection.

USB 2.0 High Speed is sensitive to cable construction and signal integrity. Extending the MCBL-00080 interface using discrete, untwisted, unshielded JST-GH conductors is not equivalent to extending it with a properly constructed USB cable. The added length also increases susceptibility to both radiated and common-mode noise, particularly in an electrically noisy environment such as a high-current multirotor.

We should also acknowledge that our standard development cables are not necessarily optimized for the highest-noise or final-production UAS environments. They are primarily intended to help get systems connected and operating during development. For final aircraft integrations, we generally encourage additional cable optimization where appropriate, including shielding, ruggedization, strain relief, and dedicated cable routing or cable channels that keep sensitive interfaces away from high-current and high-noise paths.

We have seen USB stability issues on aircraft when cabling and routing are not ideal, especially around ESCs, motors, and high-current battery wiring. The fact that your disconnects correlate strongly with motor current transients rather than steady-state current makes the custom USB harness and associated grounding/noise coupling particularly worth investigating.

I would recommend addressing the USB harness first:

Keep D+ and D- as a tightly coupled twisted pair and keep the run as short as practical.
Use a shielded USB-rated cable rather than individual discrete wires for the extended portion.
Adding shielding is absolutely a good approach here. Ideally, use the cable shield as a shield rather than simply adding another signal-ground conductor.
Keep the USB harness physically separated from ESC phase wiring, battery leads, and other high dI/dt paths.
Your plan to improve the ground path and experiment with ferrites is also reasonable, although I would first correct the basic USB cable construction before trying to solve the problem primarily with ferrites.

I would not assume there is a specific maximum J3 cable length where it suddenly becomes unreliable. Cable construction, impedance, routing, grounding, and the surrounding EMI environment all matter. A longer run made from discrete untwisted/unshielded conductors is certainly more susceptible than the stock harness, and yes, it could plausibly produce the transient-induced disconnect behavior you are seeing.

Moving the ESC bulk capacitor to the recommended location is also important, particularly on 6S, and I would still make that change. The improvement you observed when powering VOXL from a bench supply is another useful indication that conducted or common-mode noise may be contributing. There may be more than one coupling path here.

However, given the custom extended USB cable construction, I would correct that first and repeat your 0 -> 65% actuator transient test. That is actually a very good controlled reproduction test.

Vinny

Hi @dvz
It sounds like that specific unit may need to be RMA'd and we can give it a full check-out through our tests.
Please refer to this page for submitting an RMA, as there is not much we can do remotely given your assessments and noted behaviors.
https://www.modalai.com/pages/rma

ModalAI Forum

Qisda Forum

Posts

Member List