ModalAI Forum

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.

Also, there are many good simulators out there.

What software versions are you using? Can you please create a PX4 log and share that via https://logs.px4.io/? Since logging normally doesn't start until you arm the drone you can force the logger to start and stop. For example, from the adb shell you can use px4-logger on to start a log and then px4-logger off to stop the log. Can you also paste the outputs from the detect / scan? Also review this other post: https://forum.modalai.com/topic/4833/throttle-doesnt-work/7

You can use a UART on J18 / J19 to connect to the external flight controller. This is an option with the voxl-mavlink-server application. It will use the qrb5165-io library to connect to the external flight controller via one of the DSP mapped UARTs. That would then free up the UART on the board connected to J3.

We don't have any experience with those radars so it's hard to make any kind of recommendation. PX4 has no native driver support for those so it's likely you would need to create your own SW to interface with the radars and process the incoming data. You could then generate Mavlink OBSTACLE_DISTANCE or DISTANCE_SENSOR messages to send to PX4. Codex recommends using only USB for these radars.

The Commando 8 user manual is available online

Did you do a short press followed by a long press?

What if you disconnect Mission Planner before trying the voxl-ardupilot restart?

Can you try upgrading to the latest VOXL SDK to see if that helps?

I do not have a Windows computer handy so cannot really try Mission Planner. I tried to recreate this with QGroundControl but don't see it. Can you try with QGroundControl just to see what happens? Does it look like the 'systemctl restart voxl-ardupilot' is working reliably?

I think you need to keep BAT1_SOURCE set to 0.

This is what Codex says:

The root cause is a PX4 source-enum bug, not the ESC, baud rate, or VOXL_ESC_PUB_BST.

  - The supplied parameters select BAT1_SOURCE=2, meaning “ESCs”: /home/modalai/development/log_debug/no-batt-status/
    vehicle.params:5.

  - But voxl_esc constructs its battery object as BATTERY_SOURCE_POWER_MODULE (0): src/drivers/actuators/voxl_esc/
    voxl_esc.cpp:51.

  - The battery library publishes only when the driver’s source equals BAT1_SOURCE: src/lib/battery/battery.cpp:172.
  - Therefore 0 != 2, and every battery report is silently suppressed.

  This matches all the evidence:

  - VOXL_ESC_PUB_BST=1.
  - All four M0138 channels, including current-sensing ID 2, communicate at 2 Mbaud: /home/modalai/development/log_debug/no-
    batt-status/output.txt:279.

  - The flight log contains 232,935 healthy esc_status samples but no battery_status.
  - The forum test showed ID 2 reporting BOARD_VOLTAGE and BOARD_CURRENT, proving the ESC produces the special telemetry
    packet. This is the expected M0138 behavior documented in the ModalAI ESC FAQ (https://docs.modalai.com/voxl-escs/faq/).

  The proper code fix is one line:

  _battery(1, nullptr, _battery_report_interval,
           battery_status_s::BATTERY_SOURCE_ESCS)

  As an immediate workaround with the existing binary, set BAT1_SOURCE to Power Module (0), leave POWER_MANAGER=none, restart
  voxl-px4, and check:

  px4-listener battery_status 5

  That should publish, although the resulting topic will incorrectly identify its source as a power module. The one-line source
  change is the permanent fix.

Can you try setting that parameter and see if it works?

File:
output.txt

I sent an email to the address you have linked to this account.

Okay, shoot, let me see if we can get that fixed.

The forum won't let you attach it in your reply?

Can you upload the log file to https://review.px4.io/ and then send the link?

Also share the output.txt file after running this: journalctl -u voxl-px4 -b --no-pager > output.txt