PX4 + ROS 2 Architecture Explained: Flight Control, Perception, and Autonomy

A modern autonomous drone is rarely controlled by one computer.

Instead, the system is usually divided between:

1. A flight controller running PX4.
2. A companion computer running ROS 2.
3. A communication layer connecting the two.

PX4 handles the fast, deterministic tasks required to keep the vehicle stable and safe. ROS 2 handles computationally demanding autonomy functions such as computer vision, mapping, path planning, and mission logic.

Understanding this division is one of the most important steps in designing a reliable autonomous vehicle.

This article reflects PX4 v1.17, the stable PX4 release available as of July 2026.

The architecture at a glance

A typical PX4 and ROS 2 system looks like this:

Sensors → PX4 → DDS bridge → ROS 2 autonomy software

Commands then travel in the opposite direction:

ROS 2 planner → DDS bridge → PX4 controllers → motors and actuators

The two computers have different responsibilities, but they operate as one system.

The goal is not to move everything onto the companion computer. It is to place each function on the processor best suited to run it.

What PX4 should control

PX4 runs on a real-time operating system and manages the functions that must execute consistently, even when other parts of the vehicle are under heavy computational load.

PX4 should normally remain responsible for:

• IMU and sensor sampling
• Attitude and position estimation
• Rate, attitude, velocity, and position control
• Motor and actuator outputs
• Arming checks
• Battery and sensor monitoring
• Immediate failsafe behavior
• Basic takeoff, landing, hold, and return modes

These tasks require predictable timing.

A perception model taking slightly longer than expected should not delay a motor-control update. Separating flight control from higher-level autonomy helps preserve vehicle stability when the companion computer becomes overloaded, restarts, or loses communication.

What ROS 2 should control

ROS 2 is designed to connect software components across a larger robotics system.

The companion computer can run software for:

• Computer vision
• Visual-inertial odometry
• Lidar processing
• Mapping and localization
• Obstacle detection
• Path and trajectory planning
• Machine-learning inference
• Payload control
• Mission sequencing
• Multi-vehicle coordination

The companion computer usually has more processing power, memory, and storage than the flight controller. It can also run Linux libraries and development tools that would be impractical to place directly inside PX4.

PX4 recommends considering ROS 2 modes for behaviors that are not safety-critical, do not require strict timing, and can benefit from the resources and existing software available on a companion computer.

How PX4 communicates with ROS 2

PX4 uses DDS-based middleware to expose selected internal uORB messages to ROS 2.

With the standard uXRCE-DDS architecture:

• A lightweight DDS client runs inside PX4.
• A Micro XRCE-DDS Agent runs on the companion computer.
• The client and agent exchange information over serial, UDP, TCP, or another supported link.
• The agent connects PX4 data to the wider ROS 2 DDS data space.

This allows ROS 2 nodes to publish and subscribe to selected PX4 data.

For example, a ROS 2 application might subscribe to:

• Vehicle attitude
• Local position
• Battery status
• Sensor data
• Flight mode
• Failsafe state

The same application might publish:

• Position setpoints
• Velocity setpoints
• Trajectory setpoints
• Vehicle commands
• External position estimates

The list of PX4 uORB topics exposed through DDS is defined when the PX4 firmware is built. PX4 generates the necessary translation code from its internal message definitions.

A practical autonomy example

Consider an indoor inspection drone operating without GPS.

The system might work as follows:

1. Cameras and IMUs send data to the companion computer.
2. A ROS 2 visual-inertial odometry node estimates the vehicle’s movement.
3. ROS 2 sends the external position estimate to PX4.
4. PX4 fuses that estimate into its state estimator.
5. A mapping node builds a representation of the environment.
6. A planner selects a collision-free path.
7. ROS 2 sends motion setpoints to PX4.
8. PX4 converts those setpoints into stable motor outputs.

PX4’s ROS 2 Navigation Interface allows position measurements from systems such as VIO or map-matching software to be sent directly into PX4 and fused by its estimator like other navigation measurements.

ROS 2 determines where the vehicle should go.

PX4 determines how to fly there safely.

Offboard control versus ROS 2 flight modes

There are two major ways to control PX4 from ROS 2.

Offboard control

In Offboard mode, a ROS 2 node continuously sends commands or setpoints to PX4.

This is useful for:

• Early prototypes
• Research experiments
• Simple trajectory control
• Testing custom planners
• Applications that already generate continuous setpoints

PX4 requires a continuing proof-of-life signal in Offboard mode and exits the mode when that stream is lost. The official ROS 2 example also warns that developers must provide a reliable method to regain manual control during physical testing.

Offboard control is straightforward, but the autonomy software remains an external command source.

ROS 2 flight modes

PX4’s ROS 2 Interface Library allows developers to create modes on the companion computer and dynamically register them with PX4.

These modes can:

• Appear in QGroundControl like native PX4 modes
• Define their own activation requirements
• Send high- or low-level setpoints
• Participate in PX4 failsafe behavior
• Replace an internal PX4 mode
• Fall back to the original internal mode if the external mode fails

PX4 v1.17 describes the core mode architecture as largely stable and integration-tested, although parts of the API and several setpoint types remain under development.

For a mature autonomy system, registered ROS 2 modes can provide a cleaner architecture than treating every behavior as generic Offboard control.

Where should custom code run?

A useful rule is:

Keep safety-critical, high-rate, and timing-sensitive code inside PX4. Run perception, planning, and non-real-time autonomy on the ROS 2 companion computer.

Keep the code in PX4 when it:

• Directly controls vehicle stability
• Requires strict real-time timing
• Must continue if the companion computer fails
• Runs at very high update rates
• Is part of an immediate safety response

Run it in ROS 2 when it:

• Uses cameras, lidar, or large datasets
• Depends on Linux libraries
• Requires substantial CPU or GPU processing
• Changes frequently during research
• Coordinates several software components
• Performs mission-level decision-making

This separation makes the system easier to develop without compromising the responsibilities of the flight controller.

Simulation should use the same architecture

PX4 and ROS 2 can be connected in simulation using the same general messaging architecture used on physical hardware.

A research team can:

• Run PX4 in software-in-the-loop simulation
• Simulate the vehicle and environment
• Run real ROS 2 perception and planning nodes
• Test custom modes and failsafes
• Move the software to physical hardware after validation

PX4 also supports connecting multiple simulated vehicles to one XRCE-DDS Agent. Each PX4 instance receives a unique DDS key and ROS 2 namespace, enabling multi-vehicle and swarm-development workflows.

Simulation cannot eliminate physical testing, but it provides a safer place to test communication loss, estimator failures, planner behavior, and unexpected autonomy decisions.

Important integration details

The PX4 and ROS 2 connection is powerful, but it is not completely automatic.

Developers need to account for:

Coordinate frames

ROS 2 commonly uses East-North-Up conventions, while PX4 commonly uses North-East-Down and Forward-Right-Down conventions.

PX4 does not automatically convert every published topic between these frames. Incorrect transformations can send the vehicle in the wrong direction.

Message compatibility

ROS 2 applications must use PX4 message definitions that are compatible with the firmware.

PX4 introduced message versioning and a translation node that can convert recognized message versions between applications and PX4, reducing the need to rebuild both sides together.

Communication failure

The vehicle must have defined behavior for:

• Lost setpoints
• A stopped ROS 2 node
• Companion-computer failure
• Broken serial or network links
• Invalid external position estimates

Autonomy software should enhance the flight stack—not remove its ability to respond safely when the autonomy computer fails.

Building the architecture around the 305AP

The Avian Automata 305AP flight controller is designed as a compact PX4 foundation for multirotors, fixed-wing aircraft, and rovers.

It runs PX4 on an STM32H743 processor and provides:

• Seven UARTs
• Two telemetry ports with hardware flow control
• Two independent FDCAN interfaces
• Eight PWM or DSHOT outputs
• Redundant onboard IMUs
• USB-C connectivity
• A dedicated PX4 firmware target

The 305AP’s second telemetry port is intended for applications such as companion-computer communication, making it a practical connection point for a Linux computer running ROS 2.

Developers can build PX4 directly for the board using its dedicated avianautomata_305ap_default firmware target.

This provides a hardware path from:

PX4 simulation → ROS 2 development → 305AP bench testing → physical autonomous vehicle

Explore the Avian Automata 305AP flight controller →

Final takeaway

PX4 and ROS 2 should not compete for control of the same responsibilities.

PX4 provides the real-time foundation that keeps the vehicle stable, monitors its condition, and controls its actuators.

ROS 2 provides the larger software environment for perception, planning, navigation, and intelligent mission behavior.

The strongest autonomous systems use both:

PX4 handles the vehicle. ROS 2 handles the autonomy.

The communication layer between them allows each computer to focus on the work it is best equipped to perform—creating a system that is more modular, testable, and capable than either platform would be alone.