Robotics

RMW

2014ActivePublished: 23 September 2026Updated: 23 September 2026Published

Key innovation

An abstraction layer that decouples the ROS 2 core (rcl/rclcpp/rclpy) from any specific communication middleware (usually DDS), allowing the backend to be swapped without changing application code.

How it works

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.

Problem solved

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.

Components

rmw C APIThe interface contract implemented by every RMW backend.

A set of C functions defining the middleware contract: creating nodes, publishers and subscriptions, publishing/receiving messages, services, actions, QoS configuration, and discovery.

RMW implementation (backend adapter)Translates rmw calls into the selected middleware's operations.

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.

rmw_fastrtps_cppDefault implementation based on eProsima Fast DDS with static type support.

rmw_fastrtps_dynamic_cppFast DDS variant using introspection type support at runtime.

rmw_cyclonedds_cppImplementation based on Eclipse Cyclone DDS.

rmw_connextddsImplementation based on RTI Connext DDS Professional (rmw_connextddsmicro is deprecated).

rmw_zenoh_cppRMW implementation based on Zenoh (non-DDS), using the zenoh-cpp bindings.

Official

Type support (rosidl)Maps ROS message types to the middleware representation.

Message serialization/deserialization mechanism generated by rosidl; static (build-time code) or dynamic/introspection-based (runtime).

Official

QoS policiesControls delivery guarantees and buffering of communication.

A subset of the underlying middleware's Quality of Service policies exposed by ROS 2 (e.g. reliability, durability, history, depth).

Implementation

Reference implementations

ros2/rmw

C · Open Robotics / ROS 2

Official

rmw_fastrtps

C++ · eProsima / ROS 2

Official

rmw_cyclonedds

C++ · Eclipse Cyclone DDS / ROS 2

Implementation pitfalls

Mismatched RMW implementations between nodesHigh

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.

Fix:Use a consistent RMW_IMPLEMENTATION across the system; verify the backend with `ros2 doctor --report`.

Incompatible QoS policiesHigh

A publisher and subscription with incompatible QoS profiles (e.g. reliability) will not connect despite a correct topic name.

Fix:Use compatible QoS profiles on both sides; rely on ROS 2's predefined profiles.

Limited subset of middleware featuresMedium

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).

Fix:For advanced tuning, use vendor-native mechanisms (e.g. FASTRTPS/CYCLONEDDS_URI).

Evolution

Original paper · 2014 · ROS 2 Design

ROS Middleware Interface

2014

RMW design article

Inflection point

The middleware interface was defined as an abstraction layer over DDS, decoupling the ROS 2 client library from the vendor.

2017

Multiple DDS vendors in ROS 2

ROS 2 stabilized support for swappable DDS backends (Fast DDS, Cyclone DDS, RTI Connext) selected via RMW_IMPLEMENTATION.

2024

rmw_zenoh as a non-DDS alternative

rmw_zenoh_cpp emerged — an RMW implementation based on Zenoh, demonstrating a non-DDS backend in newer ROS 2 distributions.

Hyperparameters (configurable axes)

RMW implementation selectionCritical

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.

rmw_fastrtps_cppDefault backend (eProsima Fast DDS).

rmw_cyclonedds_cppEclipse Cyclone DDS.

rmw_zenoh_cppZenoh-based backend.

QoS policiesHigh

Configuration of communication guarantees (reliability, durability, history, depth, and others) within the subset ROS 2 exposes.

Type support modeMedium

Choice between static type support (build-time generated code) and dynamic/introspection-based (runtime).

statice.g. rmw_fastrtps_cpp — higher performance.

dynamic/introspectione.g. rmw_fastrtps_dynamic_cpp — runtime mapping.