ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

CycloneDDS roadmap - multi-network, async, content filtering, QL1, et al

Eclipse Cyclone DDS contributors want your input for roadmap to support the ROS community. We’ve had many inquiries about what is planned so wanted to show where to find the roadmap. We would love your comments and input here and via github issues.

CycloneDDS 0.8, Dec 2020

  • C++11 APIs (GA)
  • New APIs to access to serialized CDR data
  • New APIs for configuring the deployment of Cyclone DDS based application
  • Multi-Network interface cards support (Consolidation)
  • Content filtering support for C++
  • IDL compiler front-end & back end support of the Xtypes annotations
  • Topic and data type discovery
  • ROS 2 Quality Level 2
    • Automated performance and regression testing
    • Formal feature list also showing test coverage
    • APIs marked stable (each API in formal feature list), evolving or experimental

CycloneDDS 0.9, March 2021

  • Integration of Durability Service for Transient and Persistent data
  • Shared memory transport support … including zero-copy API
  • Python APIs (GA)
  • Internet-scale deployment support
  • DDS-Xtypes APIs
  • Asynchronous mode of operation
  • ROS 2 Quality Level 1

CycloneDDS 1.0 June 2021

  • Static discovery
  • Static memory allocation
  • Writer side filtering support
  • Content Querying APIs

Long-term milestones

  • Network Mobility support
  • C# language binding support (DDS C# API)
  • Java language binding support (Java 5 Language PSM for DDS)
  • Time-sensitive Networking support DDS-TSN
  • Rust language binding support
  • Certifiable DDS
  • FACE 3 support
  • Network Scheduling and Federated architecture support
  • TrustZone support for DDS Security

What is the current status of zero-copy transfers? If it is not yet implemented in Cyclone, where does it fall in this roadmap?

1 Like

Very glad to see “Multi-Network Interface card support” - this is about the only thing that has tripped me up with CycloneDDS. Will this magically work with rmw wrapper once CycloneDDS 0.8 goes out, or will it require updates to the RMW to use it?


Exciting roadmap!

  1. Static memory allocation looks interesting. Will also be nice if language bindings can override the allocator.
  2. TrustZone. I’m curious about this. Shouldn’t this interface be handled by security plugins? As far as I know, there is no standard software interface to a TrustZone.
  3. Any plans to support the DDS-RPC spec?


1 Like

This is really nice, since we have been working on ContentFilteredTopic Design and RMW Proposal. thank for sharing the roadmap :+1:

1 Like

There is a shared memory prototype that makes a copy in shared memory, for true zero copy the application needs to reserve the space rather than rely on Cyclone to do it internally, so it needs some work still (mostly in the periphery of the code base, but still).

If you look at the performance curve you get with that extra copy in, it hurts. So in my view “shared memory” support really means: “zero-copy shared memory support”. Otherwise, it is just isn’t fun :slight_smile:


It’ll “magically” work. All these details are handled by the configuration XML, and so it mostly depends on how far I am willing to go in changing the default behaviour. Should I decide to stick with the current behaviour (just one interface) for the time being, you might have to instruct Cyclone to do something else via that configuration XML.

(Actually, there is a working prototype: — feel free to play with it. I can only help for getting it right.)

1 Like
  1. Static memory allocation looks interesting. Will also be nice if language bindings can override the allocator.

Good point. I need to think about that, but I can see where you’re coming from :slight_smile:

  1. TrustZone. I’m curious about this. Shouldn’t this interface be handled by security plugins? As far as I know, there is no standard software interface to a TrustZone.

Yes, so it is plans for plugins that forward the operations to code running inside the TrustZone. But this is still a bit vague as to the details.

  1. Any plans to support the DDS-RPC spec?

Hmm … not really. It is an abomination that takes a pub/sub-based shared data space and then abuses it to do point-to-point request-reply, and in typical DDS specification-style it also implies a lot of work. There are more valuable things to be done, I’d say. In my opinion, it makes far more sense to use DDS to publish server locators, then use a standard RPC mechanism to invoke those services.

But if someone were to contribute an implementation (it’s mostly preprocessing anyway) of course I would be grateful!


Thanks for the info, @eboasson! No ETA on that at this time, then?

1 Like

I’d say March 2021, but I can see how one could read my initial response differently. Sorry about that!

1 Like

… with built-in Eclipse iceoryx. Heard good things from people that tried it. I think up to 4x improvement for point clouds & images. March release with zero-copy API will improve significantly upon that.


Can’t wait to see Cyclone 0.9 in March. The full power of true zero-copy shared memory communication will be leveraged when the API is adapted accordingly and the ROS2 loaned messages are used.

Does “Topic and data type discovery” will include That would be good news too


Does “Topic and data type discovery” will include

Yep, it does :slight_smile:


Yes, this would be great!

1 Like

@connoranderson CycloneDDS Rust support is well progressed with these Rust bindings and zenoh-plugin-dds

1 Like
  • Certifiable DDS

I know it is a long term goal but can you comment how you envision reaching safety certification?

1 Like

Overall, looks like a good roadmap! Wanted to weigh in with some +1’s and comments on other features that I have utilized or found useful over the years working with DDS.

First with the +1’s on features that I think are really important and that we have an immediate need for within our company’s stack:

The multi-network and IP mobility features are critical for us in the long run, especially given that our robots and user devices frequently roam across different LAN networks, often times residing on multiple at the same time and sometimes having both static and DHCP addresses on a single network interface. We’ve already run into a couple of issues around discovery and consistency in maintaining ROS2 connectivity between nodes when using non-RTI RMW implementations, so this will be critical for us in ensuring that in all of the types of network environments and configurations that our customers use, the RMW is well supported and behaves correctly.

SHMEM/Zerocopy, of course, is of huge importance, given that we are deploying high-bandwidth, multi-camera systems on embedded processors like the Jetson Nano, Xavier, etc.

Some additional suggestions:

  • Support for chainable transport plugins via a transport plugin API, similar to what RTI provides support for:
  • Not exactly a CycloneDDS feature, but in the Cyclone RMW it would be great to have access to features at node-creation time that allow programmatic configuration of aspects like specifying partitions on the Publisher/Subscriber entities. I realize that this is better discussed in the context of the “how do we provide ROS2 users a common interface to DDS features” discussion, but in the meantime, I think it might be easy to streamline some of these “extensions” into the vendor RMW layers. Partitions in particular are of critical importance to us to support efficient multi-robot <> multi-user-device (i.e., apps running on mobile devices & laptops) environments.

Love the work that the Cyclone team has been doing so far, and look forward to the next couple of milestones! Only request I would emphasize (selfishly) is that the network mobility work be prioritized a bit more highly, if possible :grinning_face_with_smiling_eyes:


Thanks for the update.

We have been trying out Cyclone DDS and found it has a big improvement over FastDDS with regards to larger and distributed setups (multiple machines). If we can we’ll share some of our testing results but it still needs some clean-up.

In order to fully adopt Cyclone DDS we require the Multi-Network interface cards support, we’ll try out the branch and report our feedback/experience.


Does anybody remember this cool roadmap?

In November, we were selecting the next DDS implementation for Galactic, and this was one major selling point for CycloneDDS.

This was clearly impossible, but anyway it was used to push cyclone DDS as the default, promising a lot of features publicly to the ROS community. We are now almost reaching the code freeze for Galactic (April 5th), and it is clear is not happening, and now delayed sine die (see this PR).

Fortunately, Fast DDS already has these features in Foxy, and we are delivering all we promised for the Galactic release.