Real-time robot control means that required computations and I/O complete within specified deadlines with bounded jitter. It does not simply mean a high average frame rate. A 1 kHz loop that occasionally stalls for several milliseconds can be less usable than a slower loop whose worst-case timing fits the plant.
ROS 2 can be part of a real-time system, but determinism depends on the operating system, kernel, scheduling, CPU and interrupt placement, memory behavior, drivers, middleware path, controller code and hardware interface. Non-real-time perception, logging and services should cross a bounded interface rather than execute in the critical loop.
Use this guide with the robot joint-network comparison and motor-driver architecture. Real-time claims require measurements under worst credible load and defined fault responses.
Start from a deadline and consequence of a miss
Define the control period, allowed start jitter, worst execution time, I/O timing and data-age limit. Then define what one missed deadline means: retain a bounded command, reduce performance, stop a controller or enter a safer state. The answer depends on plant speed and hazard.
Soft, firm and hard real-time describe how deadline misses affect usefulness or acceptability; they are not performance badges. Most general robot computers need system-specific evidence. Keep the timing contract with controller configuration so later software changes cannot silently invalidate it.
The hardware loop follows read, update and write
The ros2_control Controller Manager documentation describes the component that manages controllers and hardware interfaces and discusses determinism. A common loop reads hardware state, updates controllers and writes commands at a configured rate.
Timestamp where physical sampling and command application actually occur. Software function entry is not always the sensor capture time. Track state age into the controller and command age at the drive. A loop can execute regularly while consuming stale network data.
| Loop stage | Deadline evidence | Hidden delay | Check |
|---|---|---|---|
| Hardware read | Capture-to-available time | Device or bus queue | Physical timestamp |
| Controller update | Worst execution time | Allocation or lock | Trace duration |
| Hardware write | Command-to-apply time | Network scheduling | Drive timestamp |
| Data exchange | Producer-consumer age | Callback backlog | Sequence counter |
| Fault path | Detection-to-safe state | Service or lifecycle work | Injected miss |
Scheduling policy needs CPU and interrupt design
A real-time thread may use a fixed-priority scheduling policy with suitable permissions, but priority alone is not isolation. Assign CPU affinity and interrupt handling with the full system in mind. A high-priority thread that waits on a lower-priority lock can still miss its deadline.
Measure interference from networking, storage, GPU, camera and background services. Avoid starving essential kernel or safety tasks. Document scheduler, priorities, affinities, power state and firmware so test and deployment machines are equivalent.
Memory faults and allocation create timing tails
Dynamic allocation, page faults, memory reclamation and unbounded container growth can introduce variable delays. Preallocate buffers, lock memory where appropriate, warm relevant code and data paths, and keep message sizes bounded. Do not allocate or free memory in the tight loop without proven behavior.
Memory preparation does not solve cache contention or device DMA interference. Stress the full application and inspect tail latency. Confirm that error paths, parameter changes and controller transitions do not unexpectedly allocate or block while the loop is active.
Blocking I/O and logging belong outside the loop
File writes, console output, synchronous services, DNS, dynamic discovery and waiting for general callbacks are inappropriate inside a hard-bounded update path unless a specific implementation proves a bound. Send compact diagnostics to a lower-priority consumer through a realtime-safe mechanism.
Bound queue length and decide whether new or old data should be dropped. Unbounded logging can shift a timing problem into memory growth. Preserve counters for dropped diagnostics so the system does not appear healthy merely because evidence was discarded.
Realtime-safe buffers separate timing domains
A non-real-time planner can publish a command or trajectory into a lock-free or bounded handoff, and the controller reads the latest complete object without waiting on the producer. State can move outward through another bounded snapshot. Ownership and lifetime must be explicit.
Validate command sequence, timestamp and timeout. If the producer stalls, the inner loop should not repeat an old torque forever. Parameter updates and mode switches also need atomic or staged application so a partially updated configuration never reaches the actuator.
| Operation | In critical loop? | Preferred pattern | Failure policy |
|---|---|---|---|
| Read joint state | Yes | Bounded hardware interface | Detect stale sample |
| Update control law | Yes | Fixed work and memory | Deadline monitor |
| Write actuator command | Yes | Bounded interface | Local timeout |
| Save logs | No | Bounded queue to worker | Drop and count |
| Service or parameter work | No | Stage then swap | Reject invalid transition |
DDS is useful but not the motor current loop by default
DDS and ROS 2 communication can support configurable quality of service and distributed applications, but an inner electrical current loop often runs inside a drive or dedicated controller. Network and executor paths must be measured before they are placed inside a tight joint-control deadline.
Use ROS 2 for orchestration, trajectories, state and higher layers where its timing evidence fits. Keep destructive overcurrent and fast protection local. A middleware choice does not replace drive-level deterministic control or hardware safety circuits.
Tracing exposes rare scheduling and callback delays
ROS 2 documentation includes tracing guidance for analyzing execution. Instrument controller cycles, callbacks, I/O and deadline monitors with low and characterized overhead. Align traces with drive and network logs.
Collect histograms and maxima over long runs rather than a short average. Reproduce CPU, network, storage, thermal throttling and graphics load. Identify which event preceded each tail. A single maximum without trace context is hard to fix, while a percentile without the maximum can hide a dangerous miss.
A real-time kernel is necessary in some systems, not sufficient
A preemptible real-time kernel can reduce scheduling latency, but application locks, drivers, firmware, power management and unbounded code remain. Conversely, a modest plant may meet its deadline on a carefully measured non-RT configuration. Requirements and evidence decide.
Validate BIOS, CPU power states, thermal behavior and driver versions. Retest after kernel, middleware, controller or hardware updates. The production image and deployment configuration should be versioned with the timing report.
Stress tests must include misses and recovery
Run maximum controller count, full network traffic, sensor streams, logging and realistic application load. Add thermal soak, storage activity and error handling. Measure period, execution time, capture-to-control age, command-apply age and consecutive misses.
Inject stale state, controller error, hardware timeout and clock change where supported. Verify the intended deactivation, stop or degraded mode. A real-time loop is operationally useful only when its failure behavior is also bounded.
- Write the period, jitter and data-age contract.
- Keep the read-update-write path bounded.
- Preallocate memory and move blocking work outside.
- Trace tail latency under full production load.
- Define and test behavior for stale data and missed cycles.
Frequently asked questions
Is ROS 2 itself a real-time operating system?
No. ROS 2 is middleware and libraries that can participate in a real-time system when the OS, scheduling, code, drivers and hardware are designed and measured accordingly.
Does DDS make a joint loop deterministic?
Not automatically. Quality of service helps communication semantics, but end-to-end latency, executor scheduling and hardware application time still require evidence.
Is a higher control frequency always better?
No. The plant, sensors, actuator and computation must support it with margin. A faster loop with deadline misses can perform worse.
Can Python run a hard real-time motor loop?
Typical Python execution has sources of nondeterminism and is usually kept outside the tightest loop; use only where measured requirements and architecture permit.
What timing should be measured first?
Measure the complete capture-to-command chain, including period, worst execution, jitter, state age, command-apply delay and missed-cycle recovery.
Real-Time Control Boundary Note
ROS 2 and a real-time kernel do not guarantee determinism by themselves. Validate scheduling, memory, drivers, communication, controller code and hardware I/O under worst-case load and all relevant fault transitions.