Modular Architecture for ROS 2

• Modular Architecture for ROS 2 is a scalable, plugin-driven framework that decouples robotic functionalities into independent, interoperable nodes.
• It employs standardized interfaces and asynchronous communication via DDS to enable real-time coordination and efficient resource allocation.
• The architecture supports dynamic composition, lifecycle management, and tuned QoS policies to achieve robust deployments in complex robotic systems.

Modular Architecture for ROS 2

The modular architecture of ROS 2 defines a compositional and scalable framework for robotic systems, characterized by a decoupled, plugin-friendly paradigm. Each core functionality—perception, control, planning, interaction—resides in an independently deployable and configurable node or component, bound together at runtime through standardized interfaces, lifecycle management, and data-centric middleware. This modularity is foundational to reliability, distributed deployment, platform independence, and the integration of complex real-time systems spanning research, industrial automation, and large-scale multirobot environments (Macenski et al., 2022).

1. Guiding Architectural Principles

ROS 2 advances modularity through four central principles: distribution, abstraction, asynchrony, and modular isolation. Each major system function (drivers, perception, planning, control, UI) is implemented as a process or nodelet, often deployed across distinct machines, eliminating dependence on a centralized master. All interprocess APIs—topics, services, actions, parameters—are defined using an Interface Description Language (IDL), ensuring strict type safety and enabling middleware (predominantly DDS) abstraction via the “rmw” interface (Macenski et al., 2022).

Event-driven, nonblocking communication informs the asynchrony principle. Nodes are callback-oriented, with timers, message arrivals, service invocations, and lifecycle transitions handled asynchronously. The design mandate, “make each program do one thing well,” leads to nodes encapsulating narrowly focused capabilities, which are composed at runtime. A system may thus mix high-level Python logic with real-time C/C++ components, each plugged into a framework that is “pluggable, remixable, and selectable” at runtime.

2. Core Abstractions: Nodes, Executors, and Components

Three abstractions structure modular deployment:

• Node: The atomic computational element grouping publishers, subscribers, service/action servers/clients, parameters, and timers. Node names and namespaces provide logical modular boundaries.
• Executor: The scheduler for node(s) callbacks and threaded execution. Single-threaded, multithreaded, or custom, permissive of heterogeneity in timing guarantees and resource management.
• Component: Compile-time-shared libraries (plugins) loadable into “component containers” at runtime. Multiple stateless component-nodes can share process resources and intra-process data flow, reducing serialization overhead.

Composition may be effected via launch files or direct C++ API, enabling per-process or shared-container deployment. Intra-process communication via shared pointers achieves zero-copy semantics for high-bandwidth or low-latency requirements.

rclcpp_components::ComponentManager mgr(rclcpp::NodeOptions()); mgr.load_component("my_package", "my_package::DepthFilter"); mgr.load_component("my_package", "my_package::PointCloudMerger");

(Macenski et al., 2022)

3. DDS Abstraction and Quality-of-Service (QoS)

All communication in ROS 2 is abstracted by the “rmw” layer, decoupled from Vendor DDS implementations (Cyclone DDS, Fast DDS, RTI Connext, etc.). QoS settings are first-class and can be tuned per topic:

QoS Policy	Modes	Impact
Reliability	best_effort, reliable	Packet loss tolerance vs. guaranteed delivery
Durability	volatile, transient_local	Message history for late joiners
History	keep_last(N), keep_all	Queue vs. unbounded history
Deadline	time_constraint	Message arrival guarantees
Lifespan	expiration timeout	Max time messages are valid

Formally, for reliability: $$\text{reliability} = \begin{cases} 1, & \text{if policy = reliable}\ p, & \text{if policy = best\_effort and } 0 \leq p < 1 \end{cases}$$

A single C++ API provides policy construction:

rclcpp::QoS sensor_qos(10); sensor_qos.reliable().transient_local().deadline(rclcpp::Duration(0,100000000));

(Macenski et al., 2022)

These policies enable optimization for throughput, determinism, and fault tolerance.

4. Lifecycle Management and State Machines

Nodes may optionally implement the ROS 2 managed lifecycle, exposing deterministic states: Unconfigured, Inactive, Active, and Finalized, with explicit configure(), activate(), deactivate(), cleanup(), and shutdown() transitions. Lifecycle state machines enforce safe system bring-up and tear-down, and enable sophisticated orchestrators to tightly control execution order, hot-swapping, and safe failover.

ASCII lifecycle transitions:

Unconfigured ──configure()──▶ Inactive ──activate()──▶ Active ▲ │ │ │ │ │ │deactivate() │shutdown() cleanup() └─────▶ Inactive ──shutdown()▶ Finalized └────────shutdown()─────────────┘

(Macenski et al., 2022)

Formally, as a directed graph: $$S = \{U,I,A,F\},\quad T = \{(U\xrightarrow{configure}I),(I\xrightarrow{activate}A),\ldots\}$$

Lifecycle nodes are essential for coordinating complex robotic deployments and preventing actuator/sensor hazards that arise from unsynchronized startup.

5. Modular Deployment: Composition and Containers

Nodes as components allow for highly flexible deployment architectures. Using the component container infrastructure (e.g., rclcpp_components), systems may load and compose any mix of stateless nodes into a process at runtime. Launch files (Python or XML) enumerate composable node descriptions and parameters.

Example for two components in a container:

from launch_ros.actions import ComposableNodeContainer ComposableNodeContainer( name='pipeline_container', composable_node_descriptions=[ ComposableNode( package='my_filters', plugin='my_filters::DepthFilter', name='depth_filter'), ComposableNode( package='my_mergers', plugin='my_mergers::PointCloudMerger', name='cloud_merger'), ], output='screen', )

(Macenski et al., 2022)

Benefits include:

• Intra-process zero-copy for large messages (e.g., images, point clouds)
• Lower OS resource consumption
• Runtime reconfiguration: move nodes between containers/processes without code change
• Enhanced real-time performance by collapsing node boundaries where appropriate

6. Modularity, Scalability, and Reliability: Mechanisms and Impact

ROS 2 enforces modularity by requiring well-defined typed message (.msg), service (.srv), and action (.action) interfaces for each node. This permits arbitrary substitution and upgradability of nodes with no change to the remainder of the system.

Scalability is intrinsic due to DDS's peer-to-peer discovery, which can scale to hundreds of robots (e.g., OTTO Motors deployments) and can span both local networks and multi-machine links, including satellite-grade environments. QoS policy tuning further enables operation in lossy or high-latency networks.

Reliability is realized through:

• Managed lifecycle (publishing/actuation only when system is ready)
• DDS-Security plugin: authentication, encryption, access control lists
• Services/actions: exactly-once semantics for commands and goals
• Lifecycle gating: activation sequencing (e.g., activate localization node only after sensor node is ACTIVE)
• Composition: real-time and non-real-time nodes can coexist, enabling mixed-criticality applications

Robustness is enhanced by the guarantee that an arbitrary node can be upgraded, replaced, or redeployed with minimal impact outside its interface contract. Integration of third-party or open-source navigation (SLAM, manipulation, vision) modules is supported via the same modular ethos.

ROS 2's modular architecture thus provides the structural underpinnings for the next generation of scalable, reliable, and maintainable robot systems, from tightly-resourced microcontrollers to cloud-based planners, without rewrites of the core communication or lifecycle infrastructure (Macenski et al., 2022).