ROS 2 and DDS: Interoperability Drives Next-Generation Robotics
Written by Neil Puthuff
November 9, 2020
ROS 2 has already enjoyed widespread adoption for both automotive and robotics development projects. As today’s innovators start to build tomorrow’s innovations, the next logical inflection point is production-grade deployment. But commercial-grade, next-generation robotics will require more than the current ROS code to comply with the necessary performance, interoperability, security and scalability requirements. And that’s where DDS comes into play.
The good news? In many ways, ROS 2 is already a Data Distribution Service™ (DDS) application. This means that ROS 2 components can be freely intermixed with native DDS components, with full interoperability. And this interoperability is crucial, as the right hybrid system design approach can enable capabilities far beyond what ROS or ROS 2 alone can offer.
Though DDS is a well-established standard, it’s important to note that not all DDS offerings are created equally. In theory, building applications on the ROS 2 framework can be a great introduction to how the DDS framework enables the creation of highly reliable distributed systems. But in reality, many mission-critical applications need more from DDS, such as extreme performance, more QoS options, or easier interoperability with non-ROS components. When production-grade robotics is the goal, ROS 2 applications need the complete range of features offered by a more robust software framework such as RTI Connext® DDS, especially if the objective is to enter competitive, real-world markets. In essence, Connext DDS expands the designer’s toolbox.
On the technical side, as I’ll explore in this blog, achieving this interoperability and positioning your development efforts for the future can be surprisingly straightforward, because ROS 2 was built on DDS and uses a standard data model. From a DDS perspective, all ROS 2 applications are actually DDS applications. It can therefore be a simple matter of using the same data types, topic names, and QoS settings to make a non-ROS 2 application (one built on Connext DDS, for example) fully interoperable with existing ROS 2 applications. In this scenario, you can also hopefully skip those costly “back-to-the-drawing-board” moments and stay focused on your design goals.
The ROS 2 Data Model
Despite the changes and enhancements with each release of ROS and ROS 2, core elements of the ROS data model have remained very consistent. These include data type definitions for a variety of sensors, geometric shapes, trajectories, navigation, visualization and more, defined as data objects and as request/response topics for remote procedure calls.
These data types are defined in a ROS-specific file format, such as:
This format can be easily converted to standard IDL or XML data type definitions. This happens as a byproduct of building ROS 2 from source. However the IDL files are somewhat scattered amongst the intermediate files that are created when building ROS 2.
Fortunately there is an easier way. On the RTI Community GitHub site, RTI maintains a pre-converted IDL file set of the ROS 2 data model, arranged to be easily built, included, and used in any application that needs to interoperate with ROS 2.
Building the ROS 2 Type Support Library
This project is set up to build a static library and header files for your choice of C, C++(traditional) or C++11 (“Modern C++”). This uses CMake to simplify the build process, and the RTI code generator, which results in code that is portable to different platforms, processors, and operating systems / RTOS. I built this example on Linux; other hosts are also supported.
Open a terminal into a directory for building this project, then enter the following commands to clone and build the library:
git clone https://github.com/rticommunity/ros-data-types.git ros-data-types
cmake -Hros-data-types -Bros-data-types/build \ -DCMAKE_INSTALL_PREFIX=ros-data-types/install -DLANG=C++11
cmake --build ros-data-types/build -- install
The build step may take several minutes (note that the ROS 2 data model includes more than a hundred data type definitions), and the results will be placed in ./ros-data-types/install.
This directory contains:
|install/lib/libRosDataTypes.a||Static library of DDS data type support for ROS 2|
|install/include/*||Tree of header files for using the library|
As a simple interoperability example, let’s create a small non-ROS program that will publish 3D point cloud data using the ROS 2 “PointCloud2” data type, for viewing with the “RViz2” visualizer in ROS 2. For those who have experience developing ROS applications, writing code using the native Connext C++11 API will look very familiar:
The Connext API is used internally by ROS 2 when run on the Connext RMW layer. We’re simply bypassing the ROS 2 layers to get full access to Connext.
RTI now offers a new Connext RMW layer which we developed from the ground up to simplify the code and greatly improve the performance, providing turnkey access to RTI’s powerful distributed system development tools (see the official announcement for details).
This example uses a single source file to generate the point cloud data. The code is very compact:
This example uses the bare-metal C++11 API for Connext – without the help of any added wrappers or encapsulation – yet it’s still very compact, is very easy to understand, and runs at peak performance due to the lack of intervening software layers. The complete set of Connext capabilities are directly accessible from this API, and it seamlessly interoperates with ROS 2.
Build and Run the Application
The example uses the RTI CMake helper script, highlighted in a previous blog to simplify the build process across different platforms (Linux, Windows, etc.), resulting in correctly-configured make / solution files to build the application.
On a Linux host, this looks like:
mkdir build; cd build
cmake -G “Unix Makefiles” ..
Once the application is built, it can be directly run in a terminal:
To visualize the point cloud data, launch the ROS 2 “RViz2” visualizer, and using the “Add .. by topic” button and tab, select the PointCloud2 topic named “ptcloud_test”. You should see an image similar to this:
ROS 2 provides a convenient environment for creating robotics applications, but there are many places that need the peak performance and full range of capabilities available in Connext DDS. By directly using Connext with the ROS 2 data model, system developers can have the best of both – all of the range and performance of Connext AND full use of the ROS 2 ecosystem – effectively multiplying their toolbox to create fully optimized systems.
ROS 2 data types in IDL: https://github.com/rticommunity/ros-data-types
Example application code: https://community.rti.com/ros
Connext RMW Layer: https://github.com/rticommunity/rmw_connextdds/ under an Apache 2.0 license.
More on ROS 2!
The examples above illustrate just how straightforward it can be to pair ROS 2 with DDS. To learn more about the connectivity software used in more than 200 mission-critical robotics and autonomous vehicle programs, we encourage you to attend our webinar, "High-Stakes Robotics: Moving from the ROS 2 Lab to Production & Deployment." This webinar is presented live on November 19, 2020 and available on-demand after that date. See details and register here.
For additional detailed information on both the technical side and operational advantages of combining ROS 2 and DDS, please read a recent RTI white paper on this topic or email us at email@example.com. You can also visit our all-new Robotics webpage.
About the author
Neil Puthuff is a Senior Software Integration Engineer for Real-Time Innovations with a focus on Automotive, ROS, and Grid Modernization. Prior to joining RTI, he created the processor probes and replay debugging products at Green Hills Software. Neil is a named inventor on more than a dozen US patents.