ROS 2 Performance Tuning: Executors, QoS, and Backpressure

#ros2 #runtimeperformance

The problem

Robotics systems may show latency spikes even when individual callbacks
are fast. Executor contention, unsuitable QoS, blocking I/O, and
overloaded queues often create the real bottleneck.

What this guide covers

This tutorial focuses on practical architecture and performance
engineering for production systems. The central principle is to measure
the complete pipeline, keep latency-sensitive work close to the
hardware, and make failure states visible to the operator.

Reference architecture

Sensor callbacks → lightweight validation → bounded work queue →
worker/inference nodes → result publisher. Keep blocking disk/network
work outside latency-sensitive callbacks.

Implementation plan

Measure callback duration, message age, queue depth, CPU scheduling, and end-to-end topic latency.
Choose QoS reliability, durability, history, and depth according to each topic's semantics.
Keep callbacks short and avoid synchronous service calls inside high-frequency callbacks.
Use dedicated executors or callback groups when isolation is required and supported by the node design.
Define overload behavior explicitly: drop old sensor samples, reject commands, or reduce optional processing.

Example

# Inspect the effective QoS and topic behavior with ROS 2 CLI tools.\nros2 topic info /scan --verbose\nros2 topic hz /scan\nros2 topic bw /camera/image_raw

The snippets are illustrative starting points, not drop-in integrations.
Match APIs and version requirements to the exact SDK, OS image, hardware
revision, and runtime in your project.

Performance checklist

Measure end-to-end latency, not only one function or model invocation.
Report p50 and p95/p99 latency alongside throughput, memory use, and dropped work.
Bound queues and define what happens when consumers fall behind.
Avoid repeated frame copies and expensive work on Flutter's UI isolate.
Test sustained workloads after the device reaches thermal equilibrium.
Keep UI state, device state, and robot state distinct.
Add timeouts, cancellation, reconnection, and explicit stale-data indicators.
Profile on the actual target hardware using a reproducible build.

Common pitfalls

Reliable delivery can be inappropriate for high-rate data where freshness matters more than replaying old samples.
QoS mismatches can prevent communication entirely.
Increasing queue depth can hide overload while making data increasingly stale.