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.

Concept flow

Topics carry typed streams between graph participants

A topic is a named communication path, not a mailbox that permanently stores one latest value.

  1. PUBLISHERproduces typed messages over time
    publish
  2. TOPIC NAMEnamed path visible in the ROS graph
    carries
  3. MESSAGE TYPEdefines the structure of each message
    received by
  4. SUBSCRIBERreacts to arriving messages
    inspect
  5. 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.

Ghostty terminal simulation

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.

Commands worth trying
  • ros2 topic info /scan
  • ros2 topic hz /scan
  • ros2 topic echo /scan --once
  • ros2 topic info /cmd_vel
  • ros2 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.