Why Communication Matters
In Module 1, we built a ball-following robot with four nodes: camera, detector, controller, and motor driver. We drew arrows between them showing data flow. But we hand-waved the actual mechanism — how does an Image message get from the Camera Node to the Ball Detector?
This question might sound boring. It isn't. Communication is arguably the most critical piece of robot software. Get it wrong and your robot is blind, slow, or dead.
The Real Cost of Bad Communication
Consider these failure modes:
Too slow: Your LiDAR detects a wall 2 meters ahead, but the scan takes 200ms to reach the controller. At 1 m/s, the robot has traveled 20cm in that time. If the processing adds another 100ms, you've lost 30cm of stopping distance. For a fast-moving robot, that's the difference between stopping and crashing.
Too unreliable: Your path planner sends motor commands, but one in every hundred messages gets dropped. Most of the time, the robot drives smoothly. But occasionally, it misses a "slow down" command right before a turn — and drives off course.
Too unstructured: Your camera publishes raw bytes. The detector expects a width, height, and pixel format. But there's no agreement on the format — did the camera send RGB or BGR? Is it 640×480 or 1280×720? The detector crashes on unexpected data.
A well-designed communication system solves all three problems: it's fast enough for real-time control, reliable enough to not lose critical messages, and structured enough to prevent format mismatches.
What We Need
A good robot communication system must be:
- Fast — Sub-millisecond latency for control loops, sub-second for perception
- Typed — Messages have a defined structure that both sender and receiver agree on
- Decoupled — Senders don't need to know about receivers (and vice versa)
- Scalable — Works with 4 nodes on one computer or 40 nodes on a network
- Observable — You can inspect what data is flowing and where
The Approaches
There are several ways nodes can communicate:
| Approach | How it works | Used for |
|---|---|---|
| Publish-Subscribe | Broadcast messages to named channels | Most robot data (sensors, commands) |
| Request-Response | Ask a question, get an answer | Configuration, one-time queries |
| Shared Memory | Multiple processes read/write the same memory region | High-bandwidth, same-machine data |
| Network Sockets | TCP/UDP over the network | Multi-machine robots |
Most robot frameworks use publish-subscribe as the primary pattern, with the others available for special cases. We'll focus on pub/sub in the next lesson.
What's Next?
In the next lesson, we'll dive into the publish-subscribe pattern — the most common way robot nodes communicate. You'll understand exactly how topics work, why they're so powerful, and when to use (or avoid) them.