RMW (ROS Middleware)

RMW (ROS Middleware) – definition

RMW, short for ROS Middleware, is the abstraction layer between the ROS 2 client libraries and the underlying communication middleware. It is implemented through the rmw interface and related packages in the ROS 2 core. Its purpose is to let ROS 2 nodes exchange messages without binding application code directly to one transport implementation.

In practical ROS 2 deployments, an RMW implementation converts ROS 2 communication concepts such as nodes, publishers, subscriptions, services, and Quality of Service (QoS) policies into middleware-specific entities. Actions and parameters are implemented at higher ROS 2 layers using these communication primitives. Most production ROS 2 systems use a Data Distribution Service (DDS) implementation, but ROS 2 can also use alternative transports through compatible RMW packages.

For a mobile UGV, RMW affects how sensor data, odometry, transforms, commands, and navigation messages move between ROS 2 processes and computers. On Leo Rover or Raph Rover, it is therefore part of the communication path between the onboard computer, ROS 2 sensor and control nodes, and remote operator or development machines.

Source: ROS 2 documentation – About middleware implementations.

How RMW works in ROS 2

A ROS 2 application normally uses a client library such as rclcpp for C++ or rclpy for Python. These libraries call the ROS Client Library (RCL), which calls the selected RMW implementation. The RMW layer then creates, configures, and manages transport-specific communication entities.

The communication path can be represented as follows:

ROS 2 application
      ↓
rclcpp / rclpy
      ↓
rcl
      ↓
rmw implementation
      ↓
DDS, Zenoh, or another supported middleware transport
      ↓
Network interface, shared memory transport, or local IPC

ROS 2 distributions commonly provide several DDS-based RMW implementations. Their availability depends on the operating system, ROS 2 distribution, and installed packages.

rmw_fastrtps_cpp – implementation based on eProsima Fast DDS.
rmw_cyclonedds_cpp – implementation based on Eclipse Cyclone DDS.
rmw_connextdds – implementation based on RTI Connext DDS.
rmw_gurumdds_cpp – implementation based on GurumDDS.
rmw_zenoh_cpp – implementation using the Zenoh protocol stack, with support depending on ROS 2 release and package maturity.

Source: ROS 2 middleware implementation documentation.

RMW and DDS in mobile robotics

DDS is the most widely used middleware family in ROS 2. It is specified by the Object Management Group (OMG). DDS uses a publish-subscribe model and supports discovery, configurable reliability, history depth, durability, deadlines, and liveliness. DDS Security can provide security features when supported and configured by the selected implementation.

For UGV systems, these mechanisms affect operational behaviour. A navigation stack may require reliable delivery for goal requests and lifecycle transitions, while high-rate camera or LiDAR streams may use best-effort delivery to avoid retransmission delays on limited Wi-Fi links.

ROS 2 communication element	Typical UGV example	RMW-related concern
Publisher and subscription	`/scan`, `/imu/data`, `/odom`	QoS compatibility, bandwidth, message loss
Service	Sensor calibration or controller reset	Request and response delivery
Action	Navigation goal sent to Nav2	Feedback, cancellation, result delivery
TF2 transform stream	`map → odom → base_link`	QoS compatibility, latency, and message delivery

Source: OMG Data Distribution Service specification and ROS 2 QoS documentation.

Quality of Service and RMW configuration

QoS policies are exposed through ROS 2 APIs, but their implementation is performed by the selected RMW and underlying middleware. A publisher and subscriber must offer compatible QoS policies before they can communicate.

The most relevant QoS settings for a mobile robot are listed below.

Reliability – RELIABLE attempts delivery with retransmissions; BEST_EFFORT attempts delivery without retransmissions.
History – KEEP_LAST stores a configured number of recent samples.
Depth – defines the queue size used with KEEP_LAST.
Durability – TRANSIENT_LOCAL can provide late-joining nodes with retained data.
Deadline – defines the expected maximum interval between messages and enables missed-deadline detection.
Liveliness – helps detect whether a publisher continues to assert its liveliness.

A typical configuration can select an installed RMW implementation before starting ROS 2 nodes.

export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
ros2 launch <package_name> <launch_file>

The exact RMW package must be installed on the system. Selecting an unavailable implementation causes ROS 2 startup errors. Nodes that need to communicate directly must use compatible middleware configurations. The selected implementation can be checked with the RMW_IMPLEMENTATION environment variable and ROS 2 diagnostics.

RMW on Leo Rover and Raph Rover

Leo Rover can use an onboard Raspberry Pi compute unit running ROS 2. In this context, RMW is relevant when integrating onboard nodes for differential-drive control, wheel odometry, IMU data, LiDAR scans, depth cameras, SLAM, and Nav2.

A Leo Rover deployment may run the motor controller interface, robot state publisher, and sensor drivers locally, while a workstation runs RViz, mapping tools, or visualization nodes over Wi-Fi. DDS discovery and QoS configuration then determine whether remote nodes detect topics reliably and whether high-bandwidth sensor streams remain usable.

Raph Rover can use the same ROS 2 and RMW architecture when a larger payload requires additional sensors or compute hardware. In both platforms, RMW does not provide autonomy by itself. Autonomous navigation still requires correctly integrated localization, mapping, transform trees, costmaps, planners, controllers, and safety logic.

ROS 1 and ROS 2 differences

ROS 1 did not use the ROS 2 RMW abstraction. Its communication architecture relied primarily on the ROS Master, XML-RPC negotiation, and TCPROS or UDPROS transports. ROS 2 removed the central ROS Master dependency for normal discovery and introduced middleware pluggability through RMW.

This distinction matters when migrating UGV software. A ROS 1 package that assumes master-based discovery, TCPROS behaviour, or ROS 1 parameter semantics may require adaptation before it can operate correctly in ROS 2.

Source: ROS 2 middleware documentation and ROS 1 technical overview.

Practical limitations

RMW does not make communication deterministic by default. End-to-end latency depends on CPU load, serialization overhead, network quality, Wi-Fi roaming, multicast availability, DDS configuration, and the selected QoS policy. This is important for mobile robots operating outside a controlled laboratory network.

Network discovery can also fail when multicast traffic is blocked, hosts use multiple network interfaces, or firewall rules prevent DDS traffic. Engineers should validate discovery, packet loss, CPU load, and topic frequency on the target robot rather than relying only on desktop simulation results.

RMW (ROS Middleware)