1) Application code uses rclcpp/rclpy, which call the shared core, rcl. 2) rcl calls the C API defined by rmw (node/publisher/subscription creation, publish/receive, services, actions, QoS configuration, discovery). 3) The selected rmw implementation (e.g. rmw_fastrtps_cpp) maps those calls onto a specific DDS middleware's API. 4) Messages are serialized via type support generated by rosidl โ either static (build-time code generation, e.g. rmw_fastrtps_cpp) or dynamic/introspection-based (runtime mapping, e.g. rmw_fastrtps_dynamic_cpp). 5) The implementation is chosen by the RMW_IMPLEMENTATION environment variable (default rmw_fastrtps_cpp); ROS 2 exposes only a subset of the underlying middleware's QoS policies.
ROS 1 relied on custom protocols (TCPROS/UDPROS) and a centralized master. ROS 2 needed a way to leverage mature, standardized middleware implementations (DDS) without tying the core and application code to a single vendor. RMW solves this by hiding a specific middleware's API behind a uniform interface, so the backend can be swapped (for performance, licensing, real-time support, or network compatibility) without changing user code or maintaining separate per-middleware binary packages.
A set of C functions defining the middleware contract: creating nodes, publishers and subscriptions, publishing/receiving messages, services, actions, QoS configuration, and discovery.
A concrete package mapping the rmw C API onto a specific middleware's API, e.g. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp.
Official
Message serialization/deserialization mechanism generated by rosidl; static (build-time code) or dynamic/introspection-based (runtime).
Official
A subset of the underlying middleware's Quality of Service policies exposed by ROS 2 (e.g. reliability, durability, history, depth).
Nodes communicate only if their backends are interoperable. DDS implementations share the RTPS wire protocol, but rmw_zenoh (Zenoh) is not interoperable with DDS backends.
A publisher and subscription with incompatible QoS profiles (e.g. reliability) will not connect despite a correct topic name.
ROS 2 exposes only part of the underlying middleware's configuration; advanced tuning (e.g. publication mode, zero-copy) requires vendor-native configuration (XML files, environment variables).
The middleware interface was defined as an abstraction layer over DDS, decoupling the ROS 2 client library from the vendor.
ROS 2 stabilized support for swappable DDS backends (Fast DDS, Cyclone DDS, RTI Connext) selected via RMW_IMPLEMENTATION.
rmw_zenoh_cpp emerged โ an RMW implementation based on Zenoh, demonstrating a non-DDS backend in newer ROS 2 distributions.
Environment variable selecting the RMW implementation package (e.g. rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds, rmw_zenoh_cpp). Defaults to rmw_fastrtps_cpp.
Configuration of communication guarantees (reliability, durability, history, depth, and others) within the subset ROS 2 exposes.
Choice between static type support (build-time generated code) and dynamic/introspection-based (runtime).
RMW is a software abstraction layer over network middleware โ it does not depend on a specific accelerator and runs on standard CPUs.
