Warning

You're reading the documentation for a version of ROS 2 that has reached its EOL (end-of-life), and is no longer officially supported. If you want up-to-date information, please have a look at Jazzy.

About different ROS 2 DDS/RTPS vendors

ROS 2 is built on top of DDS/RTPS as its middleware, which provides discovery, serialization and transportation. This article explains the motivation behind using DDS implementations, and/or the RTPS wire protocol of DDS, in detail. In summary, DDS is an end-to-end middleware that provides features which are relevant to ROS systems, such as distributed discovery (not centralized like in ROS 1) and control over different “Quality of Service” options for the transportation.

DDS is an industry standard which is implemented by a range of vendors, such as RTI’s Connext DDS, eProsima’s Fast DDS, Eclipse’s Cyclone DDS, or GurumNetworks’s GurumDDS. RTPS (a.k.a. DDSI-RTPS) is the wire protocol used by DDS to communicate over the network.

ROS 2 supports multiple DDS/RTPS implementations because it is not necessarily “one size fits all” when it comes to choosing a vendor/implementation. There are many factors you might consider while choosing a middleware implementation: logistical considerations like the license, or technical considerations like platform availability, or computation footprint. Vendors may provide more than one DDS or RTPS implementation targeted at meeting different needs. For example, RTI has a few variations of their Connext implementation that vary in purpose, like one that specifically targets microcontrollers and another which targets applications requiring special safety certifications (we only support their standard desktop version at this time).

In order to use a DDS/RTPS implementation with ROS 2, a “ROS Middleware interface” (a.k.a. rmw interface or just rmw) package needs to be created that implements the abstract ROS middleware interface using the DDS or RTPS implementation’s API and tools. It’s a lot of work to implement and maintain RMW packages for supporting DDS implementations, but supporting at least a few implementations is important for ensuring that the ROS 2 codebase is not tied to any one particular implementation, as users may wish to switch out implementations depending on their project’s needs.

Supported RMW implementations

Product name

License

RMW implementation

Status

eProsima Fast DDS

Apache 2

rmw_fastrtps_cpp

Full support. Default RMW. Packaged with binary releases.

Eclipse Cyclone DDS

Eclipse Public License v2.0

rmw_cyclonedds_cpp

Full support. Packaged with binary releases.

RTI Connext

commercial, research

rmw_connext_cpp

Full support. Support included in binaries, but Connext installed separately.

GurumNetworks GurumDDS

commercial

rmw_gurumdds_cpp

Community support. Support included in binaries, but GurumDDS installed separately.

For practical information on working with multiple RMW implementations, see the “Working with multiple RMW implementations” tutorial.

Multiple RMW implementations

The ROS 2 binary releases for currently active distros have built-in support for several RMW implementations out of the box (Fast DDS, RTI Connext Pro, Eclipse Cyclone DDS, GurumNetworks GurumDDS). The default RMW implementation in Foxy is Fast DDS, which works without any additional installation steps.

Other RMWs like Eclipse Cyclone DDS, Connext or GurumDDS can be enabled by installing additional packages, but without having to rebuild anything or replace any existing packages.

A ROS 2 workspace that has been built from source may build and install multiple RMW implementations simultaneously. While the core ROS 2 code is being compiled, any RMW implementation that is found will be built if the relevant DDS/RTPS implementation has been installed properly and the relevant environment variables have been configured. For example, if the code for the RMW package for RTI Connext is in the workspace, it will be built if an installation of RTI’s Connext Pro can also be found.

For many cases you will find that nodes using different RMW implementations are able to communicate, however this is not true under all circumstances. Here is a list of inter-vendor communication configurations that are not supported:

  • Fast DDS <-> Connext

    • WString published by Fast DDS can’t be received correctly by Connext on macOS

  • Connext <-> Cyclone DDS

    • does not support pub/sub communication for WString

  • Connext Dynamic <-> Connext Dynamic

    • does not support C services

Default RMW implementation

If a ROS 2 workspace has multiple RMW implementations, the default RMW implementation since Galactic is selected as Cyclone DDS if it’s available. If the Cyclone DDS RMW implementation is not installed, the RMW implementation with the first RMW implementation identifier in alphabetical order will be used. The implementation identifier is the name of the ROS package that provides the RMW implementation, e.g. rmw_cyclonedds_cpp. For example, if both rmw_fastrtps_cpp and rmw_connext_cpp ROS packages are installed, rmw_connext_cpp would be the default. If rmw_cyclonedds_cpp is ever installed, it would be the default.

See the guide for how to specify which RMW implementation is to be used when running the ROS 2 examples.