Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/PX4/PX4-Autopilot/llms.txt

Use this file to discover all available pages before exploring further.

PX4 Autopilot is built on a two-layer architecture: the flight stack handles guidance, navigation, and control algorithms, while the middleware provides device drivers, inter-process communication, and external connectivity. Every component in the system is a self-contained module that communicates exclusively through the uORB publish-subscribe message bus, making the entire design reactive, asynchronous, and highly modular.

​
The reactive design principle

PX4’s architecture follows the Reactive Manifesto. In practice this means:
  • All functionality is divided into exchangeable, reusable components (modules).
  • Communication between components is done by asynchronous message passing over uORB.
  • The system updates instantly when new data is available, without polling.
  • All operations are fully parallelized — modules run independently and consume data from anywhere in a thread-safe way.
Because modules are decoupled through message passing rather than direct function calls, you can replace, restart, or add any module at runtime without affecting other running components.

​
The two layers

The flight stack contains all algorithms specific to autonomous flight. It processes the full pipeline from sensor data and RC input through to motor and servo commands.Key subsystems:
  • Estimators — combine multiple sensor inputs to compute vehicle state. The primary estimator is ekf2, which fuses IMU, GPS, barometer, magnetometer, and optical flow data to produce position and attitude estimates.
  • Controllers — take a setpoint and a measured or estimated state, and compute a correction output. For example, the position controller (mc_pos_control) receives a position setpoint and outputs an attitude and thrust setpoint.
  • Mixers — translate force and torque commands into individual motor commands, accounting for motor geometry, direction, and vehicle-specific limits.
  • Navigator — manages autonomous mission execution, holds, returns, and high-level mode transitions by publishing position setpoints.
Data flows from estimators → controllers → mixers → actuator outputs, with each stage publishing to uORB topics consumed by the next.

​
Data flow: sensors to actuators

The following steps describe how sensor data becomes motor commands at runtime.
1

Sensor drivers publish raw data

Hardware drivers (e.g., the ICM-42688-P IMU driver) read sensor hardware and publish calibrated measurements to topics such as sensor_combined and sensor_gyro at up to 1 kHz.
2

EKF2 estimates vehicle state

The ekf2 module subscribes to sensor topics, fuses measurements using an Extended Kalman Filter, and publishes vehicle_local_position, vehicle_global_position, and vehicle_attitude at 250 Hz.
3

Controllers compute setpoints

Mode-specific controllers (e.g., mc_pos_control, mc_att_control) subscribe to state estimates and setpoints from the navigator, then publish attitude rate setpoints and thrust commands.
4

Mixers translate to actuator commands

The actuator allocation module reads rate and thrust setpoints, applies the vehicle’s mixing geometry, and publishes actuator_motors and actuator_servos topics.
5

Output drivers command hardware

PWM, UAVCAN/DroneCAN, or other output drivers subscribe to actuator topics and write commands to the flight controller’s output pins at the appropriate rate.

​
Module execution model

PX4 modules run in one of two modes on NuttX (the primary flight controller RTOS):
A module spawned as an independent task gets its own stack, file descriptor list, and scheduling priority. Use this for modules that need to sleep, block on I/O, or do heavy computation.
independent_task = px4_task_spawn_cmd(
    "commander",                    // Process name
    SCHED_DEFAULT,                  // Scheduling type (RR or FIFO)
    SCHED_PRIORITY_DEFAULT + 40,    // Scheduling priority
    3600,                           // Stack size in bytes
    commander_thread_main,          // Task main function
    (char * const *)&argv[0]        // Command-line arguments
);

​
Runtime inspection

You can inspect and control modules live from the NuttX shell or the SITL pxh> prompt. 
# List all running modules and their CPU/stack usage
top

# Inspect uORB topic update rates in real time
uorb top

# Start or stop any module
commander start
ekf2 stop

# Check work queue status
work_queue status
In SITL you connect to the pxh> shell automatically. On hardware, access the NSH shell over MAVLink using mavlink shell in QGroundControl, or via a serial console connected to the debug port.

​
Explore the architecture further

uORB message bus

Learn how PX4 modules exchange typed messages asynchronously through the publish-subscribe bus.

Modules reference

Explore the key flight stack modules — what they do, how to start and stop them, and how to describe a new module.

MAVLink integration

Understand how PX4 communicates with ground stations, companion computers, and MAVLink SDKs.

Build docs developers (and LLMs) love

Get started for freeTalk to us