ROS2: A Robust Robotics Framework

• ROS2 is a next-generation open-source robotics middleware featuring a distributed, modular design with peer-to-peer discovery and secured DDS communication.
• It employs a layered software stack with flexible node composability and tailored Quality of Service policies to optimize real-time performance and communication efficiency.
• ROS2 has been successfully deployed in domains like industrial automation, aerial swarms, and autonomous vehicles, supporting robust multi-robot operations with integrated security.

ROS 2 is the second generation of the Robot Operating System, an open-source robotics software development kit distributed under the Apache 2.0 License and redesigned from the ground up to preserve the modularity and ecosystem advantages of ROS 1 while addressing production-grade requirements such as security, real-time and embedded support, multi-robot deployment, robust networking, cross-platform operation, and higher software quality (Macenski et al., 2022). Architecturally, it is a distributed, interface-driven middleware and application framework built around nodes, typed communications, middleware abstraction, and deployment flexibility; in practice, it has become a common substrate for research and deployment across industrial automation, field robotics, cloud robotics, manipulation, autonomous driving, and multi-robot systems (Macenski et al., 2022).

1. Historical rationale and redesign

ROS 2 emerged from the recognition that ROS 1 had been highly effective as a research platform yet lacked many features needed for deployed robotic systems. Reported limitations included the central master as a single point of failure, weak robustness on lossy links such as Wi‑Fi or satellite connections, no built-in security, limited support for large-scale embedded systems, Linux-only platform support, and an execution and parameter model that constrained extensibility (Macenski et al., 2022). The redesign therefore replaced the central name server architecture with peer-to-peer discovery, introduced a swappable middleware layer, and reworked core assumptions around process composition, communication quality, and deployment.

Early adoption pressure came from domains that could not tolerate ROS 1’s centralization and communication assumptions. In RoboCup, ROS 2 was attractive because it offered built-in support for real-time processing, suitability for embedded systems and multi-robot systems, and native node composition into a single process, reducing communication overhead on minimal hardware (Scheunemann et al., 2019). In collaborative industrial automation, ROS 2 was adopted as a communication backbone precisely because distributed cells spanning many computers and devices were “not robust” under ROS 1-style central coordination, leading to hub-based architectures and ROS1–ROS2 bridging patterns (Erős et al., 2019). In aerial swarms, ROS 2 was selected because swarm intelligence is inherently distributed, while many practical systems still depended on centralized routing, external localization infrastructure, or off-swarm control; DDS auto-discovery and peer-to-peer communication were therefore treated as a better fit for robots that should join, leave, and communicate without a central master (Queralta et al., 2021).

2. Core abstractions and software stack

At the application level, ROS 2 organizes software around nodes, which encapsulate publishers, subscriptions, services, and actions. Topics implement typed asynchronous publish-subscribe exchange; services implement request-response; actions package goal submission, feedback, and cancellation for long-running tasks; and parameters are accessed through service calls with declared and enforced types rather than inferred ones (Macenski et al., 2022). Nodes are no longer restricted to one node per process: multiple nodes can coexist in one process, lifecycle nodes can transition through states such as Unconfigured, Inactive, Active, and Finalized, and interface definitions are written in ROS IDL .msg or OMG IDL .idl and compiled into language-specific code (Macenski et al., 2022). The software stack is layered: client libraries such as rclcpp and rclpy sit above the common rcl C layer, which in turn sits above rmw, the middleware abstraction that connects ROS 2 to concrete transports such as DDS (Macenski et al., 2022).

Composition is not an incidental optimization but a core architectural feature. ROS 2 allows node design to be separated from deployment topology, so the same logical components can run in one process, across several processes, or on different machines (Macenski et al., 2022). This matters because intra-process communication can bypass much of the middleware path. In a RoboCup image-processing benchmark on an Odroid-XU4, a simple camera-to-Sobel pipeline had a median end-to-end processing time of 28.7 ms when nodes ran as stand-alone executables, 28.4 ms when composed without intra-process communication, and 20.7 ms when composed with intra-process communication enabled; the IPC-enabled case also showed a distinctly narrower timing distribution (Scheunemann et al., 2019). A plausible implication is that ROS 2’s modularity does not necessarily imply high overhead, provided composition and intra-process transfer are used deliberately.

3. Middleware, QoS, and execution semantics

ROS 2’s communication substrate is defined by the rmw interface and is usually backed by DDS, which was selected because it already provided distributed discovery, UDP-based transport, QoS controls, and a built-in security standard (Macenski et al., 2022). QoS is central to the architecture. The standard policies emphasized in the design literature are reliability, durability, history, deadline, lifespan, liveliness, and lease duration; together they let users tune the trade-off between guaranteed delivery, data freshness, storage persistence, and liveliness monitoring in networks that may be wired, wireless, lossy, or intermittent (Macenski et al., 2022). Current middleware research treats DDS as the default standardized backend while also comparing it with Zenoh, a session-centric alternative oriented toward heterogeneous and resource-constrained environments (Lee et al., 1 Jul 2026).

The execution model is similarly layered and nontrivial. Real-time analyses of ROS 2 distinguish client-library callbacks from OS scheduling and study the executor as a middleware-level scheduler in its own right. The standard runtime includes single-threaded, multi-threaded, and static single-threaded executors (Casini et al., 22 Dec 2025). In the single-threaded executor, a wait set is polled, callbacks are processed non-preemptively, and default ordering prioritizes timers, subscriptions, service requests, service replies, and waitables; within each type, registration order matters (Casini et al., 22 Dec 2025). In the multi-threaded executor, parallelism is regulated by callback groups that are either mutually exclusive or reentrant (Casini et al., 22 Dec 2025). This makes ROS 2 analyzable, but not equivalent to a classical priority scheduler.

Survey work has abstracted these behaviors into three structural dimensions: Space, Time, and State. Space is location transparency, Time is temporal predictability, and State is contextual continuity under node churn and intermittent connectivity (Lee et al., 1 Jul 2026). The same survey argues that these dimensions compete for the same bounded execution, bandwidth, and memory resources, leading to conflict pairs such as Space–Time and Time–State. It formalizes some of the scaling pressure with expressions such as $O(E \times P)$ for total transfer count in a unicast domain, where $E$ is the number of endpoints and $P$ is the number of participants, and $O(P^2)$ for DDS discovery traffic with participant count $P$ (Lee et al., 1 Jul 2026). In that framing, ROS 2 middleware is not merely a transport substrate but the architectural locus where discovery, data exchange, and state management interact.

Empirical work shows that these trade-offs appear in practice. In a ROS 2-based automated driving system running on a real vehicle computer, comparative DDS experiments at 10 Hz found latency below 2 ms across most scenarios, with maximum packet loss of 0.88% and 0% loss in most cases; CycloneDDS was selected for deeper evaluation because it looked best in packet loss and latency variance (Kouril et al., 2024). The same study also showed that 100 Hz traffic with 512 kB–2 Mb messages exposed publisher-side overload and DDS serialization bottlenecks rather than merely subscriber-side packet loss (Kouril et al., 2024). In dynamic mesh networks, middleware choice becomes even more consequential: a multi-robot exploration study reported that Zenoh used 4.01× less bandwidth and 4.03× less CPU than standard FastDDS in the tested mesh scenario, making middleware overhead itself a first-order systems concern (Chovet et al., 2024).

4. Security, safety, and operational assurance

Security in ROS 2 is built on DDS-Security, but the ecosystem has emphasized that deployability depends on usable tooling. SROS2 provides that usability layer by adding graph introspection, keystore generation, policy generation, artifact generation, and monitoring to ordinary ROS 2 workflows (Vilches et al., 2022). Its methodology is organized into six steps—Modeling, Authentication, Authorization, Generation, Deployment, and Monitoring and mitigation—and it introduces ROS-native security concepts such as enclaves, plus Identity CA and Permissions CA material, while generating artifacts such as governance.xml and permissions files from ROS graph observations (Vilches et al., 2022). Underneath, the paper ties authentication to a PKI with RSA or ECDSA and DH or ECDH key establishment, and describes message authentication and encryption in DDS-Security terms through AES-GMAC and AES-GCM (Vilches et al., 2022). The stated goal is not only confidentiality and integrity, but least-privilege, enclave-based isolation expressed in familiar ROS 2 abstractions.

The broader ROS 2 design literature treats security as one of the decisive breaks from ROS 1. DDS-Security provides authentication, access control, and encryption, while SROS2 adds credential generation and policy tooling; at the product-readiness end of the spectrum, the ROS 2 review literature cites Apex.AI’s ISO 26262 functional safety certification of ROS 2–based autonomous vehicle software as evidence that the stack can support safety-critical engineering processes (Macenski et al., 2022). For deployments that exceed the assumptions of a trusted local DDS network, ROS 2 has also been extended outward. FogROS2-SGC introduces globally unique, anonymous, location-independent 256-bit identifiers for selected ROS 2 topics, routing them through SGC proxies and routers instead of trying to merge DDS domains across the Internet; the system is designed to preserve isolation and topic-level access control while remaining agnostic to ROS 2 distributions and DDS vendors (Chen et al., 2023). In its reported experiments, FogROS2-SGC was 19× faster than rosbridge for 8000-byte messages and was demonstrated across robots and compute nodes approximately 3600 km apart (Chen et al., 2023).

5. Deployment patterns and uses in practice

ROS 2’s practical range is unusually broad. The survey of fielded systems documents its use in Ghost Robotics quadrupeds, where about 90% of the software ran on ROS 2 on an Nvidia Jetson Xavier; in Auterion’s aerial systems, where rosbag2, rviz2, and Gazebo were central to debugging and validation and roughly 22,000 simulated hours were flown in 2021; in NASA’s VIPER lunar rover operations and simulation environment; and in OTTO Motors fleets, where the move from ROS 1 to ROS 2 enabled deployments of 100+ robots and supported more than 2 million hours of operation and 1.5 million km traveled (Macenski et al., 2022). These examples show ROS 2 less as a single “robot framework” than as a family of architectural conventions reusable across land, sea, air, space, and warehouse autonomy.

Several research domains sharpen specific deployment patterns. In collaborative industrial automation, ROS 2 has been used as the inter-hub communication backbone in systems that retain ROS 1 assets locally, with static one-directional bridges between ROS1 hubs and ROS2 hubs and a supervisory Sequence Planner coordinating commands and state across heterogeneous devices and computers (Erős et al., 2019). In aerial swarms, ROS 2 has been combined with batman-adv Wi‑Fi mesh networking and UWB-based ranging and communication, using DDS auto-discovery over the mesh for peer detection while reserving UWB for one-to-one ranging and lightweight situated signaling (Queralta et al., 2021).

Other works show how ROS 2 acts as an integration substrate for modalities that are not traditionally “ROS-native.” Quest2ROS2 is an open-source framework for bi-manual VR teleoperation in which the Meta Quest side streams controller poses and button states into ROS 2 via ROS-TCP-ENDPOINT, while per-arm controller nodes derived from BaseArmController publish Cartesian end-effector targets, visualization markers, gripper commands, and pause/reset behavior (Li et al., 26 Jan 2026). OpenPodcar2 uses ROS 2 as the common contract between a real low-cost autonomous vehicle and its Gazebo simulation: both expose the same /cmd_vel, odometry, TF, image, point-cloud, and scan interfaces, while RTAB-Map and nav2 sit above that common layer (Soni et al., 27 Apr 2026). In both cases, ROS 2’s role is not just messaging but stable interface preservation across simulation, hardware, teleoperation, and autonomy.

At the control and manipulation end, ROS 2 has also become a host for high-rate and industrial interfaces. A Fanuc CRX hardware interface based on ros2_control and Ethernet/IP exposes the robot to standard ROS 2 controllers and MoveIt2, with an observed effective control frequency of about 24 Hz and an average command-to-feedback delay of about 0.31 s; the paper concludes that this is suitable for planned motion execution and speed adaptation, but not for high-bandwidth external closed-loop control such as force or admittance control (Franceschi et al., 17 Jun 2025). At a much higher control rate, multipanda_ros2 provides a ROS 2 Humble framework for controlling multiple Franka robots from a single process through ros2_control, sustaining a 1 kHz torque loop and reporting average controllet-switching delays of about 2.117 ms (Škerlj et al., 2 Feb 2026). Together, these examples illustrate that ROS 2 spans both medium-rate industrial orchestration and genuinely high-rate torque-control research, albeit with different architectural constraints.

6. Limitations and research directions

ROS 2’s strengths are paired with persistent technical limits. The general design review notes that default DDS configurations are not particularly effective for messages larger than 1 MB because of small UDP buffers, fragmentation, and retransmission costs, and explicitly recommends composition and intra-process communication to reduce large-message overhead (Macenski et al., 2022). The real-time survey likewise concludes that default executors remain problematic for hard timing analysis because of polling-induced delays, wait-set semantics, callback-group constraints, and middleware-induced delays, even though a substantial body of work now exists on customized executors, DDS-delay analysis, and micro-ROS support (Casini et al., 22 Dec 2025). A plausible implication is that ROS 2 is best treated as a flexible timing-aware substrate rather than as a hard-real-time runtime by default.

Two active research directions attempt to make these limitations more observable and more enforceable. Trace-enabled timing-model synthesis for ROS 2 uses eBPF probes on ROS 2 middleware functions and Linux scheduler events to reconstruct callback-level directed acyclic graphs with precedence relations and measured execution-time attributes, including special handling for message synchronization and services with multiple clients (Abaza et al., 2023). Runtime verification work takes the complementary route: requirements written in FRETish are translated through FRET, Ogma, and Copilot into hard-real-time C99 monitors, and Ogma’s ROS 2 backend then wraps those monitors into ROS 2 monitoring and logging nodes that can be integrated as black-box packages (Perez et al., 2022). Both strands indicate a shift from ad hoc debugging toward formalized timing and requirement assurance embedded in the ROS 2 graph.

The most ambitious middleware analyses now argue that future ROS 2 progress depends on cross-layer redesign rather than isolated tuning. One survey identifies unresolved issues around mainline executor convergence, accelerator and GPU management, and uncertainty in timing models (Casini et al., 22 Dec 2025). Another frames the deeper problem as a structural trade-off among Space, Time, and State, and points to three research directions: cross-layer co-design, adaptive middleware, and decoupled state architectures that combine centralized efficiency with decentralized fault tolerance (Lee et al., 1 Jul 2026). This suggests that the next phase of ROS 2 research is less about adding another communication primitive than about making location transparency, temporal predictability, and contextual continuity coexist under realistic wireless, edge, and multi-robot conditions.