We’ve been having an interesting issue when dealing with receiving MAVLink messages when using ArduPlane and a Pixhawk 2.1 Cube.
We have a device that we want to use essentially as an additional GCS. We want it to have the ability to receive all MAVLink messages and be able to send some MAVLink messages back as well. Typically we plug that device into the Telem2 port of the Pixhawk, but we do have some test devices plugged into Telem1. We are definitely observing a difference in functionality on the two different ports. Telem1 seems to receive MAVLink messages reliably and at the requested rate, but Telem2 does not always receive it reliably. Sometimes we do not receive messages at all on Telem2, and when we do, it usually does not come in at as high of a rate at Telem1. We have seen cases where even heartbeats are not received. We have tested multiple autopilot versions of both ArduCopter and ArduPlane. ArduCopter seems to generally work reliably, while ArduPlane gets different results. To experiment further, we plugged in two of our devices at the same time, one on Telem1 and one on Telem2. We flashed the Pixhawk with ArduPlane4. When one device sent a message to set the interval of the MAVLink messages, the other device would stop receiving messages entirely, and vice versa. This situation was not repeatable with ArduCopter.
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 reached out the discuss.cubepilot.org community as well, and a member there recommended we post here as well and tag @tridge as well. Thanks everyone!