Modular Architecture for ROS2

• Modular ROS2 architectures are designs that use independently deployable nodes communicating via topics, services, and actions to build scalable systems.
• They utilize standardized interfaces and plugins to enable dynamic runtime reconfiguration and seamless integration across diverse hardware platforms.
• Practical applications include autonomous navigation, swarm robotics, and cloud-edge integration, facilitating rapid prototyping and robust empirical validation.

A modular architecture for ROS 2 comprises independently deployable, loosely coupled software modules—encapsulated as ROS 2 nodes, components, or plugins—interoperating via ROS 2 topics, services, and actions under the Data Distribution Service (DDS) middleware. This approach enables rapid prototyping, scalable integration, hardware abstraction, and runtime reconfiguration across a diverse range of robotic platforms and domains. Modular architectures in ROS 2 support research and commercial applications including autonomous navigation (e.g., deep reinforcement learning), swarm robotics, cloud-edge robotics, flexible controllers, and complex multi-robot assemblies.

1. Foundations and Design Principles

The re-architecture of ROS 2 was driven by explicit goals of distribution, abstraction, asynchrony, and modularity. Problems are decomposed into independent, message-driven modules—typically as ROS 2 nodes or composable components—each fulfilling a narrowly-defined responsibility such as sensing, perception, actuation, behavior, or planning (Macenski et al., 2022). These modules exchange data via strictly defined interfaces: asynchronous topics for many-to-many streaming, services for synchronous request-response, and actions for managed long-lived goals. All communication occurs over DDS, allowing dynamic discovery, fine-grained Quality-of-Service (QoS), and decentralized operation.

A core design tenet is that each module provides a well-specified contract (message/service/action definitions), may be replaced or extended independently, and can be composed dynamically at runtime. Plugin mechanisms (e.g., pluginlib in C++, Python class loaders) and component containers allow for dynamic module loading, unloading, and in-process composition for performance or certification requirements. Node and component models are central to this approach, enabling the same codebase to run on microcontrollers, embedded companions, or workstation-class hardware.

2. Canonical Layered Architectures and Modular Patterns

Several large-scale frameworks exemplify modular patterns in ROS 2, illustrating distinct layering, messaging, and extensibility.

Example: Navigation with Deep RL (PIC4rl-gym)

PIC4rl-gym implements a five-module stack for autonomous robot navigation using DRL (Martini et al., 2022):

• Gazebo Simulation Wrapper (gazebo_interface): Spawns robot URDFs, interfaces with Gazebo services (reset, pause, entity state), and mediates standard simulation topics (LaserScan, Images, Odometry).
• Sensor Interface Layer (sensor_manager): Normalizes heterogeneous raw sensor streams to a unified observation format, parameterized in YAML (e.g., LiDAR beam count, camera resolution).
• DRL Agent & Environment Node (pic4rl_training, pic4rl_environment): Fuses environment and agent, exposes Gym-like APIs (reset, step), parameterizes learning algorithms, and applies policy actions.
• Control & Motor Command Executor (action_executor): Adapts normalized action vectors to real-world cmd_vel commands; optional for agent pipelines.
• Benchmark & Metrics Module (pic4rl_tester): Collects raw and task-specific data from Odometry, scan, and command topics, computes and records metric sets for evaluation and comparison.

Node interconnections are realized strictly via topics (e.g., /scan, /cmd_vel), with parameterization and extensibility mediated by YAML configs and runtime command-line overrides.

Example: Swarm Robotics (ROS2swarm)

ROS2swarm demonstrates layered modularity for swarm behaviors (Kaiser et al., 2024):

• Hardware Abstraction Layer (HAL): A ‘HardwareProtectionLayer’ node intercepts raw sensor and actuator data, enforcing safety invariants via potential-field collision avoidance.
• Primitive Behavior Library: Each swarm primitive (e.g., aggregation, dispersion, majority rule) is realized as a ROS 2 lifecycle node in a plugin-style Python class hierarchy. Nodes are independently reusable; concrete behaviors override a single compute callback.
• Composition and Task Layer: Complex behaviors are authored by combining movement and voting primitives, orchestrated at launch via namespace, parameter, and remapping configurations.
• Extensibility: New primitives (e.g., MyNewPattern) are introduced by subclassing and parameterization without changes to system-wide logic.

Example: Distributed, Heterogeneous Modularity (MoonBots)

The MoonBots platform applies a strict component-block pattern, where each logical node is decomposed into Core, Injection, Overrides, API, Interface, Executor, and Comm blocks (Neppel et al., 3 Nov 2025). Communication leverages both DDS and Zenoh middleware, enabling mesh and brokered topologies for cross-robot, cross-network data-flow. The architecture separates control logic, transport, and hardware specialization, enabling dynamic reconfiguration—new hardware or module types require only updates to Injection/Override classes or robot assembly templates.

Example Table: Typical Modular ROS 2 Layers

Layer	Example Nodes	Primary Interface Types
Simulation/Abstraction	gazebo_interface, sensor_manager	Topics, Parameters
Perception/Localization	lidar_node, ekf_node	Topics
Control/Planning	traj_planner, controller	Actions, Topics, Parameters
Actuation/Execution	action_executor, cmd_mux	Topics, Services
Monitoring/Evaluation	metrics_node, logger	Topics, Files, TensorBoard Logs

3. Module Interfaces, Parameterization, and Integration

Each module in a modular ROS 2 architecture declares explicit ROS interface contracts:

• Topics: For streaming sensor data, control signals, policies, or metrics using message definitions (e.g., sensor_msgs/LaserScan, nav_msgs/Odometry).
• Services: For transactional operations—world resets, setpoints, or mode switches (e.g., gazebo/reset_world, custom service types).
• Actions: For long-duration behaviors needing periodic feedback or cancellation (e.g., trajectory following or task execution).
• Parameters: All module configuration (hardware types, sensing parameters, algorithmic hyperparameters) resides in YAML, Python launch arguments, or ROS parameter APIs, supporting on-the-fly overrides and runtime reconfiguration.

Modules encapsulate their internal logic, expose only the necessary configuration interfaces, and can be hot-swapped or extended without perturbing unrelated system components.

Specific examples from PIC4rl-gym:

• Adding a robot: Drop new URDF/SDF in models/; update the robot selection in the YAML parameter block; all sensor and control nodes reuse the schema unmodified.
• Swapping sensors: Extend the sensor config YAML (activate new sensor, define topics and processing param), write a new plugin, and launch via sensor_manager.
• DRL training hyperparameters: Overridable by command-line (--ros-args -p algorithm:=TD3 -p gamma:=0.98 ...) or YAML config.

In ROS2swarm, each pattern is parameterized via robot-specific YAML and loaded by node class at startup; extension requires only subclassing and parameter injection.

4. Mathematical Foundations and Algorithmic Isolation

Modular architectures in ROS 2 facilitate the separation of environment/plant dynamics from learning or control algorithms.

Example: DRL Environment/Augmentation (PIC4rl-gym)

The agent-environment interface formalizes the Markov Decision Process: $$\mathcal{M} = (\mathcal{S},\mathcal{A},\mathcal{P},R,\gamma), \quad s_{t+1}\sim \mathcal{P}(\cdot\mid s_t,a_t), \quad r_t = R(s_t,a_t)$$ with the objective

$$\pi^* = \arg\max_{\pi_\theta} \mathbb{E}_{\tau\sim\pi_\theta}\Bigl[\sum_{t=0}^T \gamma^t r_t\Bigr]$$

Losses and updates for DDPG/TD3-style agents: $$L_{\rm critic}(\phi) = \mathbb{E}_{(s,a,r,s')\sim\mathcal{D}}[(Q_\phi(s,a) - y)^2], \quad y = r + \gamma\,Q_{\bar\phi}(s',\mu_{\bar\theta}(s'))$$

$$L_{\rm actor}(\theta) = -\mathbb{E}_{s\sim\mathcal{D}}[ Q_{\phi}(s,\mu_\theta(s)) ]$$

Soft Actor-Critic policy update: $$J_\pi(\theta) = \mathbb{E}_{s\sim\mathcal{D},\,a\sim\pi_\theta}[\alpha\log\pi_\theta(a|s) - Q(s,a)]$$

This isolation of mathematical logic enables swapping agent architectures, reward structures, or environment dynamics without modification to the wrappers or interface code.

In modular control frameworks (e.g., (Risi et al., 13 Jan 2026)), the reference generator component absorbs all logic for input validation and trajectory interpolation, delegating control law implementation to downstream controllers (e.g., PD+gravity compensation, Cartesian pose, admittance)—maximizing reuse and compositionality.

5. Runtime Composition, Deployment, and Reconfiguration

A critical property of modular ROS 2 architectures is support for dynamic runtime composition:

• Composability and Launch: Nodes and components can be dynamically loaded into a ComponentManager, allowing in-process communication (zero-copy), reduction in startup times, and ease of deployment.
• Launch Configuration: Entire robot stacks are parameterized by launch files, enabling the rapid switch among simulated and real hardware, new robot or sensor variants, or alternative scheduling/policy modules.
• Plugin Discovery: Components such as controllers, estimators, or behaviors are loaded dynamically at runtime according to parameter lists in YAML or command-line launch arguments. C++ plugins are registered via PLUGINLIB_EXPORT_CLASS or similar macros; Python classes via class-loader constructs.
• Process/Container Model: For large systems, containers orchestrate deployment of multiple nodes (possibly in separate processes or on distributed hosts), governed by workload distribution, hardware affinity, and safety constraints.

Concrete workflow examples from PIC4rl-gym and ROS2swarm include:

• Launching a new navigation scenario by composing Gazebo, gazebo_interface, sensor_manager, training, action_executor in a single Python script with component-specific arguments (Martini et al., 2022).
• In ROS2swarm, launch scripts glue together primitives, allocate namespaces, and establish robot counts and remappings.
• Runtime parameter overrides via --ros-args ensure flexible experimentation.

6. Validation, Extensibility, and Empirical Results

Empirical validation of modular ROS 2 architectures focuses on adaptability, scalability, and reproducibility:

• Performance Metrics: Evaluation modules log metrics such as success rates, traversal times, path length, dynamic clearances, velocity statistics, and aggregate results to CSV and TensorBoard.
• Reproducibility: All YAML parameter sets, configuration files, and launch scripts are version-controlled to ensure experiments are precisely repeatable. Using ROS 2’s /clock and use_sim_time, researchers can synchronize time, enabling consistent simulation and hardware-in-the-loop transitions.
• Extension Patterns: Adding new robot hardware, sensor modalities, or control primitives involves only localized changes—often limited to extending a YAML parameter, subclassing a base plugin, or adding a configuration file.

Results in (Martini et al., 2022) confirm that trained navigation policies generalize across robot platforms and tasks by plugging in new models and sensors, with negligible overhead for system-level changes. In swarm robotics, entire new primitives or swarm coordination algorithms are hot-swappable, supporting comparative evaluation and rapid iteration (Kaiser et al., 2024). These patterns generalize across domains: from single-robot continuous control to large-scale distributed swarm and multi-robot space assemblies.

7. Synthesis and Impact Across Domains

Modular architectures in ROS 2 have demonstrably accelerated development in autonomous navigation, multi-robot coordination, swarm robotics, and cloud–edge–robotics integration (Martini et al., 2022, Kaiser et al., 2024, Neppel et al., 3 Nov 2025). They provide a principled framework supporting decoupling of software responsibilities, hardware abstraction, and flexible experimentation. The impact includes:

• Facilitation of Sim-to-Real Transfer: Strict separation of hardware interfaces, environment dynamics, and behavior controllers enables swapping between simulated and real deployments with minimal change.
• Hardware and Platform Agnosticism: Through abstraction and parameterization, identical agent/behavior/estimator modules can be reused across diverse robot platforms.
• Scalability and Maintainability: Clear interface boundaries and plugin-based extensibility support large engineering teams, distributed deployments, and the evolution of new hardware lines or control paradigms.
• Empirical Rigor: Modular evaluation and logging modules enable rigorous benchmarking and reproducibility of academic and industrial robotics experiments.

The convergence on modular, component-based ROS 2 architecture underpins rapid innovation and reliable, maintainable robotics systems in both research and production at scale.