Open stephendade opened 2 years ago
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:
- 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
- set SIM_ADSB_COUNT = 5 on one of the vehicles
- Set ADSB_TYPE=1 on all vehicles
- 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 .
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?
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 thatstatus ADSB_VEHICLE
is showing a rapidly increasing number of packets receivedThis 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