claudeDrone is built on three load-bearing pieces glued together: ROS 2 as the runtime, ArduPilot as the flight controller, and a PyTorch RL policy as the brain that sends setpoints. Everything else — Gazebo, MAVROS, sensor drivers, custom nodes — exists to wire those three together cleanly enough that the policy can do its job without thinking about hardware. This section is the developer-facing reference for how all of that fits.
The two anchors here are the control loop and the node map. The control loop is the temporal view: how a sensor reading at 200 Hz becomes a state vector, becomes a policy action, becomes a motor PWM — and what the latency budget is at each hop. The node map is the spatial view: which ROS 2 nodes exist, what topics they publish, what topics they subscribe to. Both views describe the same system; pick whichever question you’re trying to answer.
A note on ROS 2 itself: we run Jazzy on Ubuntu 24.04 and standardized on rmw_fastrtps_cpp after the latency comparison in ros2-latency-tuning. The DDS layer matters more than most people expect — a default-tuned ROS 2 stack will idle around 5-10 ms of inter-node latency, which is fine for telemetry but starts to bite when your control loop wants to run at 200 Hz. Most of the optimization in this section is about keeping that hop under 1 ms.
If you’re new to the stack, start with MAVROS theory — it explains the translator node that bridges ROS 2 and ArduPilot, and most of the rest of the architecture is downstream of that bridge. From there, setpoint-vs-takeoff covers the practical handoff pattern we use to bootstrap a flight from ground to RL control. Together they’re maybe 20 minutes of reading and they unlock the rest of the section.
Contents
Auto-generated from child _index.md files and entries during build (update-indexes.mjs).