---
title: 'ROS2: A Robust Robotics Framework'
url: https://www.emergentmind.com/topics/ros2
type: topic
---

# ROS2: A Robust Robotics Framework

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 [2211.07752]. 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 [2211.07752].

## 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 [2211.07752]. 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 [1907.00282]. 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 [1905.09654]. 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 [2104.09274].

## 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 [2211.07752]. 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 [2211.07752]. 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 [2211.07752].

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 [2211.07752]. 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 [1907.00282]. 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 [2211.07752]. 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 [2211.07752]. 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 [2607.01304].

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 [2601.10722]. 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 [2601.10722]. In the multi-threaded executor, parallelism is regulated by callback groups that are either mutually exclusive or reentrant [2601.10722]. 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 [2607.01304]. 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\) [2607.01304]. 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 [2411.11607]. 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 [2411.11607]. 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 [2407.03091].

## 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 [2208.02615]. 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 [2208.02615]. 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 [2208.02615]. 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 [2211.07752]. 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 [2306.17157]. 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 [2306.17157].

## 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 [2211.07752]. 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 [1905.09654]. 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 [2104.09274].

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 [2601.18289]. 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 [2604.24242]. 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 [2506.14487]. 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 [2602.02269]. 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 [2211.07752]. 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 [2601.10722]. 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 [2311.13333]. 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 [2209.14030]. 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 [2601.10722]. 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 [2607.01304]. 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.

Source: https://www.emergentmind.com/topics/ros2