M6-T6: Flight modes

Learning objectives

After this lesson, you should be able to:

• Describe the main multicopter modes and the control each hands to the pilot or software.
• State the estimator outputs each mode requires.
• Explain what happens when a requirement is lost in flight (mode fallback and failsafe).
• Select the mode and failsafe configuration for an autonomous test.

Conceptual explanation

Implementation-specific Mode names, availability and fallback rules are PX4-specific and change between releases. Check the flight modes page for multicopters in the documentation of the version you use.

Representative multicopter modes in PX4:

The commander monitors the estimator validity flags, the link status and the battery. If a mode’s requirement fails, it applies the configured failsafe action (for example hold, return, land or fall back to a lower mode such as altitude or stabilised), depending on parameters and on whether the pilot has control. Careful configuration of these actions is a safety task, not a convenience.

Engineering intuition

Climb a ladder of trust: attitude from the IMU alone is the most robust; height needs a barometer or rangefinder; horizontal position needs GNSS, vision or flow. Each rung needs something external. In a GNSS-denied environment the position rung rests on your vision or lidar odometry, so “position mode works” means “my odometry is valid and fused”.

The failsafe is the safety net and must be tested, because the default may not be what you want. A vehicle flying a vision-aided mission that loses its vision should usually land or hold in altitude mode with pilot takeover, not “return home” using a position estimate it no longer has.

Mathematical formulation

A mode transition can be modelled as a guard on validity flags. Writing $v_{\text{att}}$, $v_{\text{alt}}$, $v_{\text{pos}}\in \{0,\,1\}$ for validity, the best available mode is the highest rung whose requirements hold. For hysteresis, a requirement lost for longer than a timeout $T_{\text{loss}}$ triggers fallback and is restored only after the estimate has been valid for $T_{\text{regain}}$:

The failsafe time budget is the sum of detection, decision and action times; for example if position is lost, the vehicle drifts at the velocity error rate: with a velocity bias $b$ the drift after $T_{\text{total}}$ is $b\,T_{\text{total}}$ (a bias of 0.2 m/s over 3 s is 0.6 m).

req(m)

set of validity flags required by mode $m$.

$T_{\text{loss}}$, $T_{\text{regain}}$

timeouts for losing and regaining a requirement.

Architecture and data flow

Estimator validity flags (vehicle_local_position flags and the estimator status flags) + link status + battery → commander → vehicle_status (nav_state, failsafe flags) and vehicle_control_mode → controllers and navigator select their setpoint source. A mode change command arrives from the RC, the ground station (a MAVLink command) or the companion (a VehicleCommand message over DDS). The same commander arbitrates all of them.

Real-world UAV applications

• Selecting the correct mode and failsafe for vision-aided and GNSS-denied tests.
• Designing a safe takeover procedure from autonomous to manual.
• Choosing a return strategy that does not depend on a lost sensor.
• Writing the mode-transition section of a test plan.

Implementation example

This runs as shown. A small mode-availability model with validity flags and timeouts, a stand-in for the commander’s logic (not PX4 code). It confirms the fallback order and the hysteresis on a scripted loss and recovery of vision.

import numpy as np
REQ = {'stabilised': {'att'}, 'altitude': {'att', 'alt'}, 'position': {'att', 'alt', 'pos'}}
ORDER = ['position', 'altitude', 'stabilised']

def simulate(valid_pos, T_loss=1.0, T_regain=2.0, dt=0.1):
    mode = 'position'; lost_t = 0.0; good_t = 0.0; modes = []
    for ok in valid_pos:
        if ok: good_t += dt; lost_t = 0.0
        else: lost_t += dt; good_t = 0.0
        if mode == 'position' and lost_t > T_loss: mode = 'altitude'          # position lost: fall back one rung
        if mode == 'altitude' and good_t > T_regain: mode = 'position'        # regained and stable for T_regain
        modes.append(mode)
    return modes
valid = np.array([1] * 30 + [0] * 20 + [1] * 40)                              # vision valid, lost for 2 s, restored
m = simulate(valid, dt=0.1)
t_fall = m.index('altitude') * 0.1; t_back = len(m) - 1 - m[::-1].index('altitude') + 1
print(f"fallback at t = {t_fall:.1f} s, back to position at t = {t_back * 0.1:.1f} s")
assert m[0] == 'position' and 'altitude' in m and m[-1] == 'position'
assert 3.9 < t_fall < 4.2 and 6.5 < t_back * 0.1 < 7.5

Configure and test the real behaviour in SITL by removing the aiding source and watching vehicle_status and the failsafe action.

Common engineering mistakes

Failure modes

Debugging approach

1. Plot nav_state, failsafe flags and estimator flags together over the flight.
2. Read the commander messages in the log console for the reason of each change.
3. Reproduce the loss in SITL by disabling the source.
4. Check the parameters of each failsafe action against the test plan.

Practical exercises

1. List, for your PX4 version, the failsafe parameters and their values for data-link loss, RC loss and estimator loss.
2. Write a mode-transition table for a vision-aided mission with a GNSS-denied area.
3. In SITL, disable the vision input mid-flight and record the fallback.
4. Define the pilot takeover procedure for your test vehicle in two sentences.

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: Flight modes (multicopter)
• PX4: Safety configuration (failsafes)
• PX4: Pre-flight checks

What’s next