We’ve been having an interesting issue when trying to receive the MAVLINK_MSG_ID_ADSB_VEHICLE MAVLink message when using ArduPilot (mostly ArduPlane) and a Pixhawk.
We have a device that we want to receive the MAVLINK_MSG_ID_ADSB_VEHICLE message. Typically we plug that device into the Telem2 port of the Pixhawk. We have requested the data streams, and the ADSB vehicle will show up on the main GCS (Mission Planner) but frequently, according to our logs and the behavior of our device, the ADSB message will either initially show up in our logs, then suddenly stop, or not show up at all, which leads us to believe the message is not being sent via the Telem2 port. When testing with just our device plugged into Telem1, we have also occasionally seen the same behavior. We have tested multiple autopilot versions of both ArduCopter and ArduPlane. While ArduCopter seems to work more reliably, both exhibit the same issue where sometimes our device gets ADS-B messages, sometimes it doesn’t. The GCS seems to get the messages reliably.
In order to try to troubleshoot this as much as possible, we began diving further into the ArduPilot MAVLink documentation. The documentation says that messages sent to the autopilot should have the target system set to the system the autopilot is on, which typically defaults to 1. It does not actually say that the target component id should be set to the autopilot component id, but component id for the autopilot seems to usually default to one. It goes on to say the system id for the originating component messages should be set to the same as the autopilot but use a different component id, and that a value of 0 for the target system or component id is considered a broadcast id. Currently we set the target system and component id to 0, but have started experimenting with setting the target component and system ids to the same as the autopilots and the originating component id to 101 as a unique component id, and the originating system id as the same at the autopilot’s system id… It also says that “ground stations will not send command packets to a non-broadcast destination (sysid/compid combination) until they have received at least one package from that destination over the link. This is essential to prevent a flight controller from acting on a message that is not meant for it. For example, a PARAM_SET cannot be sent to a specific <sysid/compid> combination until the GCS has seen a packet from that <sysid/compid> combination on the link.” Because of this, we have also added sending heartbeats from our device with the more “correct” message ids, but this did not seem to affect any behavior.
Basically we are running out of ideas and are hoping the community here can give us some ideas on what could be the issue. We have come across this post: Mavlink dont receive ads-b command, but did not solve our problem. Thanks!