Unit 04 · lesson
Streaming Data: Why Topics Exist
A topic is not a storage box that permanently holds the latest value.
For the beginner mental model, treat it as a named path over which publishers send typed messages and subscribers receive them.
Topics carry typed streams between graph participants
A topic is a named communication path, not a mailbox that permanently stores one latest value.
- PUBLISHERproduces typed messages over timepublish
- TOPIC NAMEnamed path visible in the ROS graphcarries
- MESSAGE TYPEdefines the structure of each messagereceived by
- SUBSCRIBERreacts to arriving messagesinspect
- EVIDENCEtopic info and echo prove the live path
Turtlesim example
When teleop tells the turtle how to move, the graph includes a command topic such as /turtle1/cmd_vel carrying geometry_msgs/msg/Twist messages from the teleop publisher to the Turtlesim subscriber.
The command is not a direct function call from one program into another. Both nodes participate through the ROS graph.
One-to-many is possible
The official topic tutorial emphasizes that topics are not limited to one publisher and one subscriber. A topic may have multiple publishers and/or multiple subscribers.
That matters because a monitoring tool can subscribe to a topic without replacing the robot node already receiving it.
Topics are usually for ongoing data
Examples include sensor readings, pose updates, velocity commands, camera images, and status streams.
Later you will compare topics to services and actions, which solve different communication problems.
Inspect topic evidence safely
Use the bounded terminal simulation to practice topic evidence commands before treating live robot data as real evidence.
Collect topic evidence safely
Inspect topic type, rate, and one sample message without publishing to a real robot or touching a real ROS 2 graph.
Ghostty Web renders the terminal, but this lesson still uses a controlled Robotnix command engine. No unrestricted operating-system shell is connected.
ros2 topic info /scanros2 topic hz /scanros2 topic echo /scan --onceros2 topic info /cmd_velros2 topic echo /cmd_vel --once
Read a deterministic terminal transcript
This fallback runs the same bounded Robotnix simulation against the suggested command sequence. It does not connect to an operating-system shell or network.
Robotnix ROS 2 topic simulation All messages are simulated and bounded. No real robot command topic is connected. Type 'help' for supported topic evidence commands. $ ros2 topic info /scan Type: sensor_msgs/msg/LaserScan Publisher count: 1 Subscription count: 2 $ ros2 topic hz /scan average rate: 9.94 min: 0.096s max: 0.105s std dev: 0.003s window: 10 $ ros2 topic echo /scan --once header: frame_id: lidar_link angle_min: -3.14 angle_max: 3.14 range_min: 0.12 range_max: 8.0 ranges: [1.4, 1.3, 1.2, 1.1, 1.2] $ ros2 topic info /cmd_vel Type: geometry_msgs/msg/Twist Publisher count: 1 Subscription count: 1 Safety note: simulated evidence only; no robot receives this command. $ ros2 topic echo /cmd_vel --once linear: x: 0.0 y: 0.0 z: 0.0 angular: x: 0.0 y: 0.0 z: 0.0
The terminal is simulated. It does not connect to DDS, a real robot, a real ROS 2 graph, or your host shell.
Write down the topic name, message type, publisher count, subscription count, and one observed sample. That is better evidence than saying "the topic works."
Checkpoint
Label the publisher, topic, message type, and subscriber using the actual names you observed in Unit 3. Then name one CLI command that would provide evidence for the live path.