ROS 2 Nodes, Topics, and Publish/Subscribe

A ROS 2 system is a set of separate programs called nodes. Nodes talk through named topics: a publisher sends messages on a topic, and any number of subscribers receive them, without the publisher knowing who is listening. This loose coupling lets you add a logger or a visualizer without touching the code that produces the data.

LiDAR publish rate Planner processing time per message Planner queue depth Add a visualizer subscriber (RViz)

Publish and subscribe

A node creates a publisher on a topic with a message type, such as /scan with sensor_msgs/LaserScan, and calls publish. Every node that subscribed to /scan gets a copy, through a callback:

$$\text{if } \text{processing time} > \frac{1}{\text{publish rate}}: \quad \text{the queue fills, and the oldest messages are dropped}$$

The queue depth is part of the subscription's quality of service, described two pages on.

What to notice

Adding the visualizer does not change the LiDAR driver at all, which is the point of publish and subscribe. When the planner takes longer per message than the gap between messages, its queue fills and messages are dropped. For a planner that is usually fine, since only the newest scan matters, so a queue depth of 1 is common for sensor data. For commands or events, dropping messages can be a bug, so those use deeper queues or reliable delivery. In the terminal, ros2 topic hz /scan and ros2 node list show this structure on a real robot.