About ROS 2 middleware implementations¶
Common Packages for DDS Middleware Packages¶
All of the current ROS middleware implementations are based on full or partial DDS implementations. For example, there is a middleware implementation that uses RTI’s Connext DDS and an implementation which uses eProsima’s Fast DDS. Because of this, there are some shared packages amongst most DDS based middleware implementations.
rosidl_generator_dds_idl: provides tools to generate DDS
rosidl_generator_dds_idl package generates a DDS
.idl file for each
rosidl file, e.g.
.msg file, defined by packages containing messages.
Currently DDS based ROS middleware implementations make use of this generator’s output
.idl files to generate pre-compiled type support that is vendor specific.
Structure of ROS Middleware Implementations¶
A ROS middleware implementation is typically made up of a few packages in a single repository:
<implementation_name>_cmake_module: contains CMake Module for discovering and exposing required dependencies
rmw_<implementation_name>_<language>: contains the implementation of the
rmwAPI in a particular language, typically C++
rosidl_typesupport_<implementation_name>_<language>: contains tools to generate static type support code for
rosidlfiles, tailored to the implementation in a particular language, typically C or C++
<implementation_name>_cmake_module package contains any CMake Modules and functions needed to find the supporting dependencies for the middleware implementation.
rti_connext_dds_cmake_module provides wrapper logic around the CMake Module shipped with RTI Connext DDS to make sure that all packages that depend on it will select the same installation of RTI Connext DDS.
fastrtps_cmake_module includes a CMake Module to find eProsima’s Fast DDS.
Not all implementations will have a package like this: for example, Eclipe’s Cyclone DDS already provides a CMake Module which is used directly by its RMW implementation without the need of additional wrappers.
rmw_<implementation_name>_<language> package implements the
rmw C API in a particular language.
The implementation itself can be C++, it just must expose the header’s symbols as
extern "C" so that C applications can link against it.
rosidl_typesupport_<implementation_name>_<language> package provides a generator which generates DDS code in a particular language.
This is done using the
.idl files generated by the
rosidl_generator_dds_idl package and the DDS IDL code generator provided by the DDS vendor.
It also generates code for converting ROS message structures to and from DDS message structures.
This generator is also responsible for creating a shared library for the message package it is being used in, which is specific to the messages in the message package and to the DDS vendor being used.
As mentioned above, the
rosidl_typesupport_introspection_<language> may be used instead of a vendor specific type support package if an rmw implementation supports runtime interpretation of messages.
This ability to programmatically send and receive types over topics without generating code beforehand is achieved by supporting the DDS X-Types Dynamic Data standard.
As such, rmw implementations may provide support for the X-Types standard, and/or provide a package for type support generated at compile time specific to their DDS implementation.
To learn more about what is required to create a new middleware implementation for ROS see this page:
TODO: Link to more detailed middleware implementation docs and/or tutorial.