ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

RMW layer for Eclipse Cyclone DDS

Hi everyone,

The Eclipse Cyclone DDS project (https://github.com/eclipse-cyclonedds/cyclonedds) at long last has received an RMW implementation, which can be found at https://github.com/atolab/rmw_cyclonedds. Eclipse Cyclone DDS is an Eclipse Foundation project and so a true open-source implementation of DDS. That it has excellent performance as well hopefully makes it a rather attractive proposition :slight_smile:

I’m hoping that this RMW layer will eventually be accepted as a ROS2 package, move to the ROS2 repositories and become part of the set of packages that is built by default, but until then, it’ll be available in this location. Also, it is really still very young, so please test the hell out of it and then be gentle with me when you report the issues you will inevitably encounter …

To build/use it you need to have a recent commit of Cyclone DDS installed somewhere, say in $CMAKE_INSTALL_PREFIX. Actually building the RMW implementation then follows the standard procedure: clone it in a ROS2 workspace source directory, set CycloneDDS=$CMAKE_INSTALL_PREFIX/share/CycloneDDS and build with colcon as usual.

11 Likes

update: Eclipse Cyclone DDS has been refactored to build easily with ROS 2 using colcon. Drop it in and build it, try it and give feedback. We really like GitHub issues😁 rmw_cyclonedds is being contributed in ROS 2 Eloquent.

tip: if your wifi has problems with multicast, then configuring DDS to use multicast only for discovery (SPDP - Simple Endpoint Discovery Protocol) can fix that

<AllowMulticast>spdp</AllowMulticast>

cyclonedds autodetects wifi and self-configures for SPDP

excerpted from another thread, @eboasson says: Eclipse Cyclone DDS today gives you a pretty decent small message latency over loopback on 8 year old 3.5GHz Xeon E3-1270 running Ubuntu 16 … you see it comes out rather well for the small ones, even though it uses the loopback interface, and fares not so badly against the latencies mentioned earlier using a shared memory transport for the large ones.

size       latency [0]
(bytes!)   (microseconds)
-------------------------
      4 [1]     10
     16         11
    128         11
   1024         13
   4096         16 [2]
  16384         28
  32768         44
  60000         67
 100000        103
 200000        202
 500000        473
1000000       1088

[0] median latency as measured by doing round-trips as fast as possible and halving the measured round-trip time, using reliable communications …
[1] keyless topic of one int32_t, the others have an int32_t key field
(always set to 0) and an octet sequence;
[2] this is with a fragmenting threshold set large enough to not fragment the ones that fit in a single UDP datagram; with the default setting the numbers are worse.