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 !
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 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 https://github.com/intel/dps-for-iot/issues? That will be the best way to track future work.
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!
long time ago, but does anyone have more information about the OPCUA RMW implementation?
I can’t find any releases or other information about the author at that time.
on the release, but there are at least two non-DDS based RMW implementations ‘out there’ already: an OPC-UA one (presented at the 