voxl-ardupilot crashing on mission planner reconnect

[Eric Katzfey]

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?

[Eric Katzfey]

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

[Eric Katzfey]

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

[Dan Jennings]

@Eric-Katzfey said:

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?

stemctl restart voxl-ardupilot does work, this is our normal solution for this issue. We don't use QGC, will have to install it to test.

@Eric-Katzfey said:

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

Mentioned this in my post, we've tried this, but it does not change the behavior.

@Eric-Katzfey said:

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

Right now we can't get the FLIR Hadron 640 to work on any other SDK.

[Eric Katzfey]

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.

[Eric Katzfey]

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.

[Alex Kushleyev]

@dan-jennings , I would be happy to help you with the Hadron Issues on newer SDKs. There were no changes to the Hadron (Boson + OV64B) functionaliy recently.

Please make a new post for this issue and provide the following details:

• which SDK is working and which SDK(s) are not working for Hadron
• detailed description of the issue, any useful info from camera server or dmesg?
• how is Hadron connected to VOXL2? which interposers and which VOXL2 camera port (J6, J7, or J8)
• please provide voxl-camera-server.conf that you are using
• please provide a list of sensormodule.bin and *so files in /usr/lib/camera

Thank you

Alex

[Eric Katzfey]

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

[Dan Jennings]

OK we weere finally able to track down the root cause.

We found that the autopilot will connect to mission planner even if the gcs static IP does not match the setting in the mavlink server config file. However if it doesn't match. voxl-ardupilot will crash on reconnnect after a reboot as described above. We were able to recreate this behavior on two dfferent drones and GCS computers.

We have a lot of different systems and windows does not like having different network devices configured the same way. This is how we ended up with misconfigured IP addresses.

[Eric Katzfey]

Ah, interesting, thanks for the update!