Latency & Real-Time
Your robot's camera captures an image. The detector finds an obstacle. The controller generates a "stop" command. How long does this chain take? And is that fast enough?
What Is Latency?
Latency is the time delay between a cause and its effect. In robotics, we care about several types:
| Type | Measures | Typical Range |
|---|---|---|
| Sensor latency | Time from physical event to data arriving in software | 1-50ms |
| Communication latency | Time to pass a message between nodes | 0.001-10ms |
| Processing latency | Time to compute a result (detection, planning) | 1-500ms |
| End-to-end latency | Total time from sensor event to actuator response | 10-1000ms |
For our ball-following robot, the chain might look like:
Camera capture: 10ms
Image transmission: 1ms
Ball detection: 15ms
Command transmission: 1ms
Motor response: 5ms
─────────────────────────
Total: 32ms
32ms means the robot's behavior lags reality by about 1/30th of a second. For a slow-moving indoor robot, that's fine. For a drone flying at 20 m/s, that's 64cm of travel — enough to miss a turn.
What Does "Real-Time" Mean?
"Real-time" doesn't mean "really fast." It means deterministic — you can guarantee that something will happen within a fixed time window.
There are two levels:
Hard Real-Time
The deadline must never be missed. If the motor controller promises to update at 1kHz (every 1ms), it must deliver every single cycle. Missing one could mean an industrial arm overshoots its target or a drone falls from the sky.
Hard real-time requires:
- Special operating systems (RTOS) or Linux with RT patches
- No garbage collection pauses
- No unbounded memory allocation
- Careful thread scheduling
Soft Real-Time
Most deadlines are met, occasional misses are tolerable. A camera processing pipeline at 30fps is soft real-time — dropping a frame occasionally is fine, dropping half the frames is not.
Most robot nodes run at soft real-time. Only the lowest-level control loops (motor drivers, safety systems) need hard real-time.
A common misconception: "real-time" ≠ "low latency." A system that responds in 100ms every time, consistently, is real-time. A system that responds in 1ms usually but occasionally takes 500ms is not — even though it's typically faster.
Communication Speed Comparison
How fast are different communication methods?
| Method | Latency | Bandwidth | Use Case |
|---|---|---|---|
| Shared memory | 0.05-1 μs | Memory speed (~10 GB/s) | Same-machine, high-performance |
| Unix socket | 5-50 μs | ~1 GB/s | Same-machine, traditional |
| UDP (local) | 50-200 μs | ~100 MB/s | Same-network |
| TCP (local) | 100-500 μs | ~100 MB/s | Reliable same-network |
| TCP (internet) | 1-100 ms | Varies | Cloud, remote |
| DDS (same machine) | 50-500 μs | ~500 MB/s | DDS-based middleware |
| HTTP REST | 1-50 ms | Low | Web APIs |
Notice the huge gap: shared memory is 1000x faster than traditional network communication. For a robot with 10 sensors publishing at 100Hz each, communication overhead matters.
Jitter: The Hidden Enemy
Latency is the average delay. Jitter is the variation in delay. A system with 5ms average latency but 0-50ms jitter is worse for control than a system with 10ms average and 9-11ms jitter.
Why? Control algorithms assume regular timing. If the motor controller expects new commands every 10ms and they arrive at 5ms, 15ms, 3ms, 20ms — the robot jerks and oscillates.
When evaluating a communication system, look at both the median latency (typical case) and the 99th percentile (worst case). For real-time control, the 99th percentile matters more than the median.
Practical Guidelines
Here's what latency requirements look like for common robot subsystems:
| Subsystem | Required Rate | Max Latency | Real-Time? |
|---|---|---|---|
| Motor control loop | 1-10 kHz | 0.1-1 ms | Hard |
| Safety/emergency stop | 1 kHz | 1 ms | Hard |
| IMU integration | 200-1000 Hz | 1-5 ms | Hard |
| LiDAR processing | 10-40 Hz | 25-100 ms | Soft |
| Camera processing | 15-60 Hz | 33-66 ms | Soft |
| Path planning | 1-10 Hz | 100-1000 ms | Soft |
| Map updates | 0.1-1 Hz | 1-10 s | No |
| User interface | 30-60 Hz | 16-33 ms | No |
The lesson: different parts of your robot have very different timing needs. A good architecture lets each subsystem run at its own rate without blocking others.
What's Next?
Module 2 is complete! You now understand how robot nodes communicate: the pub/sub pattern, when to use services, how messages are structured, and why latency matters. In Module 3, we'll tackle one of robotics' most important questions: "Where am I?" — the world of coordinate frames and transforms.