Open drone stack (PX4, ArduPilot, Dronecode)

Products and offerings #

Who they are

This hub is for engineers putting a companion computer and ROS 2 on a drone, or choosing between the two open autopilots. There is no single company here. The Dronecode Foundation was founded in 2014 as part of the Linux Foundation and calls itself vendor-neutral, according to a Linux Foundation press release. It hosts the PX4 Autopilot, the MAVLink protocol, the QGroundControl ground station and the MAVSDK libraries, and it maintains the Pixhawk open hardware designs that many flight controllers follow, according to its projects page.

ArduPilot is the other major autopilot. Its first open repository dates from 2009, it is developed by a community of professionals and enthusiasts with funding from commercial partners, and it reports being installed in over 1,000,000 vehicles, according to ardupilot.org. It is not a Dronecode project, but QGroundControl and MAVLink work with both.

Tooling and APIs

PX4 v1.17.0 was released on 13 May 2026. It runs on flight controllers built to the Pixhawk designs, among others, and in software-in-the-loop (SITL) simulation. Its ROS 2 link is uXRCE-DDS: a client in the firmware talks to a Micro XRCE-DDS agent on the companion computer, which exposes uORB topics as ROS 2 topics. PX4 v1.17 adds Zenoh as an experimental alternative, but the PX4 ROS 2 guide recommends DDS for most users. It recommends ROS 2 Jazzy on Ubuntu 24.04, or Humble on Ubuntu 22.04. Your workspace needs the px4_msgs package at the same version as the firmware’s message definitions. From v1.16 a Message Translation Node can bridge mismatched versions.

ArduPilot builds DDS support (AP_DDS) into the firmware. It publishes topics such as ap/pose/filtered, ap/twist/filtered, ap/navsat/navsat0 and ap/tf, and offers services for arming, mode changes and parameters, according to the ArduPilot ROS 2 interfaces page. The same page says the supported ROS version is Humble and that ArduPilot does not yet keep a stable interface across ROS distributions. The current release series is 4.7, with 4.7.2 tagged for Copter, Rover, Sub and Tracker in October 2026.

Both autopilots also speak MAVLink, so MAVROS, MAVSDK and QGroundControl work with either. The aerial and field robots topic covers estimators and control loops in more depth.

Pain points: firmware and ROS message versions must match. Timing over a serial or UDP link to the companion computer limits how tight an offboard loop can be. Each autopilot has its own parameter set, so a tuned PX4 airframe tells you little about an ArduPilot one.

Migration notes

The main trap is frames. PX4 messages use NED (north, east, down) for the world and FRD (forward, right, down) for the body. ROS uses ENU and FLU per REP 103. ArduPilot’s DDS pose and twist topics are already in local ENU relative to home, and its odometry follows REP 105 odom to base_link. With PX4 you convert yourself, or use the frame_transforms library in px4_ros_com. This block converts a position and an attitude from ROS conventions to PX4 conventions:

import numpy as np
from scipy.spatial.transform import Rotation as R

# World frames: ENU (ROS, REP 103) and NED (PX4). Swap x and y, negate z.
ENU_TO_NED = np.array([[0.0, 1.0, 0.0],
                       [1.0, 0.0, 0.0],
                       [0.0, 0.0, -1.0]])
# Body frames: FLU (ROS) and FRD (PX4). A rotation of pi about x.
FLU_TO_FRD = np.diag([1.0, -1.0, -1.0])

position_enu = np.array([10.0, 2.0, 5.0])  # 10 m east, 2 m north, 5 m up
print("position NED (m):", ENU_TO_NED @ position_enu)

# Attitude: vehicle yawed 30 degrees left of east in ROS (ENU/FLU).
q_enu_flu = R.from_euler("z", 30, degrees=True)  # SciPy quaternions are (x, y, z, w)
rot_ned_frd = ENU_TO_NED @ q_enu_flu.as_matrix() @ FLU_TO_FRD.T
yaw_ned = R.from_matrix(rot_ned_frd).as_euler("ZYX", degrees=True)[0]
print(f"yaw in NED (deg from north, clockwise): {yaw_ned:.1f}")
print("quaternion NED/FRD (x, y, z, w):", np.round(R.from_matrix(rot_ned_frd).as_quat(), 4))

It prints a NED position of (2, 10, -5) m and a yaw of 60.0 degrees: 30 degrees north of east in ENU is 60 degrees clockwise from north in NED. Note that px4_msgs such as VehicleAttitude store quaternions as (w, x, y, z), the FRD-to-NED rotation, according to the message definition. SciPy and ROS messages use (x, y, z, w).

Moving between autopilots: MAVLink messages are common, but flight modes, parameter names and the ROS 2 topics differ completely. Treat a switch as a new integration.

Watch for

• GPLv3 on ArduPilot. The ArduPilot licence page says products that ship it must tell customers it is open source and provide or link to the source, and that GPLv3 lets the buyer replace the firmware on user products. PX4’s BSD-3 licence has no such obligation. This is often what decides the choice for a commercial product.
• Regulation is local. Flying rules, Remote ID and operator certification depend on the country. The autopilot does not make a flight legal.
• Interfaces change. Both projects revise ROS 2 interfaces between releases. Pin firmware and message package versions together.
• Safety. Test offboard code in SITL first, keep an RC override and a geofence, and never let a companion computer be the only path to a safe landing.