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

Non-DDS-based RMW implementation

This is to announce what we believe is the first ROS2 RMW implementation that is not based on RTPS or DDS, you can find it here It runs over Intel’s Distributed Pub/Sub protocol for IoT (imaginatively named DPS-for-IoT) Full documentation for the DPS protocol and APIs is here

The base protocol is largely complete but we are working on some QoS features needed by ROS2. The package has been tested on Bouncy on Ubuntu 18.04 and Windows 10. Most of the ROS2 test cases are currently passing. The RMW implementation uses CBOR for payload serialization and the DPS API has a handy JSON translator. Without saying if this is a good or bad thing, this makes is easy to send or receive ROS2 messages without actually running any ROS2 code.

We welcome community participation and contributions to either the RMW or DPS code bases.


@GregBurns It’s awesome for your work, but before digging deeply to the Intel DPS, could you please brief what’s the essential difference between Intel DPS and DDS ? Especially the advantage/use cases over DDS or it’s merely another counterpart of DDS for ROS2 ?
Generally speaking, I personally think that it will be pretty interesting if it can bring ROS2 robotics to another level from IoT perspective, but not sure whether it’s the case. Thanks !


:+1: on the release, but there are at least two non-DDS based RMW implementations ‘out there’ already: an OPC-UA one (presented at the ROS-I 2016 conference) and one using NDN (ROS2 on microcontrollers with RIOT).

Probably not as polished as rmw_dps, but they were ‘frist’ :wink:


Thank you for pointing this out, I stand corrected about being the “first” non-DDS implementation.



This is covered in the wiki but some of the high-level features are:

Full-distributed (no broker)

Built-in security – messages are authenticates and encrypted end-to-end (node-to-node)

Publications and subscriptions can have multiple topic strings (subs only match if all required topics are present)

MQTT-like wild-card matching (+ and #)

MQTT-like retained messages, but with TTL

Forms mesh overlay network with hop-by-hop routing based on subscriptions

Automatic subnet bridging- container and virtual network friendly

Supports UDP multicast and unicast

Built-in support for RPC

Built-in support for data series

Simple protocol designed to be implementable on MCU’s

Protocol itself is payload agnostic

Not all of these features are currently exploited in the RMW layer.

Regardless of who got there first, it’s great to see these different RMW implementations coming into existence! It offers encouragement that the design decision in ROS 2 to develop and adhere to the RMW abstraction layer was a good one. No matter how effective DDS (RTPS) is for some domains, there are going to be applications where other middleware backends are a better fit and now we can accommodate those needs without changing the ROS 2 code on top.


I went reading through the DPS docs and was concerned that the security section made no mention of a access control (like with DDS’s specification):

I then spotted a brief subsection in the tutorials page about adding support for access control by interjecting custom policy functionality that could operate on the context of the connection, be it subscription, publication or acknowledgement control:

While that seems like a good start, I’d like to see a default plugin that could be shared among client libraries to maintain interoperability. I fear leaving everyone to writing their own Policy Enforcement Point (PEP) and/or Policy Decision Point (PDP) could lead to inconsistencies in interpretation and enforcement of access control implementations.

Also looks like policy to enforce would then reside within the local participant, and not necessarily originate from the remote subject unless some additional handshaking exchange is introduced. This would otherwise require distributing policy updates to the entire IoT network rather then just to the participant/subjects affected. Perhaps the policies could be bound to subjects via extensions to the signed certs when using DTLS with certificates, though I'm not sure I'd recommend that approach.

Good points on the policy aspects of DPS, would you mind starting the discussion by creating an issue at That will be the best way to track future work.

@gavanderhoorn, was code for this RMW implementation released? I couldn’t find it.

No, that never got released.

I’ll see what the status of it is, or what happened to that effort.

I’m trying to learn more about the DPS, I’m not sure if this is the right thread to ask this question.
I followed the installation instructions for it and got it build successfully. (

After doing this, I switched from default rmw to rmw_dps by specifying the environment variable.

export RMW_IMPLEMENTATION=rmw_dps_cpp

And then I tried running talker demo (ros2 run demo_nodes_cpp talker) and listener demo node, but the listener node couldn’t get the read the message. When I tried to echo the topic from talker node, I got this message:

Could not determine the type for the passed topic

Could someone point out what is going on here?
Thank you!


I do not know very much of DPS, but i would make issues on rmw_dps/issues instead.

Thank you for letting me know.