Choose the interface by the interaction
ROS 2 topics suit continuous streams, services suit short request/response interactions, and actions suit longer tasks with feedback and cancellation. One original design uses topics for images and vehicle state, a service for a quick status query, and an action for a filming sequence. ROS 2 does not automatically replace a vendor flight API. It connects components; camera drivers, flight bridges, coordinate transforms and execution conditions still need implementation and validation. For each component, document what state it consumes and what it produces. Module boundaries should make delay, failure and replacement easier to understand, not merely make a diagram tidy. Write a short responsibility statement for each component regardless of system size.
Carry time, frames and quality with the data
A subject offset alone omits when it was observed, which camera produced it and whether it is reliable. Carry timestamps, coordinate frames, camera calibration and validity or confidence with observations. Processing every old frame in order may be inappropriate for control even if it is desirable for an archive. Choose communication and queue behavior according to freshness, loss tolerance and recording requirements. A logging stream may preserve all available data while a control consumer should reject stale observations. Do not force these different requirements into one unexamined default. A value named confidence is not necessarily a calibrated probability. Define its calculation and limitations, and distinguish stale or invalid observations instead of presenting an unexplained reassuring number.
Propagate cancellation through the whole system
Cancellation is incomplete if a filming action stops while downstream path generation or the vehicle adapter keeps sending old targets. In our original exercise, diagram perception, framing, flight commands and supervision, then trace cancellation through every stage. Record normal completion, user interruption, target loss and communication failure as distinct outcomes. Stopping recording and transitioning the aircraft to a conservative state need not be the same decision at the same instant. Replay logs and check for consistent component states. More modules require clearer ownership, not less. Specify whether resumption preserves intermediate state or restarts the task. A subject may have moved during interruption, so blindly returning to an old path can violate the shot assumptions.
YOUR NEXT STEP
Put it into practice.
- Using ROS 2 alone does not establish real-time performance or safety.
- Stopping a node is not confirmation that the aircraft received an appropriate stop instruction.
Sources and editorial scope
Explanations and exercises are original editorial material. Verify product-specific conditions against the linked documentation version.
Research date: 21 October 2026. Check the linked version, supported hardware and applicable conditions. Evidence includes directly reviewed text and official search-index records.
Read the methodology and open questions →