Eclipse Cyclone DDS: IoT Middleware for Robots, Autonomous Vehicles, and Demanding Systems

Just before Christmas 2020, Open Robotics announced the Eclipse Cyclone DDS project had been selected by the Robot Operating System (ROS) 2 Technical Steering Committee to be the default middleware in the ROS 2 Galactic Geochelone release. The announcement was an important milestone on the long road from the origins of the Data Distribution Service (DDS) concept and technology to today and the promising future of the Eclipse Cyclone DDS implementation.

I’ll start with some history.

I’ve been working with DDS technology for about 25 years, and in many ways, I’m working in the family business. The first versions of the technology that later became the Object Management Group (OMG) DDS standard were developed by my father, Maarten Boasson, in the early 1980s when he worked in the defense industry. So, we’re actually working with a method of building systems that’s about 40 years old.

Development on the Eclipse Cyclone DDS implementation started about 10 years ago as part of the ADLINK OpenSplice DDS product, and in 2018, we made the initial commit to the Eclipse Cyclone DDS project.

To help you understand more about Eclipse Cyclone DDS, how we got to the Open Robotics announcement, and our goals for the future, here are answers to the questions I’m most often asked.

What Role Does DDS Play in ROS 2?

Robots are built with many components and nodes that need to exchange messages, data, and parameters. The DDS implementation is the glue that interconnects all of these nodes and components so they can discover one another and communicate.

With a DDS implementation as the middleware layer, robot developers, who are typically not software engineers, don’t have to work directly with DDS, which is a complex standard. They can simply select the middleware they want to use with ROS 2 and the rest is taken care of.

Figure 1 illustrates where Eclipse Cycle DDS fits in the ROS 2 architecture.

Figure 1: Eclipse Cyclone DDS in the ROS 2.0 Architecture

Figure 1: Eclipse Cyclone DDS in the ROS 2.0 Architecture

How did Eclipse Cyclone DDS Become the Default ROS 2 Middleware?

Open Robotics was rewriting the original ROS software and had decided to base it on DDS. So, I developed a first, very minimalist implementation of support for ROS 2 using Eclipse Cyclone DDS. I then announced at a conference that this minimalist implementation performed much better than the implementations most people were using at the time. That got the ball rolling. By the time the next conference came along, our implementation included a lot more functionality.

My colleague, Joe Speed, did a tremendous job evangelizing the merits of Eclipse Cyclone DDS and getting robotics companies to switch out the original ROS 2 default middleware and try it. Most were very happy, and many wrote blog posts and tweets about their experience:

  • Rover Robotics, which makes small, rugged autonomous vehicles, is a great example. They tried five DDS implementations using Wi-Fi and made a video series about their experience. In the first video, the Eclipse Cyclone DDS implementation had the system up and running in 11 seconds. Two implementations weren’t able to start at all. And another needed a minute to start the system. One of the implementations that could not start the system was the default ROS 2 middleware at the time. To be fair, a few bug fixes solved their problem.
  • Ghost Robotics was also an early adopter of Eclipse Cyclone DDS, using it in ROS 2 quadruped robots adopted by Verizon and the U.S. Air Force.
  • Trajekt Sports uses Eclipse Cyclone DDS in robotic pitching machines for Major League Baseball players.
  • Mission Robotics took Eclipse Cyclone DDS 457 m (1,500 ft) underwater to the bottom of Lake Tahoe.
  • Box Robotics (now Seegrid) used Eclipse Cyclone DDS to accelerate 3D LiDAR point clouds.

These companies, and many others, listened to Joe, tried Eclipse Cyclone DDS, and never looked back. Many became contributors to the project. You can see the growing list of Eclipse Cyclone DDS adopters, here.

When Open Robotics recently held its first-ever selection process for the default middleware for a ROS 2 release, Eclipse Cyclone DDS was selected based on Open Robotics’ extensive testing and their survey of ROS 2 users, which found that Eclipse Cyclone DDS users are happier than users of other middleware.

Further validating the decision, the Technical University of Dresden published research entitled “Latency Overhead of ROS2 for Modular Time-Critical Systems,” which concluded that “CycloneDDS yields the best latency.” Figure 2 illustrates some of the research findings published in the paper.

Figure 2: Technical University of Dresden ROS 2 Latency Overhead Analysis

Figure 2: Technical University of Dresden ROS 2 Latency Overhead Analysis

Are Other DDS Implementations Also Open Source?

The previous ROS 2 default middleware is open source, but is developed by a company that simply publishes in GitHub, so it doesn’t have the same assurances you get with Eclipse Foundation licensing and governance. Another DDS implementation that is often a point of comparison is a proprietary, closed-source implementation which, according to the Technical University of Dresden research, doesn’t perform nearly as well as Eclipse Cyclone DDS in ROS 2 robots, despite its cost.

Naturally, our plan is to ensure that everyone who uses ROS 2 is so happy with Eclipse Cyclone DDS as the default middleware, the next selection process will only be a formality.

How Will You Enhance the Software to Remain the Default ROS 2 Middleware?

We’ll work closely with the Open Robotics ROS community to understand their rapidly evolving needs.

One thing we’re doing based on the community’s interest is integrating the Eclipse iceoryx software to add zero-copy memory transfer and significantly optimize data copy performance. Performance in this area is an issue for many robotics companies because robots with HD cameras, LiDAR, and radar output huge amounts of data. If you have to copy that data multiple times, you end up using all of your resources to copy data instead of other, more useful, tasks.

Robot developers will be able to build Cyclone DDS implementations with Eclipse iceoryx integrated to offload some of that traffic and data. The Eclipse iceoryx integration will be completely transparent to applications. Robot developers will get all of the technology’s benefits with no additional effort as we will take on the pain of making it all work behind the scenes.

We’re also working on scaling to much larger systems so it’s easy and efficient to manage systems transparently through the cloud. DDS is very good at communicating across LANs, but not so great at communicating over the internet. We’ve developed a bridge so we can use Eclipse zenoh to connect different DDS networks across large areas.

Eclipse Cyclone DDS and Eclipse zenoh are an important combination for robot swarming and autonomous vehicle “V2X” applications. The combination has been adopted by the U.S. Department of Transportation CARMA program. It’s early days, but we’ve already had a lot of interest from companies and universities with these types of needs, including Indy Autonomous Challenge university teams. Figure 3 shows a race car being used in the challenge.

Figure 3: Indy Autonomous Challenge Race Car

Figure 3: Indy Autonomous Challenge Race Car

How Do You See Eclipse Cyclone DDS Being Used Beyond ROS 2?

DDS is used in many industries for IoT and other applications, and we want to expand our implementation to reflect that breadth and increase adoption. Here are just a few examples of where DDS is used:

  • Smart Cities, such as Singapore's smart lamppost project, which uses DDS, to connect lamppost sensors to the data center
  • Smart greenhouses use DDS to control sprinklers and sun shades
  • Airports use DDS in control systems for runway lighting and in air traffic control systems
  • Agriculture equipment companies use DDS to control self-driving harvesters

And, of course it’s used in many defense systems, which is where the technology originated. Flight simulators for pilot training are just one example.

Basically, DDS can be used anywhere devices, sensors, controllers, actuators, and computers need to be integrated and share data with low latency, and at relatively high data rates. Even NASA uses DDS for launch and control systems at the Kennedy Space Center.

Try the Eclipse Cyclone DDS

I encourage everyone who needs middleware for distributed communications to try the Eclipse Cyclone DDS implementation. If you run into any issues or have questions, just let us know. We’re happy to provide suggestions and assistance. Don’t be afraid to tell us what you think. And if you want to contribute to the software, so much the better. You can find our developer mailing list details, here.

About the Author

Erik Boasson

Erik Boasson

Erik Boasson is a member of the Technology Office at ADLINK Technology. His focus is on DDS, its applications, and future developments, and his current efforts are primarily toward developing Eclipse Cyclone DDS. Erik has 25 years of experience in the field, beginning at the source of the data-centric programming model, Hollandse Signaalapparaten B.V., now Thales Nederland B.V., in the 1990s. His implementation of the SPLICE architecture there played a crucial role in convincing the U.S. Department of Defense to mandate use of DDS.