Image courtesy of ros.org
ROS 2 Iron: Real-Time Performance Improvements and New Safety-Critical Profiles
ROS 2 Iron release introduces deterministic executor profiles, improved DDS configuration for latency-sensitive applications, and a new safety-critical node lifecycle specification that integrates with IEC 61508 development processes.
ROS 2 Iron: What Robotics Systems Engineers Need to Know
ROS 2 Iron (released Q1 2025) is a Long-Term Support release — the first since Humble. For robotics systems engineers building production autonomous systems, the Iron release contains meaningful improvements in three areas that matter for safety-critical applications.
Deterministic Executor
The default ROS 2 executor has long been a source of unpredictable callback scheduling behaviour. Iron introduces a Deterministic Executor that provides bounded worst-case callback latency for a specified set of registered callbacks, with a formal guarantee that callbacks execute in priority order within each scheduling period.
The caveat: the Deterministic Executor requires explicit priority assignment for all callbacks in the node, and degrades gracefully (to bounded but non-deterministic behaviour) rather than failing if a deadline is missed. For hard real-time applications, this is not a replacement for a real-time OS with appropriate configuration — but for soft real-time robotics applications (perception pipelines, planning components), it significantly improves predictability.
DDS Configuration for Latency
Iron ships with validated DDS profiles for common robotics latency targets: 1ms, 5ms, and 10ms end-to-end communication latency on typical local Ethernet networks. The profiles tune QoS parameters (history depth, reliability mode, batch size) for each target. For teams that have been hand-tuning DDS configuration, these starting points reduce the empirical tuning burden significantly.
Safety-Critical Node Lifecycle
A new specification defines a safety-critical node lifecycle with explicit managed states, required health monitoring interfaces, and diagnostic topic publication requirements. Nodes implementing the safety-critical lifecycle are interoperable with health monitors that can trigger system-level responses (graceful degradation, safe stop) based on node health state.
This is a step toward the kind of system-level health management that safety-critical robotics deployments require, and provides a standard interface that monitoring tools can target rather than requiring per-system integration.