ModalAI Forum

Our upcoming SDK 1.8.0 will have a release 1.18 based version of PX4. The package we are testing with can be found here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.18.0-1.0.9-202610051650_arm64.deb. PX4 parameters are different in this release than the 1.14 based versions so that needs to be considered. Our voxl-px4-params utility has been updated for this already and will be part of SDK 1.8.0. Directly building the tip of mainline should also work although that hasn't been tested for a few months.

It is saying that your throttle is not at lowest position. Is that the case? Can you calibrate the RC in QGC and see all of the sticks moving as expected?

It's not really a priority for us at the moment but our platform is open and you should be able to adapt Crazyswarm2 to work with PX4. But there are no plans at the moment to design a new drone specifically for that use case.

Are you using Crazyswarm2, Bitcraze’s Python Swarm API, or another framework? And which positioning system are you using?

Yes, we have tested a few USB (UVC) cameras and they can continuously live stream. So we need to figure out what is causing the problem on your setup.

Please provide a PX4 log.

Most of this can be answered by our documentation here: https://docs.modalai.com/. If after reading through that you still have any specific questions feel free to reach out here on the forum. The short answer to most of your questions is "yes".

That's kind of pointing to VLC as the issue. Can you try with QGC?

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?

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?

Ah, interesting, thanks for the update!

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.

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.

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.

As far as I know no one has ever tried this. I don't think HITL is supported by ardupilot (was in the past) but there may be some sort of Simulation on Hardware (SoH) that you could try to get running on VOXL2. I'm guessing it wouldn't be easy.

I think ImmersionRC was bought by Orqa.

Yes, there is ground, power, and the transmit line from the receiver. The receive line to the receiver is not connected. But this is a 4 wire UART.

It shows that no bytes have been received over the UART. So you need to see why there are no bytes coming across. Is the receiver generating any? You can attach a oscilloscope to the transmit line from the receiver and see if it is trying to send anything. Are you sure that the receiver and transmitter are properly bound?

Looks like the px4- version of the command isn't printing anything. You'll need to stop px4 running as a service with systemctl stop voxl-px4. Then wait a few seconds. Then start voxl-px4 from the command line in non-daemon mode with voxl-px4 -d. Once the startup script completes and you get a px4 prompt enter qshell ghst_rc status.

Could you post a log of the drone flip?