A computer vision model on its own is just a function: image in, detections out. It becomes useful to a robot only once it’s wired into the rest of the system — publishing results other nodes can react to, on a schedule the rest of the robot can keep up with. ROS2 is where that wiring happens.
Where Vision Fits in the Graph
-
A camera driver node publishes raw image frames on a topic (typically using
sensor_msgs/Image) -
A vision node subscribes to that topic, runs detection or recognition on each frame, and publishes structured results — bounding boxes, classes, confidences
-
Downstream nodes (navigation, manipulation, decision logic) subscribe to those results, with no idea — and no need to know — how the detection actually happened
Practical Considerations
-
Inference rarely runs as fast as the camera publishes frames — the vision node should run in its own thread or process so it doesn’t block the rest of the pipeline
-
Use
vision_msgsfor detection output where possible, so other nodes and tools can consume it without a custom message type -
Keep heavy preprocessing (resizing, normalization) in the vision node itself, close to the model, not scattered across the graph
-
Log detection topics during testing — ROS2 bags make it trivial to replay a run and debug a model’s behavior offline, without the robot in front of you
A Minimal Node Layout
| Node | Subscribes To | Publishes |
|---|---|---|
| camera_driver | — | /camera/image_raw |
| vision_node | /camera/image_raw | /vision/detections |
| decision_node | /vision/detections | /cmd_vel, /robot/state |
None of this depends on any specific model or detection technique — the same node layout works whether the vision node is running a lightweight on-device detector or forwarding crops to a heavier remote model. ROS2’s job isn’t to do the seeing; it’s to make sure whatever the seeing produces reaches the parts of the robot that need to act on it, reliably and on time.
