MAVLink Router extension for forwarding a subset of messages

Blue Robotics Software
1

When trying to forward MAVLink messages from my boat to all my other vehicles I ran into an issue: if I just added a broadcast client endpoint on my boat that sent data to a server port on all my ROVs, my ROVs would suddenly think they are boats! I’m not sure if this was just a visual bug or what, but their displayed ID would switch rapidly between my Boat’s ID and their own correct ID. They’d also show a full GPS fix despite not having a GPS. I think all this had to do with receiving heartbeat messages from two vehicles. Regardless, this was inconvenient and I needed a fix.

Fortunately, MAVLink Router comes with tooling to address this issue. By only forwarding messages that I care about (including GPS position and battery level, and excluding HEARTBEAT), this issue is easily resolved. I made a docker container that runs MAVLink Router with a file that limits what message IDs from my boat it forwards to the ROV. This both saves bandwidth and prevents the sending of confounding HEARTBEAT messages.

Instructions on how to use are in the README.

2

Hi @SamH

I think the issue you encountered was that multiple vehicles had the same ID or component IDs - here is what is default on a BlueROV2:

image
image1456×1482 405 KB

You may be better off doing targeted endpoints rather than broadcast, in general? You’re likely disabling the default Mavlink router? Have you tried Mavlink Server, which is default on newer versions of BlueOS? It may be possible to configure it to achieve your goals more directly…
Glad you found a solution that works!

3

I’m certain the system ID’s are distinct. One vehicle is of ID 10 the other has 11. The messages definitely have the same component IDs though. No easy way to fix that :/. Though, in theory, shouldn’t that not matter so long as the fully-qualified (SYSID + Component ID combo) addresses are distinct? If it’s worth anything, I’m testing this on my simulation cluster, so it’s the SITL autopilot. I don’t think that should change anything.

The reason I went with MAVLink Router as opposed to MAVLink Server is that Router comes with an option for message filtering by message and source ID. I don’t want to saturate my wireless connection to the boat with a bunch of IMU messages!

I’ve found (after posting of course) that this extension does not entirely work as expected. While it prevents the system IDs from getting swapped, each Autopilot treats the messages sent by the other (including ATTITUDE and GLOBAL_POSITION_INT) as its own in the EKF. This–of course–causes each vehicle’s EKF to totally destabilize.

The messages are routed cleanly and show up under their own system IDs. Here’s MAVLink2Rest on the Pi simulating a ROV. The simulated ROV has an ID of 11, and the simulated boat (running my extension) has a simulated ID of 10.

image
image700×1079 240 KB

Looking at the MAVLink Inspector graphs for the ATTITUDE topic, it seems like the individual streams are not conflated at the MAVLink level. The steam from systems 10 and 11 show different, unmixed data. The Autopilot is just eating both of them for some reason.

While writing this response, I think I’ve figured out what’s going on and I’m not thrilled about it. Referencing the Ardupilot documentation, specifically [the detailed theory of MAVLink routing]( MAVLink Routing in ArduPilot — Dev documentation ) we see the following:

image
image557×285 30.9 KB

The ATTITUDE and GLOBAL_POSITION_INT messages lack a target_system field, so Ardupilot eats them without regard to their origin. The ArduRover firmware has a SYSID_ENFORCE parameter which sounded really promising, but it unfortunately does not appear to work. Looking at the source, I cannot figure out why. Regardless, this option is not present at all in ArduSub.

I’d really love to keep MAVLink data routed over MAVLink with out any contrivances or repackaging, but that seems to be rather difficult under these circumstances. Maybe I can use custom message types, but those are a chore and a half in my experience. I might just have to write a little script to spit the GPS and attitude data over UDP.

Update: I think GLOBAL_POSITION_INT is harmless? It contains enough information to get my job done. Once I stopped forwarding ATTITUDE messages the situation seemingly resolved.