PX4

of PX4 flight control architecture

PX4 (Pixhawk Autopilot) is an open-source drone flight control system widely used in multirotor, fixed-wing, and vertical take-off and landing (VTOL) drone platforms. Its architecture is designed based on modularity, real-time performance, and scalability, supporting a wide range of application scenarios from consumer to industrial applications. The following provides a detailed analysis of its architecture layering, core components, and data flow:

1.

PX4 adopts a layered architecture design, dividing system functions into different levels. Each layer interacts through standardized interfaces to ensure module decoupling and reusability. The core architecture is divided into:

1. Hardware Abstraction Layer (HAL)
2. Middleware
3. Applications
4. Peripheral tools and interfaces

2.

1. Hardware Abstraction Layer (HAL

• Function: Shields underlying hardware differences, provides a unified interface for the upper layer, and supports different hardware platforms (such as Pixhawk series, Holybro Kakute, etc.).
• Key modules:
  • Sensor driver: supports inertial measurement units (IMUs) such as gyroscopes, accelerometers, magnetometers, barometers, as well as GPS, vision sensors, etc.
  • Actuator drive: controls output devices such as motors, servos, and electronic speed controllers (ESCs), and supports communication protocols such as PWM and DShot.
  • Communication interface: abstract interface of hardware communication protocols such as UART, I2C, SPI, and CAN.
  • Power management: battery voltage monitoring, power status management.

2.

The middleware layer is the core of the PX4 architecture, responsible for real-time task scheduling, data processing, and inter-module communication. It includes the following key components:

(1) Real-time operating system (RTOS

• Based on NuttX RTOS (or Zephyr RTOS), it provides real-time support such as task scheduling, memory management, and interrupt handling.
• Supports multi-threaded parallel processing (such as sensor reading, control algorithm, and communication task separation) to ensure real-time response of high-priority tasks (such as posture control).

(2) Data Distribution and Communication (uORB

• uORB (Micro Object Request Broker): PX4's self-developed lightweight message bus for sharing data between modules.
• Features:
  • Publish/Subscribe model: Modules can publish data (such as sensor readings) or subscribe to data (such as control instructions), decoupling dependencies between modules.
  • Real-time guarantee: Message queue priority management ensures that critical data (such as posture information) is transmitted first.
  • Typical message examples: sensor_combined (sensor fusion data), vehicle_attitude (aircraft attitude), actuator_controls (actuator control instructions).

(3) Control algorithm

• Attitude Control Module:
  • Based on PID, complementary filtering and other algorithms, it processes IMU data, calculates the aircraft attitude (roll, pitch, yaw), and outputs motor/servo control variables.
• Position & Navigation:
  • Integrate GPS, visual positioning (such as optical flow), and barometer data to achieve functions such as fixed-point hovering and trajectory tracking.
• Mission & Path Planning:
  • Supports receiving mission instructions (such as waypoint flight) through the MAVLink protocol, or locally executing preset mission scripts (.mission files).

(4) Hardware interface and driver

• Encapsulates the underlying hardware drivers and provides standardized interfaces to the upper layers (such as device drivers modules managing sensor devices).

3.

The application layer contains functional modules and command-line tools that users can directly call to implement specific flight modes and tasks:

• Airplane Mode:
  • Manual mode (Manual), Stabilized mode (Stabilized), Position mode (Position), Auto mode (Auto, waypoint flight), Return to Launch (RTL) mode, etc.
• Useful tools:
  • commander: Receive and execute flight instructions (such as takeoff and landing).
  • mavlink: Handles the MAVLink communication protocol and interacts with ground stations such as QGroundControl.
  • px4ctl: System configuration and control commands (such as parameter adjustment and log management).
• Extended application:
  • Supports custom application development (such as visual obstacle avoidance and agricultural spraying control) and is integrated into the system through CMake compilation.

4. Peripheral tools and

• Ground Station Interface: Communicates with ground station software such as QGroundControl and Mission Planner via the MAVLink protocol to enable parameter configuration, real-time monitoring, and mission planning.
• Development toolchain:
  • A cross-compilation tool based on GCC that supports development on Linux, Windows, and macOS.
  • Simulation environment: Software-in-the-loop (SIL) and hardware-in-the-loop (HIL) simulation tests are implemented through tools such as Gazebo and JSBSim.
• Communication protocols: Supports MAVLink, ROS/ROS 2, UDP/TCP and other protocols, facilitating integration with other systems (such as robot operating systems and cloud platforms).

3. Data Flow and Control

1. Sensor data processing

1. Data acquisition: The HAL layer drives the reading of raw sensor data (such as angular velocity and acceleration of IMU).
2. Preprocessing: Remove noise and calibrate sensor bias through filtering algorithms (such as complementary filtering and Kalman filtering).
3. Data publishing: Published to the message bus via uORB for the attitude control module to subscribe.

2. Control loop (taking attitude control as an example

1. Outer loop (position/velocity control): Calculates the desired attitude (angle) based on the target position (such as a GPS waypoint).
2. Inner loop (posture control): Compare the current posture with the desired posture and generate the motor control quantity through the PID algorithm.
3. Output execution: The control quantity is sent to the ESC/servo through the HAL layer to adjust the aircraft attitude.

3. Task and Communication

• The ground station sends mission instructions (such as "go to coordinates (10,20,30)") through MAVLink. After mavlink being parsed by the module, commander it is converted into flight control instructions and executed through the control loop.

4. Architecture Advantages and Design

1. Modular design: Each functional module is independently developed and tested, facilitating maintenance and expansion (such as adding new sensors or flight modes).
2. Real-time guarantee: Based on RTOS and uORB message priority mechanism, it ensures the real-time response of the control loop (usually 100-1000Hz).
3. Cross-platform compatibility: Through HAL layer abstraction, it supports multiple hardware platforms (such as Pixhawk 2, FMUv5) and RTOS (NuttX/Zephyr).
4. Open source ecosystem: Relying on the PX4 open source community, it supports global developers to contribute code and integrates advanced algorithms (such as visual SLAM and autonomous obstacle avoidance).

5. Typical Application

• Consumer drones: such as DJI open source platform and drone control.
• Industrial applications: agricultural plant protection, logistics distribution, power inspection, and aerial photography.
• Research and education: UAV research in universities and autonomous driving algorithm verification (such as MIT's AeroAstro Lab project).
• Special scenarios: military reconnaissance, post-disaster rescue, geological exploration and other fields with high reliability requirements.

6. Development and Extension

• Source code structure: PX4 source code is organized based on CMake, and the directory structure is clear (such src/lib as library files and src/modules functional modules).
• Custom development: Implement specific functionality by creating new modules (such as src/modules/my_application) and interact with other modules using the uORB interface.
• Simulation Testing: Use Gazebo to simulate the aircraft and environment, allowing you to verify algorithms without hardware (e.g., make px4_sitl gazebo launching simulation).

Conclusion

The PX4 flight control architecture achieves efficient and flexible drone control through a layered design, modular components, and real-time communication mechanisms. From the underlying hardware drivers to the upper-layer application functions, each layer works together through standardized interfaces, meeting the reliability requirements of industrial drones while providing open expansion space for developers. Whether rapidly developing consumer drones or enabling autonomous control in complex scenarios, the PX4 architecture demonstrates strong adaptability and scalability.

The differences between Pixhawk, FMU, PX4, and FC

In the field of drone flight control, Pixhawk, FMU, PX4, and FC are closely related but distinct concepts, corresponding to hardware, core modules, software systems, and functional categories, respectively. The following is a detailed explanation of the specific differences and connections:

1. FC (Flight Controller

• Definition: FC is a general term for "flight control," which refers to the hardware equipment responsible for core functions such as drone attitude control, navigation, and mission execution . It is the "brain" of the drone.
• Function: Obtain the drone status through sensors (gyroscope, accelerometer, GPS, etc.), calculate control instructions, drive motors or servos to adjust flight attitude, and process ground station instructions and perform autonomous tasks.
• Scope: All drone flight control hardware can be called FC. For example, Pixhawk, APM (ArduPilot Mega), DJI's N3/M6, etc. are all specific FC products.

2. Pixhawk

• Definition: Pixhawk is a specific series of flight control hardware, developed by the open source drone community (such as the PX4 project). It was originally based on the design of 3DRobotics and has now become the benchmark for open source flight control.
• Features:
  • Open source hardware: Design drawings and specifications are made public to support secondary development.
  • Strong compatibility: compatible with various drone types (multi-rotor, fixed-wing, helicopter, etc.).
  • There are many iterative versions: such as Pixhawk 1 (FMUv2), Pixhawk 2.1 (FMUv3), Pixhawk 4 (FMUv5), etc. The performance improves with each version (computing power, sensor accuracy, etc.).
• Relationship with FC: Pixhawk is a specific implementation of FC and one of the most well-known open source FC products.

3. FMU (Flight Management Unit

• Definition: The FMU is the core computing module in the Pixhawk hardware , equivalent to the "main chip" of the flight control system. It is responsible for running flight control algorithms, processing sensor data, and executing control logic.
• Composition: Usually includes a microprocessor (such as the STM32 series), memory, power management circuits, etc., and is the core component of Pixhawk hardware.
• Version correspondence: Different Pixhawk models correspond to different versions of FMU, for example:
  • Pixhawk 1 with FMUv2
  • Pixhawk 4 with FMUv5
  • Version upgrades usually mean stronger computing power, more interfaces, and better stability.
• Relationship with Pixhawk: FMU is part of Pixhawk hardware and is the core unit for implementing flight control functions.

4. PX4

• Definition: PX4 is an open source flight control software system that runs on flight control hardware (such as Pixhawk) and is responsible for implementing the autonomous flight logic (attitude control, path planning, task scheduling, etc.) of the drone.
• Function:
  • Provides underlying control algorithms (such as PID control and LQR control).
  • Supports a variety of sensors and peripherals (GPS, barometer, obstacle avoidance radar, etc.).
  • Compatible with ground station software (such as QGroundControl) and supports manual/automatic flight mode switching.
• Relationship with hardware: PX4 is software that needs to run on specific hardware. The most typical compatible hardware is Pixhawk, but it can also be ported to other FCs (such as DJI N3 partially supports PX4).
• Difference from ArduPilot: PX4 and ArduPilot are two mainstream open source flight control software. PX4 focuses more on modular design and real-time performance, while ArduPilot is known for its rich features and ease of use. Both can run on Pixhawk.

Summary:

concept	type	Core role	Examples/Correspondence
FC	Functional Category	The "brain" of the drone (a general term for hardware)	Pixhawk, DJI N3, etc. are all FC
Pixhawk	Hardware products	Specific models of open source flight controllers	A type of FC equipped with FMU module
FMU	Hardware Module	Pixhawk's core computing unit	Part of Pixhawk (such as FMUv5)
PX4	Software System	Flight control algorithm running on FC	Most suitable for Pixhawk, can also be used for other FC

Simply put: FC is a general term for flight control, Pixhawk is an open source FC hardware, FMU is the core module of Pixhawk, and PX4 is the control software running on FC such as Pixhawk.

Introduction to Offboard Mode and Onboard Mode in PX4

Offboard mode and Onboard mode in PX4 (usually referring to autonomous modes such as Auto and Mission; note that "Onboard" is not a standard mode name officially defined by PX4, but rather a relative term to Offboard) are two different control methods. The core difference lies in the source of control commands and the degree of autonomy, as follows:

1. Offboard mode (external control mode

Offboard mode is a PX4 mode specifically designed for drones controlled by external devices (such as ground stations, onboard computers, ROS nodes, etc.). In this mode, the drone's core control commands (such as position, speed, attitude, and throttle) are sent entirely by the external system to the flight controller via a specific protocol. The flight controller is solely responsible for executing these commands and providing basic stability control (such as maintaining a stable attitude).

Key Features

• External control source: Commands must be sent in real time (usually at a frequency ≥ 2Hz) by an external device (such as an algorithm running on an onboard computer or ground station software) via the Mavlink protocol. Otherwise, the flight control will automatically switch to a safe mode (such as Altitude or Position mode) after a timeout to prevent loss of control.
• High flexibility: Suitable for custom control logic, such as trajectory tracking, obstacle avoidance algorithms, and SLAM navigation in scientific research. Users can generate complex motion commands through programming.
• Dependence on external systems: External device failure or communication interruption will directly affect the safety of the drone, so redundant design or emergency switching mechanism is usually required.
• Typical applications:
  • Autonomous navigation algorithm testing based on ROS.
  • The ground station manually sends custom track points.
  • The onboard computer uses visual sensors to achieve autonomous obstacle avoidance.

2. Onboard mode (autonomous mode, such as Auto/Mission

PX4's "Onboard Mode" primarily refers to the flight controller's autonomous decision-making and generation of control commands. The most typical of the official standard modes is Auto (Mission Mode), but other modes include Mission, Hold, and Return. In these modes, control logic and command generation are entirely internal to the flight controller, requiring no external intervention.

Key Features

• The control source is internal to the flight controller: The flight controller autonomously generates control commands based on predefined tasks (such as waypoint lists), sensor data (such as GPS, IMU) and built-in algorithms (such as PID controllers), without the need for external input.
• Strong autonomy: Without continuous external communication, the flight control can independently complete tasks such as takeoff, waypoint flight, and landing.
• Standardized process: Relying on the mature control logic built into the flight controller, users only need to plan the mission (such as setting waypoints, altitude, and speed) through the ground station, without having to write complex control algorithms.
• Typical applications:
  • Automatic inspection according to preset waypoints.
  • Perform repetitive mapping tasks.
  • Automatic return to home in emergency situations (Return mode).

Core Difference Comparison

Dimensions	Offboard Mode	Onboard mode (such as Auto)
Control command source	External equipment (onboard computer, ground station, etc.)	Flight control internals (predefined tasks, built-in algorithms)
Autonomy	Depends on external systems, the flight control only executes instructions	Completely autonomous, no external intervention required
Communication Request	Instructions must be sent in real time (≥2Hz), otherwise the safety mode will be triggered	No need for continuous communication, only configuration during mission planning
flexibility	High, supports custom control algorithms	Low, relies on the built-in logic of the flight controller, only configurable parameters/waypoints
Typical uses	Scientific research, custom algorithm testing (such as trajectory tracking, obstacle avoidance)	Routine task execution (inspection, surveying, automatic return)
Security Mechanism	Redundant design that relies on external systems	Flight controller with built-in safety logic (such as low battery return, fault protection)

Conclusion

• If you need to control the drone with your own algorithms (such as implementing a specific trajectory or obstacle avoidance logic), select Offboard mode and ensure the real-time and reliability of external commands.
• If you only need the drone to complete tasks autonomously according to a preset process (such as flying according to waypoints), select an autonomous mode such as Auto. The flight control will handle most of the low-level control, which is simpler and more stable.

In actual applications, the two modes can be used in combination (e.g., the Offboard mode performs complex tasks, and the return-to-home function of the Auto mode is switched to when an emergency occurs).

Detailed explanation of PX4 flight modes

PX4 has multiple flight modes, which can be divided into manual mode, assisted mode, and automatic mode. The following is a detailed introduction3:

• Manual Mode:
  • Manual mode: The remote controller is the control source, and the stick values are converted to the desired attitude. The user directly controls the aircraft via the remote controller; the flight controller does not control the position, and the position may drift due to wind.
  • Acro (Stunt Mode): Suitable for Flying Drones, but should be used with caution by beginners. Remote control stick measurements are converted to desired angular rates. The flight controller controls angular rate but not attitude. This allows the aircraft to perform complex acrobatic maneuvers, making it more difficult to operate.
• Assisted Mode:
  • Altitude Mode: The aircraft maintains a constant altitude when the throttle is neutral, making it suitable for novice pilots. The aircraft maintains a stable altitude but cannot maintain a fixed position. Winds may cause the aircraft to drift horizontally.
  • Position (Fixed Position Mode): Shifts the stick values into desired velocities on all three axes. When the stick values are neutral, the aircraft's speed is zero, and the position remains unchanged, allowing it to hover. This mode allows the aircraft to withstand wind and maintain a fixed position, making it a safer choice for beginners.
• Automatic mode:
  • Takeoff: When switching to this mode, the aircraft automatically takes off, flies vertically upward to the set altitude, and then remains in the hover, and does not accept joystick control.
  • Land (One-key landing): The aircraft descends vertically at the speed set by the parameters, maintains the idle speed for the set time after landing, and then locks.
  • Return (One-key return): The aircraft first flies upward to a certain altitude, then returns to above the HOME point in a straight line or along the original route according to the parameters, and then slowly descends to the ground in landing mode.
  • Mission Mode: Waypoints must be planned via the ground station and uploaded to the aircraft. Once in Mission Mode, the drone will fly according to the planned waypoints and speeds, controlled by the cascade of the position and attitude control loops.
  • Offboard mode: The aircraft receives and responds to external control data transmitted via MAVLink, primarily serving as an interface for external control data. It requires auxiliary information for periodic communication and maintenance; otherwise, it will exit this mode.