Tech Brief:

Achieving Real-Time Behaviour with ROS 2

ROS 2 was designed with real-time applications in mind, addressing many of the architectural limitations of ROS 1. However, ROS 2 is not “real-time by default.” Deterministic behaviour depends on executor design, scheduling, middleware configuration, and operating system choices.

Understanding where ROS 2 enables real-time behaviour — and where it does not — is essential for building predictable robotic systems.

Real-Time Latency Breakthroughs

In a 1-kHz ROS 2 teleoperation loop, the ROS-to-ROS median latency is 0.35 ms; unlike ROS 1, ROS 2 eliminates ~2 ms latency spikes, improving execution predictability (reported jitter ~55% per the paper’s jitter metric).

Source: DFKI ROS 2 Real-World Latency Analysi

End-to-end latency is sustained by ROS 2 with IK motion scaling at 1000 Hz control loops, halving worst-case delays vs ROS 1 for industrial telerobotics.

Source: HS-Osnabrück ROS 2 Telerobotics Evaluation

Mastering Real-Time Control in ROS 2

Executor Design: Controlling Execution and Latency

The ROS 2 executor determines how callbacks are scheduled and executed. Its design has a direct impact on latency, jitter and determinism.

Single-Threaded Executor A single-threaded executor offers predictable execution order and minimal context switching. It is easier to analyse and debug, but limits parallelism and can become a bottleneck in complex systems.

Multi-Threaded Executor Multi-threaded executors allow parallel callback execution and better CPU utilisation. However, they introduce scheduling complexity, synchronisation overhead and potential priority inversion if not carefully configured.

Synchronization and Callback Grouping Callback groups define which callbacks may run concurrently. Proper grouping is critical to avoid unintended blocking and to ensure that time-critical callbacks are not delayed by non-critical work.

Quality of Service (QoS): Fine-Tuning Data Flows

ROS 2 introduces QoS profiles to control how data is exchanged between nodes. These settings are essential for predictable communication behaviour.

Key QoS parameters include:

Reliability (reliable vs best-effort)
History and depth (buffer size and message retention)
Durability (late-joining subscribers)
Deadline and latency budget

Misconfigured QoS settings are a common source of latency and jitter in ROS 2 systems.

The Key Insight

ROS 2 provides the mechanisms for real-time behaviour, but not the guarantees. Determinism emerges only when executor design, QoS profiles, OS scheduling and hardware capabilities are aligned.

Practical Actions Engineers Can Take Today

Identify which nodes and callbacks are truly time-critical
Choose executor models deliberately, not by default
Use callback groups to isolate real-time workloads
Configure QoS profiles explicitly for latency-sensitive data
Validate timing behaviour under realistic system load

Real-time issues in ROS 2 systems often appear late — during integration or field testing — when fixes are expensive. Early architectural decisions around executors and QoS significantly reduce risk and improve system stability.