This is a control-authority problem rather than a simple link-quality problem. Detecting the absence of messages is only the first part of the response. The aircraft must know which external controller it was following, what evidence proves that controller has stopped working, and which safe state should receive control.
An ArduPilot proposal opened on 10 October provides a timely engineering example: an onboard Lua applet watches for a specified companion computer's MAVLink heartbeat and changes flight mode if those heartbeats stop while Copter is flying in GUIDED. It is still an open pull request, tested in simulation but not on hardware. The more durable question extends to any autopilot that delegates motion control to another computer.
A heartbeat proves less than it appears to
MAVLink's heartbeat protocol is a discovery and connectivity mechanism. A HEARTBEAT declares that a system or component is present, along with its type and autopilot identity. MAVLink deliberately does not prescribe one universal heartbeat period or disconnection timeout. RF telemetry installations commonly use roughly one heartbeat per second, with several misses indicating a disconnect.
That is useful for detecting a broken serial or network path. It is not automatically evidence that the planning program, perception pipeline or mission state machine is making progress.
Consider two implementations:
- The mission application sends its own heartbeat only after its control loop has successfully completed a cycle.
- A separate communications library keeps sending heartbeats independently of whether the application has frozen.
Both produce identical heartbeat traffic during healthy operation. After a deadlock, the second can continue reporting life. The flight controller sees a functioning sender and may never activate a heartbeat-based watchdog.
This is an acknowledged behavior in MAVSDK's heartbeat watchdog documentation. MAVSDK can continue sending normal heartbeats as long as its object exists, even if the application around it is hung. The opt-in watchdog changes that relationship: the application must regularly call feed_heartbeat_watchdog(), and the library stops its heartbeats if the application stops feeding it.
The distinction is not semantic. A heartbeat generated by a healthy telemetry thread says that the telemetry thread is alive. An application-fed watchdog can additionally say that a particular application execution path is progressing. Neither proves that its position estimates, obstacle decisions or commanded setpoints are correct.
ArduPilot's existing timeouts watch different failures
ArduPilot Copter has at least two relevant monitoring mechanisms, with different scopes.
The GUIDED mode documentation describes GUID_TIMEOUT, which defaults to three seconds for attitude, velocity and acceleration command streams. If those commands stop, the aircraft slows or levels and holds according to the control type. It can remain in GUIDED, waiting for new commands. A stable hover is a defined response to missing setpoints, not proof that the mission application is still operational.
Separately, the GCS failsafe monitors MAVLink heartbeats from the ground control station. The documented FS_GCS_TIMEOUT default is five seconds, and its configured action may be RTL, land or another permitted response. The same documentation notes that the GCS failsafe does not activate if a ground station has never connected. The GCS identity and the companion computer's identity are therefore not interchangeable.
This is why simply enabling a GCS-loss action does not necessarily protect a vehicle whose onboard companion process dies while the operator's ground station remains connected. Conversely, a companion-specific watchdog should not misinterpret an ordinary GCS-controlled GUIDED flight as a failed companion mission.
The October 10 proposed companion watchdog applet makes that distinction explicit. Its author says it monitors a configured MAVLink system and component, acts only while armed and in GUIDED, and requires a matching heartbeat associated with that GUIDED flight. If it times out, it switches to a configured mode, with LAND as the proposed default, and sends a critical status text. A GUIDED flight in which no matching companion heartbeat was observed remains unaffected.
These are design and test claims from a contributor, not released Copter behavior. The author reported a simulated hover switching to LAND after 2.1 seconds of lost heartbeats and subsequently landing and disarming. The pull request says there is no hardware testing or automated test yet. That is a useful starting demonstration, but it cannot establish sensor, RF or terrain robustness in an actual aircraft.
PX4 uses a different proof-of-life boundary
PX4's Offboard mode documentation requires a continuous external-control proof-of-life stream at more than 2 Hz. Under MAVLink Offboard control, the supported setpoint stream supplies both the commanded state and liveness signal. Under ROS 2, OffboardControlMode can provide proof of life separately from the setpoint itself. PX4 requires the stream before entering Offboard; loss beyond COM_OF_LOSS_T initiates the configured COM_OBL_RC_ACT response.
This checks a more direct interface to external motion control than a generic MAVLink heartbeat does. Yet a recurring setpoint generated by a stuck middleware node can still look alive even when a planner upstream has failed. The safety boundary needs to match the software component whose failure matters.
An aircraft may contain a perception process, a path planner, a trajectory smoother, a MAVLink or ROS 2 bridge and a low-level flight controller. If only the last bridge is monitored, upstream failures can leave the bridge streaming an old target. Monitoring every process independently may create unnecessary mode changes instead. The practical requirement is to define one authoritative health signal that means fresh, valid control decisions can still reach the aircraft.
For a stationary hover, an old position setpoint can be temporarily benign. In moving-target tracking, inspection beside a structure or low-altitude transit, it may be unacceptable. The chosen supervision boundary should reflect that difference.
Choosing a fallback mode is a site decision
A watchdog that reliably detects a failure can still command an unsuitable recovery.
LAND limits further flight, but the aircraft may be over a roadway, water or inaccessible terrain. RTL may take the aircraft through an obstacle, consume too much remaining battery or depend on a usable home position and navigation estimate. Position hold can create time for the pilot to take over, provided the aircraft has sufficient reserve power and valid positioning. Altitude hold can be less useful if horizontal drift is the immediate hazard.
ArduPilot's GCS failsafe documentation also makes an operationally important point: recovering the lost heartbeat does not automatically restore the previous flight mode. A vehicle that has changed to RTL remains in RTL until someone intentionally changes its mode. That avoids uncontrolled automatic handback, although other configurable recovery behaviors may exist in particular builds.
A competent control handoff needs to specify four things in advance:
- Trigger: Which component and kind of progress are monitored? What precise timeout applies?
- Fallback: Which flight mode is suitable for this environment, navigation source and remaining energy?
- Authority: Can the pilot override the fallback, and which concurrent failsafe wins if battery, RC or estimator health also deteriorates?
- Re-entry: What fresh evidence and explicit action are required before a restarted companion regains control?
The fourth point is often missed. Rebooting a mission computer should not automatically revive a stale survey trajectory or resume a delivery mission from a half-completed state. Recovery should involve an explicit new control grant after the autopilot and external software agree on current position, active mission and flight mode.
The failure combinations matter more than the happy path
A single simulation in which heartbeats stop and the vehicle lands verifies only one row of a much larger test matrix. A useful laboratory plan would exercise at least these cases:
| Test condition | Expected question |
|---|---|
| Companion process killed but telemetry bridge remains running | Does the health signal stop, or does a background thread mask the failure? |
| Link cable unplugged while a GCS remains connected | Does the companion-loss path fire independently of GCS failsafe? |
| Companion never connected on a GCS-only GUIDED mission | Is the mission left alone rather than falsely classified as a dropout? |
| Repeated mode switches near the watchdog deadline | Does the watchdog bind loss to the correct active control session? |
| Missing setpoints with continuing heartbeats | Does setpoint timeout or the application health check respond? |
| Heartbeats continue while the planner publishes stale coordinates | Is there a freshness or sequence check, rather than only a connectivity check? |
| Battery or EKF failsafe occurs during a companion outage | Which mode request wins, and can the watchdog accidentally cancel a more urgent recovery? |
| Companion restarts after a fallback mode is entered | Must the pilot or supervisor explicitly authorize renewed external control? |
Testing should begin in software-in-the-loop, continue through hardware-in-the-loop or restrained bench exercises where applicable, and only reach controlled flight after recovery behavior is understood. Logging should capture heartbeat source system and component IDs, receive times, setpoint age, mode changes, mode-change acknowledgements, RC inputs and the sequence of concurrent faults.
A watchdog's timeout is a trade-off, not a universal constant. A short value reacts sooner but is vulnerable to scheduling jitter, communications congestion and transient pauses. A long value tolerates those disturbances while extending the interval during which an out-of-date command can remain authoritative. The appropriate interval depends on aircraft speed, proximity to hazards and what the autopilot itself does while awaiting fresh commands.
Identity and diagnostics are part of the architecture
MAVLink's heartbeat guide distinguishes a component's type, autopilot, system ID and component ID. For a real system with several onboard applications, merely hearing a heartbeat is insufficient. A camera, gimbal or another process may remain connected while the controlling companion application has failed.
A configured system/component pair is better, but it is only an address. Designers still need to consider duplicate identities, routing, replacement hardware and the possibility that the same companion hosts several applications. A monotonic control-session ID, a timestamp or age limit on commands, and a supervised application-health feed can strengthen the design. These are possible engineering safeguards, not claims that MAVLink HEARTBEAT itself provides all of them.
The proposed ArduPilot watchdog exposes CWD_SYSID and CWD_COMPID, with a proposed component default of 191. That makes identity configuration visible. The proposal also intentionally ignores a companion that disappeared long before an unrelated GUIDED session. This avoids one class of false alarm, but leaves the operator responsible for verifying that the expected companion was present when autonomous control was granted.
What evidence would justify deployment
Today's documentation and code discussion support a narrow conclusion: external computer health, setpoint freshness and ground-station connectivity are separate things, and they require explicit coordination when an aircraft can change control authority in flight.
PX4 provides a defined Offboard proof-of-life interface. ArduPilot documents a GUIDED command timeout and a distinct GCS heartbeat failsafe. MAVSDK offers an opt-in way to tie heartbeats to application activity. The new ArduPilot applet proposal fills another potential gap by watching a named companion during a specific control session.
No one mechanism eliminates the need to test the complete vehicle. Before a companion-watchdog design is called flight-ready, useful evidence would include reproducible loss-injection runs, timing distributions under processor and link load, logs of competing failsafe actions, recovery from reboot, and controlled hardware tests in the intended operational environment.
The aim is not merely to notice silence. It is to make the next controller, and the conditions under which that controller takes over, predictable.