SITL multi-vehicle mission issue

[lamping7]

uav1: sys ID 10 | QGC on 14497 | mavros on 14493 | SITL_UDP_PRT 14490
uav2: sys ID 20 | QGC on 14597 | mavros on 14593 | SITL_UDP_PRT 14590

This is with slightly different model configs and different launch parameters than the iris with the provided multi_uav launch provided by PX4 to make the port values more clear. The above ports are shown to be true, from px4 at startup:

INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 14591 remote port 14597
INFO  [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14592 remote port 14593
...
INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 14491 remote port 14497
INFO  [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14492 remote port 14493

As QGC and MAVROS are interfaces to the same thing, the issue applies to both. This is in a ROS-based simulation.

This is interesting because the whole mission isn't getting set to that of the other vehicle. Rather, waypoint details are being over written. See the photo: uav2 only had 3 wps, so after uav1 hit uav2's 3rd wp, it went back to its own 4th wp

I tied with various version combinations of mavlink, mavros, sitl_gazebo, and px4. I didn't find a combination that performed as expected.

[lamping7]

It was proposed that dataman and rootfs be looked into. @dagar

[dagar]

I likely won't get to this for a few days, but we need a unique location for each instance's working directory ("rootfs").

[lamping7]

There's quite a bit of history on this and related topics. #5181 #5255 #5162

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lamping7]

I think this is still an issue.

[stale]

Closing as stale.

[lamping7]

@dagar Do we consider a change like this to address the problem? lamping7/Firmware@15325ff

[dagar]

That seems fine for now. Personally what I'd want to do is take a step back and figure out the full picture, then implement it cleanly top to bottom.

PX4 Linux (include SITL, raspberry pi, ocpoc, ROS 1&2 (catkin), multi vehicle sim, etc)

• where should px4 actually install? both local and system wide (packaging)
• where do the supporting install files go (airframes, mixers, etc)
• where does configuration and logging live?
  • this is the part that enables handling multi-sim cleanly
• bonus: process management (systemd)
  • packages for deploying to linux boards
  • Basis of package for PX4 simulation that could actually be quite important going forward. Thinking of Mavlink SDK developers or general end users. (@JonasVautherin)

[lamping7]

Agreed... All good questions for discussion. This is a quick and dirty solution, based off #9088. I'd rather not add the launch files you see that there in the commit link above. No need to add more to maintain. A doc showing that should suffice.

[julianoes]

Thanks for following up @lamping7. I've read this issue the first time and I have to say it's one of the funnier ones 😄.

[JoachimVeulemans]

I was having the same issue as #12444. I've created a Dockerfile, for quick and easy testing, where all the needed software is already installed. I thought that it might come in handy when someone wants to quickly test a solution for the presented problem described here.

The Dockerfile is available at PXLRoboticsLab/PX4_SITL_Docker. Feel free to create an issue when there is a bug or improvement needed.

[lamping7]

A fix is in the pr #12482

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[lamping7]

Closed via #12482