The C++ mavsdk-based onboard computer program connects to the Ardupilot flight controller through Telem2. After establishing the connection, the flight controller will automatically disconnect after a random duration. Later, through the serial port debugging tool, I found that the flight controller’s Telem2 port had no MAVLink data stream output. However, after restarting the flight controller software using Mission Planner (MP), data returned and the connection was re-established correctly (I ruled out hardware issues through this). Once the serial port detects that the flight controller has disconnected, even if I restart my control program, it still cannot reconnect. I later tried using a TCP/UDP connection to the flight controller, but the disconnection issue persisted. However, sometimes after about half an hour, the flight controller reconnects on its own. This issue has been bothering me for months. I want to know why the flight controller serial port behaves this way. From the Ardupilot wiki, I learned that there may be conflicts caused by telemetry link sharing, but I am not sure if this is the cause of the problem, since I also use Telem1 to connect to QGC. I would greatly appreciate it if anyone could help me analyze the possible causes.
You have to request data streams on the telemetry ports… also your onboard computer must provide heartbeat,
Check : Requesting Data From The Autopilot — Dev documentation and Heartbeat/Connection Protocol | MAVLink Guide
I am certain that I have requested the data stream. The telemetry service of MAVSDK includes encapsulated data stream requests, and I also used the passthrough to send the SET_MESSAGE_INTERVAL command to request raw GPS and other data. I have been actively sending heartbeat packets (5Hz), in addition to the 1Hz heartbeat sent internally by MAVSDK, resulting in a total heartbeat frequency of 6Hz.
Today, I encountered the situation again where the flight controller serial port was not transmitting data. It feels like the flight controller blacklisted me. When I checked the message packets using MP, I could see the onboard computer’s heartbeat packets (1Hz) send by MAVSDK.
In other words, the flight controller refuses to send data to me, making it impossible for me to detect the flight control unit. However, it can receive the heartbeat packets I send.
Hi @ColdFire_yangqf,
I think the most likely cause is a system id conflict between the ground station and the companion computer. Can you check what system id is being used for the companion computer?
Another possibility is conflicting set-message-interval requests or request-data-stream messages.
I think we’re going to need more information about the setup and when it occurs in order to be of help. Could you remove some sender/receivers from the setup? For example, remove the GCS from the setup so that it is only the flight controller and the companion computer communicating? You’d probably need to add some debug to the companion computer and monitor it’s output from a console (e.g. not via a mavlink GCS)
FYI @peterbarker
6011.param (18.5 KB)
-
The portable computer running the Jetson program uses the same system ID (1) as the drone, but its component ID is custom set to 8. I’m not sure if this might cause a conflict.
-
The uploaded
6011.paramfile contains parameters for the flight controller. I’m not certain if this is a pattern, but one of my drones often disconnects from the Jetson during flight when the number of mission waypoints exceeds 70. The flight controller can only reconnect after a reboot. During this process, I also configured QGroundControl (system ID set to 255) to connect to the flight controller to allow manual intervention in case of an emergency. Whenever I fly the drone, I always use at least two ground control stations (including the Jetson). -
Thank you so much for your reply and for providing new ideas to help me solve these issues. I truly appreciate your support.
Hi @ColdFire_yangqf,
Setting the component id to 8 should be fine. Personally I normally use 191 (ONBOARD_COMPUTER) but it shouldn’t make any difference. You could try changing the companion computer’s system id but again I don’t think it will matter.
I suspect the issue is in MAVSDK but not too many AP developers have experience with it so it’s hard to say for sure. we normally recommend the lower level pymavlink but I know that could be a large change for your setup.
Perhaps there’s some test that could be done to confirm whether it’s the autopilot or MAVSDK that’s the problem? so for example if the problem can be replicated on the bench (without flying) perhaps the serial port that is connecting to the companion computer could instead be connected to a telemetry radio and GCS and then check again if the disconnects continue?
There should also be .tlogs created which could give a clue as to what is happening just before the disconections. Those logs can be large and detailed though so finding the issue could be laborious.
What version of ArduPilot are you running?
When in the “disconnected” state it enters, are you receiving heartbeats from the flight controller?
Check the MAV message in the onboard dataflash logs to see if the autopilot thinks it is sending heartbeat messages.
I have already performed such serial port swapping operations, exchanging the ports connected to Jetson and QGC on the flight controller’s serial ports. I found that even after swapping Telem1 and Telem2, QGC still works normally, but the Mavsdk program on Jetson still detects random disconnections from the flight controller.
Thank you for your suggestion. I will try creating tlogs files and use pymavlink to write a driver.
1、Ardupilot is using Copter-4.5.6, and below are the specific parameters of the flight controller.
MAVSDK is currently using versions 2.12.3 and 2.13.0.
The hardware is CUAV X7+, with a custom expansion board.
The logic of my code is as follows:
First, I use the subscribe_on_new_system function, which is used to callback when the flight controller connects and disconnects. Then, I create a telemetry service, but also connect to the drone through passthrough, and I set the message intervals for the following messages using MAV_CMD_SET_MESSAGE_INTERVAL. I have created the corresponding callback functions to receive messages such as Global Position and Raw Position, and I check whether the position information is being returned at the specified frequency. By the way (a side note), when I previously used MAVSDK version 2.0.1, when I detected that the drone hadn’t sent the subscribed messages for a while, I would again use MAV_CMD_SET_MESSAGE_INTERVAL to resubscribe to the messages. Although the drone would occasionally disconnect, it didn’t happen as frequently as it does now.
I am sure the issue might be with my program, mainly because the QGC (Ground Control Station) doesn’t show the drone disconnecting, but my program does.
2、 When Jetson detects that the drone is disconnected, it cannot receive the heartbeat messages sent by the drone.
3、How can I check the MAVLink messages to see if the flight controller is still sending heartbeat messages?