commander (Application)


The commmander app is in charge of the global state machine. It operates the red and blue leds and the buzzer output to indicate its current state. Think of the commander app as the process which ultimately makes sure that all the other apps only run actions which make sense in the current context of the system. For example the controller app should not be allowed to start the motors while your plane is still lying on your table.

Developer Information

Normal users should not need to interact directly with the commander app. However, knowledge of the state machine can help understand the actions of the system.

The following sections give an overview of the app structure for developers and about the flight safety state machine.

The commander app is a very critical system component. Changes will only be accepted after intense reviews. Read this page thoroughly and completely.

State Machine

Basic Concepts

The commander app implements a finite state machine. All states in this state machine are the evaluation of predicates of basic boolean logic (bool flags) and enums in First-order logic and state transitions occur following standard Automata theory.

The table below summarizes the individual states and the output flags. This is the result and not the input to the state machine.

State name Description armed att mode vel mode pos mode pos setpoint
PREFLIGHT Uninitialized system false any off off none
STANDBY Ready to be armed false any off off none
GROUND_READY Armed, still on ground true any off off none
MANUAL Armed, > 30% thrust true rate or att off off none
STABILIZED Armed, takeoff cmd true att on / off on / off stick/offboard
AUTO Armed, takeoff cmd true att on / off on / off waypoints
MISSION_ABORT true any on / off on / off any
EMCY_LANDING true any on / off on / off any
EMCY_CUTOFF true any on / off on / off any
GROUND_ERROR false any on / off on / off any

Typical State Transition Sequences

Manual Flight

  1. PREFLIGHT, immediately followed by
  3. GROUND_READY on arming (stays grounded with spinning rotors at idle speed)
  4. MANUAL on throttle above 30% for 0.5 s, even when still on ground
  5. GROUND_READY on disarming, immediately followed by

Autonomous Flight

  1. PREFLIGHT, immediately followed by
  3. GROUND_READY on arming (stays grounded with spinning rotors at idle speed)
  4. AUTO on takeoff command
  5. GROUND_READY on landing command (stays grounded with spinning rotors at idle speed)
  6. STANDBY on disarming

Individual States


The system boots up and immediately enters the PREFLIGHT state. In this state the system cannot be armed and all non-core systems and peripherals should be shut down. It is not known to the system if its fully operational, e.g. it has not evaluated yet the health of critical peripherals as the GPS receiver. Sensor calibration and other maintenance tasks are only possible in this state.


In standby state, the system has checked the basic operation and found critical peripherals to be operational. If it fails to initialize or communicate with one, it will transition into GROUND_ERROR.


The system is ready for takeoff, if a sensor fails or other errors occur the system throws a ground error.

MANUAL state

The system is flown with the remote-control, Error Handling:

  • only really severe errors are handled (for example a problem with the gyrometer) and lead to a state change to mission abort. Smaller errors are displayed on the ground station. The idea is that a skilled pilot can safely land his system even with some systems not working
  • system type dependency: for an airplane a gyrometer fail may not be fatal and so the system should not abort the mission. however, for a quadrocopter gyormeters are crucial, even in manual mode and therefore the system state should change to mission abort. (not implemented yet!)

(not implemented yet) The system stabilizes the altitude. Horizontal control is manually via the remote control.

AUTO state

The system navigates along the waypoints set in the groundstation. Position and attitude are controlled by the system itself.

MISSION_ABORT error state

A severe error has occured. If the system is in this state for the first time a reboot is done. The system will then go to in-air-restore after the reboot. If several attempts to reboot the system have been done without success the state is changed to EMCY landing or EMCY cutoff depending on the flight environment (FLIGHT_ENV parameter )

EMCY_LANDING error state

The controller tries to land the system (not implemented yet) and then switches to EMCY cutoff

EMCY_CUTOFF error state

All motors are stopped and the state changes to ground error.

GROUND_ERROR error state

The system is on the ground (or in a tree) and an error has occurred. The buzzer is used to notify the user.


This explains the structure of the commander app. You only need to read this if you want to change the commander app. The boxes with dotted borders indicate a buffered value.

The commander app consists of several loops which run as individual pthreads.

  • command_handling_loop: the mavlink app forwards mavlink commands to the commander app (see shared_object_communication) which are handled in this loop. Depending on the command the state machine is changed (in the state machine handling block).
  • subsystem info loop: listens to informations from subsystems (like sensors). This does not include the quality of the signal. Possible updates are: present/not present, enabled/disabled, healthy/unhealthy.
  • monitoring loop: does periodically the following checks and depending on the result of the checks the state machine is changed:
    • the quality (variance) of the sensors (gps for now!)
    • the ppm input (remote control) for arm/disarm stick positions
    • the battery voltage

State machine handling

All changes to the state machine are implemented in the file commander/state_machine_helper.c. The current state of the state machine is saved in the commander_state_machine_t enum in orb/global_data_sys_status_t.h.

The following list summarizes the most important functions in the file (this is NOT a complete list of all functions):

  • do_state_update: this performs the actual state update, all checks if the state update is valid need to be done beforehand.
  • state_machine_emergency_always_critical: should be called when a critical system (for the current platform fails). Handles the change to the error state.
  • state_machine_emergency: for non-critical errors (ex: gps in manual), calls state_machine_emergency_always_critical if the system is in a state that does not allow a fail of some sensors (e.g. auto state)
  • update_state_machine_custom_mode_request: performs checks if the requested update is possible and then calls do_state_update
  • update_state_machine_mode_request: for requests according to the mavlink enum MAV_MODE
Translations of this page:

Quick Links

QR Code: URL of current page