How to Set Up Separate UDP Connections for Multiple Rovers in SITL Using MAVProxy?

Ground Control Software MAVProxy
1

Hello all,

I am running a SITL simulation with two vehicles using the latest ArduPilot Rover firmware on WSL2 (Windows 10 host).

I start the simulation with the following command:

sim_vehicle.py -v Rover -L nisaki --add-param-file=/home/thomas/ardupilot/parms/boat_parms.parm --map --console --count 2 --auto-sysid --auto-offset-line 270,60

my custom params file has only a frame_class=2 and a larger battery, nothing else.

This successfully launches two vehicles with IDs 1 and 2.

The initial output list in MAVProxy shows:

MANUAL> output list
MANUAL> 2 outputs
0: 172.21.176.1:14550
1: 172.21.176.1:14560

Here, 172.21.176.1 is the WSL address of the Windows host machine.

Goal: I want to set up separate connection strings within the WSL2 subsystem to connect independent Python scripts to each rover. Specifically, I want to assign 127.0.0.1:14550 to rover with ID=1 and 127.0.0.1:14560 to rover with ID=2.

I have tried various approaches for several hours without success and found no comprehensive documentation on this topic. The most promising attempt was using the following MAVProxy commands:

output sysid 1 127.0.0.1:14550
output sysid 2 127.0.0.1:14560

This seemed correct since the output command in MAVProxy has a sysid option to add new output for a specific MAVLink sysID. The command appeared to work, as indicated by the response:

MANUAL> output sysid 1 127.0.0.1:14550
MANUAL> Adding output 127.0.0.1:14550 for sysid 1

After running these commands, the output list updates to:

MANUAL> output list
MANUAL> 2 outputs
0: 172.21.176.1:14550
1: 172.21.176.1:14560
1 sysid outputs
1: 127.0.0.1:14550

However, right after adding the output, I get a “link 1 down” error in the MAVProxy console, and I’m unable to determine why. I’ve tried different ports, IPs, and other configurations, but the issue persists.

I’ve searched through documentation and forum posts (e.g., here and here), but haven’t found a solution or detailed guidance on how to achieve this setup.

To clarify, I want to run multiple rovers on the same SITL, view them on the same MAVProxy map, and have discrete connection strings for each rover to connect different Python scripts to them independently. I am obviously doing something wrong … this must be easily achievable.

If anyone has insights or suggestions, I would greatly appreciate your help!

Thank you.

2

That looks like a bug in MAVProxy.

I’ve replicated your issue - the main MAVProxy instance does indeed loose link. However, the output sysid <> links are correctly working. I’m getting the proper telemetry on each.

So MAVProxy is forwarding correctly, but it’s not consuming the packets itself. I’ll take a look later in the week.

3

Thank you very much for taking the time to replicate my issue answer. I really appreciate your help!

I will clarify a bit further on the problem, both to receive some help with what I am trying to do, but also because it might help identifying the issue.

Let me first explain my setup,

I run SITL within WSL2 on a windows 10 host. I mostly relied on mavproxy to interact with drones, but I have Mission Planner installed on Windows too. What I want to do, is to have two rovers on same sitl (same map) with reliable discrete connection strings to each, so i can experiment with some python scripts controlling both and trying some autonomous scenarios like ‘follow the leader’ etc.

Now, back to the connection issues. I experimented with adding another port when running SITL. So the initial command now is:

sim_vehicle.py -v Rover -L nisaki --map --console --count 2 --auto-sysid --auto-offset-line 270,60 --out=udp:172.21.176.1:16000

MANUAL> 3 outputs
0: 172.21.176.1:14550
1: 172.21.176.1:14560
2: 172.21.176.1:16000

When I fire up MP, it connects to 14550. I disconnect from it, and connect on port 16000. All is well, I can see/control rovers from MP.

As soon as I add a specific port for sysid=1, something like:

output sysid 1 127.0.0.1:14550

link1 goes down, but it also goes down in MP although I thought that would be separate from mavproxy’s outputs. Same of course happens when I add an output for sysid=2.

So I lose connection on both mavproxy and MP, and therefore although telemetry might still be sent on the sysid specific IP:PORT, it’s impossible to either control or monitor the vehicles through either mavproxy or MP.

So I guess the only solution I have is to run two independent SITL instances with different mavproxy each, give discrete output to each one, and then use python scripts for each rover but they will show on different maps … I cannot see a solution to have them both on same map, which was what I wanted…

Thanks again for your time.

EDIT: I think I kinda solved my situation for the time being. But I need to test further and will report here, so that it stays for someone who might need it in the future. I will then edit this reply to write the ‘solution’ more clearly.

I ended up running two independent SITL instances,

first:

sim_vehicle.py -v Rover -L nisaki --add-param-file=/home/thomas/ardupilot/parms/boat_parms.parm --map --console --out=udp:127.0.0.1:14550

second:

sim_vehicle.py -v Rover -L nisaki2 --add-param-file=/home/thomas/ardupilot/parms/boat_parms.parm --instance 1 --console --map --out=udp:127.0.0.1:14560 --out=udp:172.21.176.1:14550 --sysid=2

(param file is only for frame_class=2 and a larger battery. )

So both SITL rovers transmit to windows home pc address on port 14550 (first instance does it automatically, thats why i add it only for the second one), so both can be seen on MP. And they have discrete IP:PORTS on WSL2 localhost so I can interact with them independently via python scripts.

Its probably simple … but I am a beginner and it took several hours to find this ‘solution’…

Then I can connect

4

I’ve fixed your bug at Fix Sysid filtered output by stephendade · Pull Request #1443 · ArduPilot/MAVProxy · GitHub. See if that works for you.

5

Thank you very much for looking into this. I will look into this in the following next few days, when I have a little bit more time, and I will report here.