Flight Modes (Developers)
Modes ("flight modes", "drive modes", and so on) are special operational states that control how the autopilot responds to user input and controls vehicle movement. They are loosely grouped into manual, assisted and auto modes, based on the level/type of control provided by the autopilot. The pilot transitions between flight modes using switches on the remote control or with a ground control station.
Modes can be implemented as PX4 internal modes running on the flight controller, or as PX4 external (ROS2) modes running on a companion computer. From the perspective of a ground station (MAVLink), the origin of a mode is indistinguishable.
This topic links to documentation for the supported modes, compares PX4 internal and external modes, provides implementation hints, and provides links to how PX4 modes can be used with MAVLink.
Supported Modes
Not all modes are available (or makes sense), on all vehicle types, and some modes behave differently on different vehicle types.
Mode documentation for the PX4 internal modes are listed below:
- Flight Modes (Multicopter)
- Flight Modes (Fixed-Wing)
- Flight Modes (VTOL)
- Drive Modes (Differential Rover)
- Drive Modes (Ackermann Rover)
- Basic Configuration > Flight Modes
Internal vs External Modes
With some exceptions a mode can be implemented in either the FC or companion computer. The main considerations are listed below.
PX4 external modes cannot be used in the following cases:
- Modes that need to run on vehicles that don't have a companion computer.
- Modes that require low-level access, strict timing, and/or high update rate requirements. For example, a multicopter mode that implements direct motor control.
- Safety critical modes, such as Return mode.
- When you can't use ROS (for any reason).
External modes should be considered for all other cases. They have the following benefits:
- Easier to implement as there is no need to deal with low-level embedded constraints and requirements (such as restricted stack sizes).
- Easier to maintain as the integration API is small, well defined, and stable.
- Porting custom PX4 modes on the flight controller between PX4 versions can be much harder, as often flight modes use interfaces that are considered internal, and allowed to change.
- Process termination of a ROS 2 mode results in a fallback to an internal flight mode (while termination of an internal mode may well crash the vehicle).
- They can override existing modes to provide more advanced features. You can even override a safety-critical mode with a better versions: if the ROS 2 mode crashes the original mode will be engaged.
- High-level functionality is available, including a better-feature programming environment, and many useful Linux and ROS libraries.
- More available compute to do more advanced processing (e.g. computer vision).
Note that the PX4 ROS 2 Control Interface used to create external modes first appeared in PX4 v1.15 and is still considered experimental. There are still some limitations, but expect changes and ongoing enhancement.
PX4 External Modes
PX4 external modes, are written in ROS 2 using the PX4 ROS 2 Control Interface (see link for instructions).
PX4 Internal Modes
Mode Restrictions
Some modes only make sense only under specific pre-flight and in-flight conditions. For example, a manual control mode should not be used unless the system has a manual controller.
PX4 modes can specify these conditions as restrictions. For internal modes the types of restrictions are listed in the FailsafeFlags uORB topic under "Per mode requirements" (duplicated below)
text
# Per-mode requirements
mode_req_angular_velocity
mode_req_attitude
mode_req_local_alt
mode_req_local_position
mode_req_local_position_relaxed
mode_req_global_position
mode_req_mission
mode_req_offboard_signal
mode_req_home_position
mode_req_wind_and_flight_time_compliance # if set, mode cannot be entered if wind or flight time limit exceeded
mode_req_prevent_arming # if set, cannot arm while in this mode
mode_req_manual_control
mode_req_other # other requirements, not covered above (for external modes)
If the condition of restriction is not met:
- arming is not allowed, while the mode is selected
- when already armed, the mode cannot be selected
- when armed and the mode is selected, the relevant failsafe is triggered (e.g. RC loss for the manual control requirement). Check Safety (Failsafe) Configuration for how to configure failsafe behaviour.
This is the corresponding flow diagram for the manual control flag (mode_req_manual_control
):
The requirements for all modes are set in getModeRequirements()
in src/modules/commander/ModeUtil/mode_requirements.cpp. When adding a new mode you will need to add appropriate requirements in that method.
TIP
Readers may note that this image is from PX4 ROS2 Control Interface > Failsafes and mode requirements. The requirements and concepts are the same (though defined in different places). The main difference is that ROS 2 modes infer the correct requirements to use, while modes in PX4 source code must explicitly specify them.
MAVLink Integration
PX4 implements the MAVLink Standard Modes Protocol from PX4 v1.15. This can be used to discover all modes and the current mode, and to set the current mode.