Point-to-Point vs Broadcast
Pub/sub is a broadcast pattern — one publisher, many listeners. But not all communication fits this model. Sometimes you need to ask a specific node a question and wait for an answer.
Two Patterns, Two Use Cases
| Publish-Subscribe | Request-Response (Service) | |
|---|---|---|
| Direction | One-to-many | One-to-one |
| Timing | Continuous stream | On-demand |
| Blocking? | No — publisher doesn't wait | Yes — caller waits for reply |
| Best for | Sensor data, commands, state updates | Configuration, computation, one-off queries |
When to Use Pub/Sub
Use pub/sub when:
- Data flows continuously (sensor readings, motor commands)
- Multiple consumers need the same data
- The producer doesn't care who is consuming
- You want fire-and-forget semantics
Examples: camera images, LiDAR scans, velocity commands, robot pose, map updates.
When to Use Request-Response
Use request-response (also called services) when:
- You need a one-time computation (plan a path from A to B)
- You need to query state (what are the current joint positions?)
- You need to change configuration (set the maximum speed to 2.0 m/s)
- The caller needs to wait for the result before proceeding
Examples: path planning request, parameter changes, calibration triggers, map saves.
The Hybrid Approach
Real robots use both patterns together:
Continuous data (pub/sub):
Camera → /camera/rgb → Detector → /objects
LiDAR → /lidar/scan → Mapper → /map
Controller → /cmd_vel → Motors
One-off requests (services):
Navigation ← "plan path A→B" → Path Planner
CLI ← "save map to disk" → Map Saver
Config ← "set max speed" → Controller
The rule of thumb: if data flows continuously, use pub/sub. If you're asking a question, use a service.
Some robot frameworks also have actions — long-running tasks with progress feedback. "Navigate to coordinates (5, 3)" is an action: it takes time, you want progress updates, and you might want to cancel it mid-way. Actions combine the request-response pattern with streaming feedback.
Common Pitfalls
Using services for streaming data
Don't request camera images one at a time through a service. Each call has overhead, and you lose the decoupling benefits. Use pub/sub instead.
Using pub/sub for configuration
Publishing a "set speed" message to a topic seems convenient but has problems:
- How do you know it was received?
- What if multiple nodes try to set different speeds?
- How do you query the current value?
A service call gives you a response confirming the change succeeded.
Mixing blocking and real-time
If your 100Hz control loop calls a service that takes 50ms to respond, your loop drops to 20Hz. Never put blocking service calls in time-critical loops. Either use them in a separate thread or cache the result.
What's Next?
We've seen how nodes can exchange data through pub/sub and services. But what exactly is inside those messages? In the next lesson, we'll look at message types — how data is structured, serialized, and validated.