M8-T14: Communication loss and failsafes

Learning objectives

After this lesson, you should be able to:

• List the loss events a UAV must handle and the typical actions for each.
• Choose timeouts that balance spurious triggering against reaction time.
• Design escalation so that a failed action leads to a safer one.
• Verify failsafes in simulation, on the ground and (bounded) in flight.

Conceptual explanation

Implementation-specific Failsafe names, actions and parameters are autopilot- and version-specific. PX4 groups them under its safety configuration (data link loss, RC loss, offboard loss, battery, geofence, position-estimate loss and others); consult the failsafe documentation for the exact parameters and defaults of your version. The example numbers are illustrative.

Common loss events and the actions usually available:

Design principles:

• Return is not always safe: a return path may cross obstacles or people, and relies on a valid position and a reachable home. If the position estimate is lost or the battery cannot support the return, landing in place may be safer.
• Escalate: if the first action cannot complete (return fails because position is lost), fall back to a lower-capability action (land), then to the most basic (descend, terminate).
• Priorities: when several events occur together, the most severe wins; define the order.
• Timeouts are a trade: short ones react fast but trigger spuriously on a noisy link; long ones leave the vehicle uncontrolled longer.

Engineering intuition

Imagine the moment the link drops at 120 m altitude, 800 m from the pilot, with 35 % battery. Return flies 800 m in a straight line at the return altitude; does the battery cover it with a margin? Does the path cross a building? Is the position estimate trusted? Each question has an answer in advance. The failsafe design is the pre-computed answer to “what then?” for the credible combinations of altitude, distance, battery and estimator state.

The offboard case deserves special attention because the companion computer is the part you wrote and trust least. If it stops streaming setpoints, PX4 leaves offboard mode; what mode does it enter, and is that mode valid in the current estimator state? In a vision-aided GNSS-denied flight, “return to launch” may rely on a position estimate that is itself fed by the failed companion: the failsafe must be selected for the failure of the thing that supplies the estimate.

Mathematical formulation

Timeout selection from the link statistics: with a heartbeat period $T_{h}$ and independent loss probability $p$ per message, a timeout of $m$ periods triggers spuriously with probability $p^{m}$ per window, and detects a real loss in at most $(m+1)T_{h}$. Choose the smallest $m$ with $p^{m}$ below the spurious-trigger budget; for $p=5$ % and a budget of $10^{-6}$ per window $m=5$. For a return-to-launch, the energy and distance check:

so the maximum distance from home at which return is feasible is $d_{\max}=(E_{\text{avail}}-E_{\text{climb}}-E_{\text{land}}-E_{\text{reserve}})v_{\text{return}}/P_{\text{cruise}}$. A battery failsafe at the warning level should trigger return when remaining energy equals the energy needed to return from the current position plus the reserve, not at a fixed percentage.

$T_{h}$, $m$, $p$

heartbeat period, missed-periods threshold, per-message loss probability.

E_*

energy terms: return, climb, landing, reserve, available.

$v_{\text{return}}$

return speed.

Architecture and data flow

Link and sensor monitors (MAVLink heartbeat from the ground station, RC input, offboard setpoint stream, estimator validity flags, battery state, geofence) → commander failsafe state machine (parameters for timeouts and actions) → mode request (hold, return, land, terminate) → navigator and controllers → logged in vehicle_status with the failsafe flags and the reason. The ground station displays the event; the companion receives the status and must stop commanding appropriately.

Real-world UAV applications

• Configuring failsafes for a beyond-visual-line-of-sight test (where permitted).
• Handling companion crashes in vision-aided flight.
• Defining the battery escalation levels for a mission.
• Writing the failsafe verification tests.

Implementation example

This runs as shown. A failsafe state machine with timeouts and escalation, plus the return-feasibility calculation. It confirms that a heartbeat loss triggers the configured action after the timeout, that a lost position estimate escalates return to land, and that a battery that cannot support the return forces landing in place. The structure is a model of the logic, not PX4 code.

import math

def return_feasible(dist_m, batt_wh, p_cruise_w=180.0, v_ret=8.0, climb_wh=0.5, land_wh=0.4, reserve_frac=0.2, batt_total_wh=148.0):
    need = p_cruise_w * dist_m / v_ret / 3600.0 + climb_wh + land_wh + reserve_frac * batt_total_wh
    return batt_wh >= need, need
def failsafe(state, T_loss=2.0):
    # state: dict(link_age_s, pos_valid, batt_wh, dist_home_m, mode). returns the action name; escalation returns, then lands
    actions = []
    if state['link_age_s'] > T_loss: actions.append('return')                         # configured action for link loss
    if actions and not state['pos_valid']: actions = ['land']                           # return needs a valid position estimate: escalate to landing
    if actions == ['return']:
        ok, need = return_feasible(state['dist_home_m'], state['batt_wh'])
        if not ok: actions = ['land']                                                   # cannot reach home: land in place
    return actions[0] if actions else 'continue'
base = dict(link_age_s=0.2, pos_valid=True, batt_wh=90.0, dist_home_m=800.0, mode='mission')
cases = {'nominal': base, 'link lost, all good': dict(base, link_age_s=3.0), 'link lost, no position': dict(base, link_age_s=3.0, pos_valid=False),
         'link lost, low battery far away': dict(base, link_age_s=3.0, batt_wh=30.0), 'short blip': dict(base, link_age_s=1.0)}
for k, v in cases.items(): print(f"{k:>34}: {failsafe(v)}")
assert [failsafe(v) for v in cases.values()] == ['continue', 'return', 'land', 'land', 'continue']
ok, need = return_feasible(800, 90.0); print(f"energy needed to return 800 m: {need:.1f} Wh (have 90.0 Wh) -> {'feasible' if ok else 'not feasible'}")
p, budget = 0.05, 1e-6; m = next(m for m in range(1, 30) if p ** m < budget); print("smallest m for a 5 % per-message loss and a 1e-6 spurious budget:", m)
assert m == 5 and abs(8.0 ** 2 / (2 * 4.0) - 8.0) < 1e-12

The PX4 parameters for the main actions are found under the safety configuration page; set them explicitly for the mission and record them in the baseline.

Common engineering mistakes

Failure modes

Debugging approach

1. Read the failsafe flags and the reason code in the log at the moment of the event.
2. Plot link statistics (heartbeat intervals, loss) around the event.
3. Replay the scenario in SITL by dropping the link or the stream.
4. Check parameters against the planned configuration in the manifest.

Practical exercises

1. Compute the maximum feasible return distance for your vehicle’s battery and power.
2. Choose $m$ and $T_{h}$ for a 1 s detection requirement with 3 % message loss and a $10^{-7}$ spurious budget.
3. List the failsafe actions for a vision-aided flight and the order of escalation.
4. Design a SITL test that drops the offboard stream and checks the resulting mode and position drift.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• PX4: Safety configuration (failsafes)
• PX4: Return mode
• ArduPilot Copter: Failsafe landing page

What’s next