ADSB: Message bouncing on multi-vehicle

[stephendade]

Bug report

From @peterbarker and myself.

When using mesh/multipoint networks in multiple vehicles, ADSB messages are continuously bounced between vehicles, due to each vehicle retransmitting ADSB messages.

To replicate in SITL: 1) Start a swarm where all vehicles can broadcast to each other: sim_vehicle.py -v ArduCopter --gdb --debug --map --console -n 5 --mcast --auto-sysid --auto-offset-line=90,10 -L CMAC 2) set SIM_ADSB_COUNT = 5 on one of the vehicles 3) Set ADSB_TYPE=1 on all vehicles 3) Notice that the ADSB vehicles don't disappear from the map and that status ADSB_VEHICLE is showing a rapidly increasing number of packets received

This occurs because AP_ADSB will automatically re-transmit any received ADSB_VEHICLE messages on all MAVLink interfaces, including the one it was received on. On any multicast or mesh-type network (such as a RFD900 multipoint setup) this re-transmission will occur, leading to ADSB_VEHICLE messages being continuously "bounced" between vehicles.

It doesn't quite lead to a message flood, as SRn_ADSB is still being honored.

However, the messages will continue to be bounced long after the detected vehicle in ADSB_VEHICLE has left the area. There's no timestamp check on the ADSB_VEHICLE message for Ardupilot to know how recent the ADSB detection is.

I suspect this will occur with AC_Avoidance as well, as it also transmits ADSB_VEHICLE messages.

The suggested fix is that ADSB_VEHICLE messages are not re-transmitted on the same interface that they were received on. And we need some sort of timestamp check on ADSB_VEHICLE messages to ensure we're not consuming old data.

Version master

Platform [ ] All [ ] AntennaTracker [ X ] Copter [ X ] Plane [ ] Rover [ ] Submarine

[WickedShell]

Won't you also get the problem that a retransmitted vehicle from anything else is older then the one observed locally? Without a timestamp it has very high odds of pushing it backwards. I'd argue in addition to not broadcasting out the link you received from you need a mask to say only accept vehicles from these ports. (Or a priority system to use your local observations before anything from the remote, with say a timeout)

On Sat, Nov 13, 2021, 14:37 Stephen Dade @.***> wrote:

Bug report

From @peterbarker https://github.com/peterbarker and myself.

When using mesh/multipoint networks in multiple vehicles, ADSB messages are continuously bounced between vehicles, due to each vehicle retransmitting ADSB messages.

To replicate in SITL:

1. Start a swarm where all vehicles can broadcast to each other: sim_vehicle.py -v ArduCopter --gdb --debug --map --console -n 5 --mcast --auto-sysid --auto-offset-line=90,10 -L CMAC
2. set SIM_ADSB_COUNT = 5 on one of the vehicles
3. Set ADSB_TYPE=1 on all vehicles
4. Notice that the ADSB vehicles don't disappear from the map and that status ADSB_VEHICLE is showing a rapidly increasing number of packets received

This occurs because AP_ADSB will automatically re-transmit any received ADSB_VEHICLE messages on all MAVLink interfaces, including the one it was received on. On any multicast or mesh-type network (such as a RFD900 multipoint setup) this re-transmission will occur, leading to ADSB_VEHICLE messages being continuously "bounced" between vehicles.

It doesn't quite lead to a message flood, as SRn_ADSB is still being honored.

However, the messages will continue to be bounced long after the detected vehicle in ADSB_VEHICLE has left the area. There's no timestamp check on the ADSB_VEHICLE message for Ardupilot to know how recent the ADSB detection is.

I suspect this will occur with AC_Avoidance as well, as it also transmits ADSB_VEHICLE messages.

The suggested fix is that ADSB_VEHICLE messages are not re-transmitted on the same interface that they were received on. And we need some sort of timestamp check on ADSB_VEHICLE messages to ensure we're not consuming old data.

Version master

Platform [ ] All [ ] AntennaTracker [ X ] Copter [ X ] Plane [ ] Rover [ ] Submarine

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/19241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKTCFQYGQOMZDS2BO3BEDUL3SCDANCNFSM5H7DQL4A .

[magicrub]

This is not good. There is always a timestamp of when it was received, but in sitl that's a local timestamp. In real hardware the tslc would be generated from hardware with a sane number and hopefully greatly reduce this. However, for SITL work this is surely a nasty thing. How have we not noticed this?