Middleware is software that lies between an operating system and the applications running on it. Essentially functioning as hidden translation layer, middleware enables communication and data management for distributed applications.


How can a middleware (ROS) use another middleware (DDS)??

The middleware concept here is applied at different layers, and one can think of it like a stack:

  • Application Software > ROS > DDS > Hardware

ROS provides the services needed to build robotics applications, and DDS provides the services needed for nodes within ROS to communicate effectively.

ROS Middleware Interface (RMW)

ROS 2 is built on top of DDS / RTPS as its middleware, which provides discovery, serialization and transportation.

The RMW (ROS Middleware Interface) serves as an Abstraction layer between ROS and the underlying middleware, such as DDS implementations. The idea is to provide a consistent API for ROS nodes, regardless of what middleware is used. RMW translates high-level ROS API calls into middleware-specific calls.

The best DDS is ConnextDDS, but you need a license to use it. The free default version is CycloneDDS.


Is the middleware determined at compile-time or runtime?

It is determined at runtime. This is a design decision, see here for more.

Mapping between DDS and ROS concepts

Source Every ROS node is one DDS participant. If multiple ROS nodes are being run in a single process they are still mapped to separate DDS participants. If the containing process exposes its own ROS interface (e.g. to load nodes into the process at runtime) it is acting as a ROS node itself and is therefore also mapped to a separate DDS participant.

The ROS publishers and subscribers are mapped to DDS publishers and subscribers. The DDS DataReader and DataWriter as well as DDS topics are not exposed through the ROS API.

The ROS API defines queue sizes and a few Quality of Service parameters which are being mapped to their DDS equivalent. The other DDS QoS parameters are not being exposed through the ROS API.