The control loop has three latency contributors and they compound: sensor pipeline (ToF reading → ROS 2 topic), policy compute (inference → action message), and command pipeline (action → MAVROS → MAVLink → ArduPilot → motor PWM). Total budget for a responsive indoor drone is on the order of 50–100 ms one-way; anything past that and the policy is reacting to a stale picture of the world.
This page is currently a placeholder — the detailed breakdown lives in ROS 2 latency tuning, which covers the DDS layer (RMW choice, QoS profiles, transport overhead) and the practical tuning recipe we use on D2. For the sensor side, see TF-Luna driver for the UART pipeline timing characteristics, and for the command side, MAVROS theory covers the MAVLink translation cost.
Three quick rules from experience:
- Don’t fight individual µs. A 5 ms improvement in DDS publish latency is irrelevant if you’re also waiting 50 ms for the next TF-Luna frame. Measure the longest pole first.
- Sensor data → BestEffort QoS. Reliable QoS adds retransmit overhead for messages that get superseded by the next reading anyway. The full QoS table is on the ROS 2 latency tuning page.
- Co-locate the tight loop.
frontier_picker+mission_fsm+state_publisherlive in one process (composition); only SLAM and MAVROS run in separate processes for crash isolation.
Where to go next
- ROS 2 latency tuning — the detailed page
- MAVROS theory — command-side timing
- Setpoint vs takeoff rules — what happens when you fight ArduPilot’s internal timing