ModalAI Forum

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?

A drone immediately flipping over is usually caused by some combination of incorrect motor mapping, incorrect motor spin direction, and / or improper prop direction.

Yes, you can monitor the battery data. What did you want to do with it?

Yes, you can create custom code. Have you looked at our documentation? https://docs.modalai.com/voxl-sdk/

I was finally able to get to a Windows PC and try this. I still cannot recreate the issue. I can restart voxl-ardupilot with systemctl restart or via Mission Planner reboot pixhawk and in both cases I can disconnect and then reconnect Mission Planner to ardupilot. I am connected on VOXL2 to my local WiFi network via station mode. I have disabled all other services other than, essentially, voxl-ardupilot and voxl-mavlink-server. I am using recent VOXL2 SDK, recent ArduPilot build, and Mission Planner 1.3.83

Yes, you can connect to one of the UARTs on J19. However, there are only 3 UARTs so you'll have to choose which one to use. The PWM outputs on the IO expander are mainly intended to be used when you have PWM ESCs instead of a ModalAI UART based ESC. In that case you would connect to the ESC UART. If you want to use the IO expander in addition to a ModalAI UART based ESC then you will have to choose between the RC UART or the GNSS UART.

First of all I would update the SDK to something newer. That's probably not going to solve this issue but it makes it easier for us to support you when you are on the current SDK. To help troubleshoot can you show the output of px4-qshell ghst_rc status. Run that status command a few times.

Can you plug the cable from the working drone into the other one? That could tell you if it's the cable.

My only guess at this point is that it may be timing related. I would try each step, wait a long time, then try the next step. Maybe something is taking too long and the system is not yet ready for the next step. But that's just a guess.

I'll probably have to recreate this and then debug it. I won't be able to do that until I get back from travel the week after next. Here's something from Codex that you could try:

  With Mission Planner closed, add this to its config.xml:

  <UseMavFtpParams>False</UseMavFtpParams>

  Then restart Mission Planner and repeat the exact sequence. This forces the legacy MAVLink parameter protocol instead of the packed MAVFTP download.

  Interpretation:

  - Failure disappears: strongly implicates MAVFTP burst traffic and the QURT/SLPI backpressure path.
  - Failure remains: investigate the broader reconnect/SLPI lifecycle rather than MAVFTP specifically.
  - QGroundControl works consistently: also supports the Mission Planner MAVFTP-trigger theory, though it would not prove MP is defective.