PX4 consists of two main layers: the flight stack is an estimation and flight control system, and the middleware is a general robotics layer that can support any type of autonomous robot, providing internal/external communications and hardware integration.
All PX4 airframes share a single codebase — multicopters, planes, VTOL, rovers, and submarines. The complete system design is reactive: functionality is divided into exchangeable components, communication uses asynchronous message passing, and the system handles varying workloads gracefully.
The reactive design principle
Modules communicate through uORB, a publish-subscribe bus backed by shared memory. This means the system is asynchronous and updates instantly when new data is available, all operations are fully parallelized, and any component can consume data from anywhere in a thread-safe fashion.
At runtime, you can inspect which modules are running with the top command in the NuttX shell. Each module can be started or stopped individually via module_name start / module_name stop. In SITL, the same commands work in the PX4 shell (pxh>).
PX4 High-Level Architecture
Both layers run in a single address space — memory is shared between all modules
Update rates
IMU drivers typically sample at 1 kHz and publish at 250 Hz. Controllers run at 250 Hz. The navigator and commander modules run much slower. Use uorb top to inspect live message rates.
PX4 runs on NuttX (flight controllers), Linux, or macOS. On NuttX, modules execute as tasks with their own stack. On Linux/macOS, PX4 runs as a single process with modules as threads. The work queue mechanism lets lightweight modules share a thread to save RAM.
text
Runtime environments ─────────────────────────────────────────────── OS Execution Address space ────────── ─────────── ────────────────────── NuttX Tasks Single (shared memory) Linux Threads Single process macOS Threads Single process (SITL)