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 is an open-source flight control stack licensed under the permissive BSD 3-Clause license. As a developer, you can modify flight algorithms, add support for new sensors and actuators, define custom airframe configurations, and integrate external robotics frameworks such as ROS 2. This guide introduces the tools, workflow, and code structure you need to get started.

​
What you can do with PX4

PX4 is designed to be extended. The most common developer tasks fall into four categories:
  • Custom modules — Implement new flight modes, state estimators, or application logic by adding a module under src/modules/.
  • New drivers — Add support for sensors, actuators, or peripherals by writing a driver under src/drivers/ using the standard uORB messaging interface.
  • New airframes — Define a new vehicle type or configuration by adding an airframe file that maps physical geometry and mixer outputs to PX4’s control allocator.
  • ROS 2 integration — Connect an onboard or offboard ROS 2 node to PX4 over the uXRCE-DDS middleware bridge, enabling full bidirectional uORB topic access from ROS 2.

​
Development workflow

1

Set up your environment

Install the build toolchain for your host OS. Ubuntu 22.04 and 24.04 are the primary supported platforms, with macOS and Windows (via WSL2) also available. See Setting Up the PX4 Development Environment.
2

Clone the source

Get the full source tree including all submodules:
git clone https://github.com/PX4/PX4-Autopilot.git --recursive
3

Build and run in simulation

Validate your setup by running a software-in-the-loop (SITL) simulation before touching hardware. See Building PX4 Firmware.
4

Make changes and test

Edit source files, rebuild, and rerun the simulation. Use make format before committing to satisfy the CI format check.
5

Deploy to hardware

Flash firmware to your flight controller with make <target> upload once simulation testing passes.

​
Key tools

ToolRole
gitSource control; all submodules are managed with --recursive
cmakeMeta-build system; PX4 uses it to generate board-specific build files
makeInvokes cmake and the compiler; the primary interface for all PX4 builds
arm-none-eabi-gccGCC cross-compiler targeting ARM Cortex-M for NuttX/Pixhawk builds
ninjaFast build backend used by cmake under the hood
python3 / pipRequired for simulation tools, code generation, and CI scripts
The ubuntu.sh setup script installs all of these automatically on Ubuntu. On other platforms you may need to install some tools manually.

​
Code structure overview

The PX4 repository is organised so that related code lives together. The directories you will work in most often are: 
PX4-Autopilot/
├── src/
│   ├── modules/        # Flight modes, estimators, and application logic
│   ├── drivers/        # Sensor and actuator drivers
│   └── lib/            # Shared libraries (math, geo, control, filters)
├── msg/                # uORB message definitions (.msg files)
├── ROMFS/              # Airframe configs, mixer files, and startup scripts
├── Tools/              # Setup scripts, simulation launchers, utilities
└── platforms/          # OS-specific abstraction layers (NuttX, POSIX)
uORB is the publish-subscribe messaging bus that connects every module and driver. When you add a new data type, define it as a .msg file in msg/ and run the build — PX4 generates the C++ headers automatically.

​
Source directory details

src/modules/ contains the high-level flight stack: the commander (state machine), position and attitude controllers, the EKF2 estimator, the navigator (mission execution), and more. Each module is a self-contained directory with its own CMakeLists.txt. src/drivers/ contains drivers grouped by bus or peripheral type — imu/, barometer/, gps/, optical_flow/, actuator_outputs/, and many more. Drivers communicate with the rest of the system exclusively through uORB topics. src/lib/ provides reusable components such as PID controllers, quaternion math, geo conversion utilities, and the perf counter infrastructure. msg/ is the source of truth for all inter-module data. Adding a new message here and referencing it in a module’s CMakeLists.txt is sufficient to make it available system-wide.

​
Next steps

Set up your build environment

Install the toolchain on Ubuntu, macOS, or Windows so you can build PX4 from source.

Build PX4 firmware

Compile for SITL simulation and real hardware targets, and flash firmware to a flight controller.

Build docs developers (and LLMs) love

Get started for freeTalk to us