In early July of this year, Open Robotics announced the second official release of their next-gen Robotics platform, ROS2. Codenamed “Bouncy Bolson,” this release continues to enhance ROS2, highlighted by the inclusion of the “RViz” 3D visualizer.

For those unfamiliar, ROS(Robot Operating System) is an open-source software framework for developing robot software applications.  It started as an open-source project in 2007, and is a mainstay in robotics research because of its ease-of-use and open-source hackability. As a result, it has grown to include tools for 3D simulation and visualization, route planning, pose estimation and support for nearly every type of robotic arm, actuator, gripper, etc.

While the tools in ROS are impressive, the performance and scalability of ROS itself could not keep pace with the needs of next-gen robotics applications, such as autonomous vehicles, multi-robot swarms and operating in distributed environments. ROS was designed to control a single robot from a desktop Linux environment, but these new applications required real-time performance with safety-critical implications, and potentially to operate in a distributed environment with limited memory and unreliable networking. Open Robotics needed a next-gen redesign of ROS, using the best technology to improve these underlying limitations in the original ROS. That led them to adopt DDS as the connectivity framework for ROS2.

Ready to get started with AI and the latest technologies? Microsoft Reactor provides events, training, and community resources to help developers, entrepreneurs and startups build on AI technology and more. Join us!

DDS (Data Distribution System) is an open-standard connectivity framework, supported by around a dozen commercial and open-source implementations. DDS creates a virtual ‘databus’ to efficiently connect the participants in a distributed system, handling the details of discovery, routing, security, reliability, etc., thereby freeing system developers to focus on their application software.   

Autonomous systems often require large amounts of data to be moved quickly, and must be held to a higher standard of safety and security. In addition to ROS2, DDS has been adopted by AUTOSAR for their Adaptive Platform(designed for autonomous-drive vehicles), by the Future Airborne Capability Environment (FACE) Consortium for military aircraft, and is identified as a Core Connectivity Standard by the Industrial Internet Consortium(IIC). DDS is used in the world's largest and most demanding systems and applications

In this tutorial we will set up ROS2 on multiple computers with different operating systems (Linux, Windows, and Apple) to create a distributed robotics system that operates as an integrated whole.  Later, we’ll extend it beyond the boundaries of ROS to interoperate with a DDS-only system. To start, I followed the installation instructions from the ROS2 Wiki site.

This was the simplest of the three installations: add the ROS2 repository to my apt sources list, then do an apt update / apt install of the ROS2 packages. ROS2 was ready-to-go in a few minutes.

I made sure to install the additional RMW implementation for RTI Connext DDS. ROS2 is architected to use a “ROS Middleware Wrapper” (RMW) to give users a choice of DDS implementations.  The default RMW is for a subset implementation that uses the DDS wire protocol but does not include the capabilities of the DDS framework (this will become important later in the article). 

This was a bit more involved than the Linux installation; the original ROS had always been a Linux-only application, and Windows offers fewer conveniences for package installation. After a manual installation of Chocolatey (package manager), Python, OpenSSL, OpenCV and Visual Studio -- and the RTI Connext DDS Libraries -- I had ROS2 running on a Windows system.

Of the three installations, this required the most steps.

I’d started with a factory-new MacBook and needed to install Brew -- then fix some issues that Brew revealed. Once that was done, Brew was very convenient for installing the prerequisite components (Python, ASIO, OpenCV, OpenSSL, etc.), but it was a teeth-clenching manual process to disable the System Integrity Protection (reboot into Recovery OS mode, edit a text file, reboot again). Once that was complete, I could install ROS2 by downloading and extracting a .tar archive (very old-school), and from there I could install the RTI Connext DDS Libraries to get a complete DDS implementation under ROS2.

Under normal conditions, it can be difficult to get computers running the same operating system to talk to each other.  This test is looking to get computers running a mixture of different operating systems working together, which often takes the skills of an IT department to accomplish.I braced myself to solve problems…

It was almost anti-climatic how easily the “demo_nodes” talker/listener applications worked when I tried them in any combination of the three different systems. Multiple talkers, multiple listeners -- they interoperated as if they were all part of the same computer.

Talker and listener on the same PC

After another talker (on a different PC) is added.

One of the brilliant things about DDS is that it implements a data-centric approach to system interoperability. DDS applications communicate with the data itself; not with messages and not with other applications. It’s a very powerful way to decouple the components of a distributed system. In this instance, the talker/listener applications were communicating using a data topic named “chatter”:

This image was captured from the RTI Admin Console, a diagnostic utility for visualizing and troubleshooting DDS system connectivity.  The data-centric approach of DDS allows talkers (publishers) and listeners (subscribers) to be added to or removed from the system as needed, without any special consideration in the application code.  

DDS also supports the use of ‘keys’ (designating a specific element as a unique identifier for the topic) in the topic data, allowing multiple publishers to share the same topic.  Subscribers can accept data from specific keyed topics, or all keys.

Let’s do something a little more interesting than “Hello World”…

Some of the most valuable parts of ROS are its 3D visualization tools (RViz and Gazebo) and their support of a wide range of data types: Image, LiDAR, navigation, position, etc.   A great use-case would be to use these tools for general-purpose 3D visualization of application data outside of ROS.

Let’s try this out using a 3D-appropriate data type: the LiDAR point cloud.

The ROS “PointCloud2” data type gives me just what I need: control over the size, colouring, and quantity of data points to represent in 3-dimensional (x, y, z) space.

Here’s what’s contained in the PointCloud2 data type:

I’ll make a publisher of this 3D data type, and to make it visually interesting I’ll use an outside source of coordinate data: the DDS Shapes Demo.   The ‘Shapes Demo’ is a 2D graphical program used for interoperability testing between different DDS vendors; squares/ circles/triangles bouncing around in a 2D space, it will make for a nice visualization in the 3D point cloud space.

Better yet, let’s combine the data from multiple instances of Shapes Demo into a single 3D space. This kind of “Sensor Fusion” is used extensively in autonomous vehicle systems to provide a more complete picture of the surrounding environment.

Here’s a system diagram of this test (below) -- note the addition of an Android device, which is also running the RTI Shapes Demo:

The updated test system: 4 different operating systems running 4 instances of the Shapes Demo, providing 2D position data to a rendering application which publishes 3D point cloud data to several visualizer applications.  As an interesting side-note: the OSX and Android systems are connected over WiFi, while the Windows and Linux systems are using wired Ethernet.

This Sensor Fusion application will subscribe to the 2D(x,y) ShapeType data produced by the multiple Shapes Demo applications running on 4 separate devices, and convert it to a 3D(x,y,z) PointCloud2 data type, with all 4 inputs combined into the same 3D space. For brevity, the 2D points were mapped directly to 3D space using the ‘shapesize’ variable of the input for the Z axis, and the Sensor Fusion application was limited to converting 2D circles to 3D spheres only.

Interoperation with the ROS tools required some adjustment to the DDS Quality of Service (QoS) and other settings, in summary:

With a compatible set of names and QoS policies in place -- the system, again, just worked, resulting in a distributed system running on four different platforms, all with different operating systems.

This demonstration is running a pure-DDS system -- but is using ROS-compatible data type and QoS settings to allow interoperation with the ROS 3D visualization tools. This resulted in a system, with the performance and flexibility of DDS, being able to use the visualization and planning tools of ROS.

This system was running at modest sample rates -- 16 to 25Hz for the Shapes Demo applications, and 10Hz for the output of the Sensor Fusion application; DDS is capable of running many times faster and with much larger (>GB) sample sizes.

ROS2 was wisely designed to use DDS, resulting in a merger of their respective ecosystems. Autonomous system designers can truly have it all:

For next-gen robotics applications, this combination lets system developers quickly create large-scale systems - and have the ability to surgically connect, debug, and visualize each robot or participant individually.

Neil Puthuff is a Technical Marketing Engineer for Real Time Innovations (RTI) and a named inventor on 13 U.S. patents.

On the 16th of October RTI released a new version of their Connext product suite: Connext 6. One major update to this version is optimizing their throughput and latency of large data samples. For developers of autonomous vehicles, this can provide major data savings for high-volume data such as LiDAR data. Their new version still integrates with ROS2 and AUTOSAR Adaptive.