Hi all,
this post is a last resort after trying ton of things…
My simulation suppose to have 2 uavs by using two instances of ardupilot. Two different wp files are then to be uploaded and the missions to start.
So I start my simulation by using sitl -> sim_vehicle -I1 --aircraft test (+ sim_vehicle -I2 --aircraft test).
In the script I’ve also added the ‘–target-system $INSTANCE’ mavproxy option in order for each of the mavlink/mavproxy commands to be received by the appropriate instance/system.
So far so good. (P.S. the SYSID_THISMAV ids are different by changing parameter loading inside sim_vehicle also).
I have two custom wp plan files to be uploaded to each of the simulated planes. When I upload the first, no problem. When the second is uploaded, it rewrites the wp plan of the first… (I hope I’m getting my self clear…). Same thing happens if I reverse the order of course. I guess it has to do with the way the MAVLink routing works in ardupilot (dev.ardupilot.com/wiki/mavlink-r … ardupilot/) but I haven’t been able to work around this case.
I have the same problem when running multiples instances in Windows (what OS have you tried?). Apparently, they have different SYSID_THISMAV and use different ports.
The problem is that the last loaded plan (in my case from a QGCS) is broadcasted and the two instances perfom the same flight (sometimes in waypoint number 3 or similar).
no it’s still there and I’ve been running it on Linux (kubuntu 14.04).
There doesn’t seem to be any workaround (at least that I know of…)
Currently I’m dealing with some other issues so I could not dig deeper.
The only thing that I haven’t tried though, is using different clones for each SITL instance.
I think that if you change the SYSID_THISMAV after you’ve initiated the simulation, some bits in the whole procedure are left out (jargon here…)…
I was stuck on this problem for days. You have a few options:
Run your instances of SITL on separate machines (or one on a virtual machine) so the classes don’t get overwritten
Have one UAV in GUIDED mode and use MAV_CMD_NAV_WAYPOINT to send simple_goto commands
implement peterbarker’s multivehicle or avoidance mavlink hub in dronekit
The big problem here is that (a) that hasn’t been merged upstream yet, and (b) MAVProxy itself doesn’t use it. @tridge wants to see MAVProxy implemented in terms of this before looking more closely at it, and the first thing I found is that I would need to add multiple-link support into the mavsource class.
Ah great – I install Dronekit with pip, that would have the Tridge-fixed-pymavlink I imagine?
Which means I must be doing something silly on my end. I’ll look more into it in the morning and might post more. And I’ll hold off on my original plan which was to install a bunch more VMs…
