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

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 https://github.com/ros2/rmw_dps It runs over Intel’s Distributed Pub/Sub protocol for IoT (imaginatively named DPS-for-IoT) https://github.com/intel/dps-for-iot Full documentation for the DPS protocol and APIs is here https://intel.github.io/dps-for-iot

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.

7 Likes

@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 !

2 Likes

:+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.

Greg.

2 Likes

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.

5 Likes

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):

https://intel.github.io/dps-for-iot/security.html

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:

https://intel.github.io/dps-for-iot/tutorials-security.html#adding-access-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 https://github.com/intel/dps-for-iot/issues? That will be the best way to track future work.