What is publish/subscribe messaging?

Publish/subscribe (pub/sub) is a messaging pattern where senders (publishers) emit data to named channels without knowing who will receive it, and receivers (subscribers) listen on channels without knowing who sends the data. This decoupling makes it easy to add, remove, or replace components without rewiring the entire system.

What is the difference between a topic and a service in robotics?

A topic is a one-way data stream — publishers push data continuously and subscribers receive it asynchronously. A service is a request/response pattern — one component sends a request and waits for a reply. Topics are used for streaming sensor data, while services are used for discrete actions like setting a parameter or triggering a calibration.

How fast do robot components communicate?

Communication speed depends on the middleware and data size. Shared-memory systems can transfer messages in under a microsecond, while network-based middleware like DDS typically achieves latencies of 0.1 to 5 milliseconds for small messages. Camera images and point clouds take longer due to their size, often 5 to 20 milliseconds per transfer.

The Publish-Subscribe Pattern

If you learn one communication pattern for robotics, make it publish-subscribe (pub/sub). It's used in virtually every robot middleware, including DDS, MQTT, and many other frameworks. Let's understand it from the ground up.

The Core Idea

Pub/sub has three concepts:

Topic — a named channel (like "/camera/rgb" or "/cmd_vel")
Publisher — a node that sends messages to a topic
Subscriber — a node that receives messages from a topic

A publisher writes messages to a topic. Any number of subscribers can listen to that topic. The publisher doesn't know who's listening — it just publishes.

Pub/sub topology — publishers send to a topic, subscribers receive independently — The pub/sub topology: publishers write to named topics, subscribers read from them. Neither side knows about the other — the topic is the only connection point.

Publishing

# Camera node publishes images
publisher = create_publisher(topic="/camera/rgb", type=Image)
 
while True:
    frame = camera.capture()
    publisher.publish(frame)  # Anyone listening will get this

Subscribing

# Detector node receives images
def on_image(image):
    objects = detect(image)
    # ... process
 
subscriber = create_subscriber(
    topic="/camera/rgb",
    type=Image,
    callback=on_image  # Called every time a new image arrives
)

Why Pub/Sub Is Powerful

1. Decoupling

The camera node doesn't import, reference, or depend on the detector. It just publishes to a topic name. You can:

Add a new subscriber (a logger, a recorder, a second detector) without touching the camera code
Replace the camera with a simulated camera that publishes fake images — the detector can't tell the difference
Run the detector on a different machine

2. Many-to-Many

A single topic can have:

Multiple publishers — two cameras publishing to "/camera/rgb"
Multiple subscribers — a detector AND a logger both listening to "/camera/rgb"
Any combination — no special configuration needed

Message flow timeline — showing async delivery to multiple subscribers — Messages are delivered asynchronously. The camera publishes at t=0, the detector receives at t=2ms, and the logger at t=3ms — each processes independently.

3. Asynchronous

Publishers and subscribers run at their own speed. The camera publishes at 30Hz, but the detector might only process at 10Hz. That's fine — the detector just gets the latest message when it's ready (or queues them up).

The Anatomy of a Topic

Every topic has:

Property	Example	Purpose
Name	`/camera/rgb`	Unique identifier, usually hierarchical
Type	`Image`	The message format (fields and their types)
QoS	Reliable / Best-Effort	Delivery guarantees

Topic Naming

Topics use a hierarchical naming convention with / separators:

/camera/rgb           → RGB camera image
/camera/depth         → Depth image
/lidar/scan           → LiDAR point cloud
/perception/objects   → Detected objects
/planning/path        → Planned path
/cmd_vel              → Velocity commands to motors
/diagnostics/cpu      → CPU usage stats

Good naming makes the system self-documenting. Anyone can look at the topic list and understand what data flows where.

Topic hierarchy — tree structure showing how topics are organized by namespace — Topics are organized hierarchically like a file system. This makes it easy to discover data streams and understand the robot's structure at a glance.

Tip

Name topics by what they carry, not who produces them. Use /camera/rgb instead of /camera_node/output. This way, you can swap the camera hardware without renaming topics.

Quality of Service (QoS)

Not all data is equally important. A camera frame can be dropped — the next one arrives in 33ms. But a "stop immediately" emergency command must never be lost.

QoS policies let you configure this per-topic:

QoS Policy	Behavior	Use Case
Best-Effort	Drop messages if subscriber is slow	High-frequency sensor data (cameras, LiDAR)
Reliable	Retry until message is delivered	Commands, configuration, infrequent updates
Keep Last N	Only buffer the N most recent messages	Sensor data where only the latest matters
Transient Local	New subscribers get the last published value	Configuration, map data, static transforms

Note

Most sensor data uses Best-Effort + Keep Last 1. This means: always have the latest data, don't waste time on old frames. Control commands typically use Reliable delivery to ensure nothing is missed.

A Common Mistake: Topic Explosion

Beginners sometimes create too many topics:

/camera/rgb/raw
/camera/rgb/compressed
/camera/rgb/undistorted
/camera/rgb/resized_640x480
/camera/rgb/resized_320x240

This creates confusion. Better approaches:

Use one topic per semantic data stream (/camera/rgb for the main output)
Use parameters to configure whether the output is compressed or not
Create secondary topics only when genuinely different consumers need different formats

What's Next?

Point-to-point vs pub/sub — comparing connection complexity — With direct point-to-point connections, 5 nodes need 10 links (and it gets worse fast). Pub/sub via topics keeps connections linear and clean.

Pub/sub isn't the only communication pattern. In the next lesson, we'll compare it with point-to-point communication and learn when each pattern is the better choice.

Publish-Subscribe Pattern