The autonomous drone stack in 2026: PX4, ROS2, and the companion computer decision
How the modern autonomous quadcopter stack fits together — autopilot, companion computer, ground station, and the DDS bridge between them.
This is the first technical post in the Autonomous Quad 2026 build log. Last week’s manifesto was the why. This is the what.
The “autonomous drone stack” in 2026 is a layered system with distinct responsibilities. Each layer has multiple viable choices and a small handful of canonical defaults. Knowing the defaults — and why they’re the defaults — is the difference between a working build and a year of yak-shaving.
This post walks through every layer of the stack I’m using for this project, the choices I’ve made, and the reasoning behind each one. The companion computer choice is left open deliberately — that’s the W5 post. If you’re starting from scratch, this is the architectural map.
The four layers
┌──────────────────────────────────────────────────────────────────┐
│ 4. Ground Station QGroundControl · rviz2 · Foxglove │
├──────────────────────────────────────────────────────────────────┤
│ 3. Companion computer ROS2 · MAVROS2 · vision · SLAM · planner │
├──────────────────────────────────────────────────────────────────┤
│ 2. Autopilot Cube Orange+ — PX4 · EKF2 · offboard │
├──────────────────────────────────────────────────────────────────┤
│ 1. Airframe Motors · ESCs · battery · props · frame │
└──────────────────────────────────────────────────────────────────┘The layers communicate downward through serial (MAVLink), upward through DDS over Ethernet or WiFi, and sideways through ROS2 topics.
Let me walk each one.
Layer 1 — Airframe
For a development drone that needs to carry a full compute stack with margin: a 650-class quadcopter frame with 13-inch props. Tarot 650, Holybro X500, or equivalent. Big enough to maneuver outdoors, small enough to develop indoors.
Airframe + motors + props + ESCs + battery is the bottom $500-700 of the build. Most of that cost is in the propulsion system, which is also where most of the safety risk lives. Buy from reputable vendors, document the thrust tables, run the math.
Total airframe + propulsion cost: ~$500-700.
Layer 2 — Autopilot: Cube Orange+ on PX4
The autopilot is the only safety-critical system on the aircraft. Everything else — companion computer, vision stack, ground station — can crash, freeze, or lose power and the autopilot will still bring the drone home.
For this build: Holybro Cube Orange+ running PX4 v1.15+.
Why Cube Orange+
The Cube form factor has better vibration isolation than the Pixhawk 6X series. The Cube sits in a foam-damped carrier board that mechanically decouples it from the frame. For a research drone carrying a companion computer and stereo camera, this matters more than the extra $300 over a Pixhawk 6X Pro.
The Orange+ (not the base Orange) has more flash and RAM, which matters for some of the PX4 v1.15+ features we’re using. If you already have a regular Cube Orange, it works too.
Why PX4 over Ardupilot
Both are mature, well-maintained open-source autopilot projects. Both support the Cube. For this project the choice comes down to one thing: ROS2 integration.
PX4 treats ROS2 as a first-class integration target. MAVROS2 is in the PX4 docs, the PX4-ROS2 bridge examples are maintained by the PX4 team, and the offboard mode (which is what we use to send position setpoints from a companion computer) is well-documented and well-tested in PX4.
Ardupilot supports ROS2 via MAVROS too, but the documentation is thinner and the reference examples are sparser. For a project where ROS2 is the integration layer, PX4 wins.
What PX4 actually does
For an autonomous quad, PX4 handles:
- EKF2 sensor fusion. Combining IMU + GPS + barometer + magnetometer into a state estimate at 250 Hz. The state includes position, velocity, orientation, and angular rates. EKF2 is highly configurable; you can tune which sensors contribute, how much noise to assume, and how the filters interact.
- Offboard mode. This is the mode that lets a companion computer send position, velocity, or acceleration setpoints. PX4 runs the control loops; the companion decides where to go. Without offboard mode, there’s no autonomy.
- Safety: failsafe, geofence, low-battery RTL. If the companion loses link, the autopilot can return-to-launch or land autonomously. This is the safety net that makes the rest of the stack possible.
PX4 doesn’t do vision. PX4 doesn’t do SLAM. PX4 doesn’t do mission planning. It runs the aircraft. Everything else is layered on top.
Layer 3 — Companion computer (TBD)
The companion computer is the ROS2 host. It runs the bridge to PX4 (MAVROS2), the mission executor, the failsafe watchdog, the telemetry forwarding to the ground station, and — for vision-capable builds — the perception stack.
For this build, the companion is one of:
- Jetson Orin Nano Super (8 GB) — the canonical AI robotics platform in 2026
- Raspberry Pi 5 (8 GB) + Hailo-8L AI Kit — budget-friendly, vision-capable but constrained
- Split-companion (RPi 5 + Jetson) — research-grade safety isolation
The detailed comparison is the W5 post (will be linked here when published). For now, the short version:
- Jetson is the default for AI robotics work
- Pi 5 + Hailo is the budget option
- Split-companion is overkill for development but valuable for BVLOS / swarms
What the companion actually runs (whichever is chosen)
ROS2 Jazzy nodes:
/mavros — MAVLink ↔ ROS2 bridge to Cube via TELEM2
/qcg/drone/state — drone state aggregator (pose, battery, link)
/qcg/mission — waypoint mission executor
/qcg/safety — failsafe watchdog
/qcg/telemetry — MAVLink forwarding to ground station
/qcg/vision/depth — OAK-D Pro depth perception (vision-capable only)
/qcg/vision/detect — YOLO11 real-time detection (vision-capable only)
/qcg/vision/slam — VINS-Fusion / ORB-SLAM3 (vision-capable only)
/qcg/planner/local — Nav2 local planner + costmap (vision-capable only)Plus: a WiFi access point (hostapd) so the ground station can connect without depending on external infrastructure.
Why this matters
The companion is the integration layer. It doesn’t fly the drone — PX4 does that. The companion decides where to fly, what to look for, and how to react.
For an autonomous drone, this split is the canonical pattern. The autopilot runs the aircraft (low-level control, sensor fusion, safety). The companion runs the intelligence (perception, planning, mission). They communicate over MAVLink, and the autopilot remains in control at all times.
Layer 4 — Ground station
The ground station is a laptop running:
- QGroundControl — PX4’s official GCS, for full parameter config and manual flight
- rviz2 — ROS2’s standard visualization, for seeing the ROS2 graph in real time
- Foxglove Studio — modern alternative to rviz2 with better web-based UX
- rqt — ROS2’s plugin-based debugging UI
The ground station connects to the companion over WiFi (the companion’s own access point). No internet required. Field-deployable.
The stack in one diagram
Ground Station (laptop)
│
│ WiFi (companion AP)
▼
┌───────────────────────────┐
│ Companion Computer │
│ ROS2 + MAVROS2 + vision │
│ (Jetson or Pi + Hailo) │
└─────────────┬─────────────┘
│ TELEM2 UART (MAVLink 2)
┌─────────────┴─────────────┐
│ Cube Orange+ │
│ PX4 + EKF2 + offboard │
└─────────────┬─────────────┘
│ DShot600
┌─────────────┴─────────────┐
│ ESCs + Motors │
└───────────────────────────┘What’s next
Week 3: BOM deep dive — every part, every choice, every cost. Week 4: Zero to first flight — PX4 + QGroundControl on the bench, first manual hover. Week 5: Companion shootout — Jetson Orin Nano Super vs RPi 5 + Hailo (the decision post).
If you want to follow along, subscribe for the weekly drop. The GitHub repo with the full BOM and architecture docs is here.
— Shane