ROS2和DDS學習筆記

參考資料鏈接：

1. ROS on DDS：http://design.ros2.org/articles/ros_on_dds.html
2. ROS 2 and different DDS/RTPS vendors：https://index.ros.org/doc/ros2/Concepts/DDS-and-ROS-middleware-implementations/
3. ROS2 + DDS: When Ecosystems Merge：https://www.rti.com/blog/ros2-dds-when-ecosystems-merge
4. What's the difference between ROS2 and DDS?：https://stackoverflow.com/questions/51187676/whats-the-difference-between-ros2-and-dds

稍後學習後補充

What's the difference between ROS2 and DDS?

ROS2 is a distributed architecture using publisher/subscriber messaging between nodes.

ROS2 has taken a different approach in its messaging layer and now employs the industry standard called Data Distributed Services (DDS).

But, DDS is a middleware for communication, also support publisher/subscriber.

So, we can use DDS directly, why use ROS2?

Ecosystem

DDS is a communication standard proposed by OMG. It's targeted market is more general, like military, air-traffic control, autonomous vehicles, medical devices .. There are few vendors providing enterprise and open source version as well but only few people or the market can decide their future works or design.

Anyone who want to adopt DDS to their product needs to begin from scratch.

ROS2 is more like an ecosystem. The leader of ROS2 - OSRF provide an ecosystem, documents and friendly framework for those who want to create their robotic application.

Anyone can submit their thoughts to the core design or provide their own contribution to the community.

More technical

Pub/Sub model difference between ROS and DDS

DDS

Participant, topic, publisher, subscriber, datareader and datawriter

yes, DDS has publisher and subscriber. Moreover, it has participant, topic, publisher, subscriber, datawriter and datareader, they are called an entity in the DDS's data shared space.

Each entity owns different QoS attributes and affect how entity manage the data delivery or data lifecycle.

• Participant

Participant controls the whole entities's creation, deletion, grouping. It has ability to know new entity join or leave.

Different participant is identified by the domain ID (integer).

• Topic

Topic is like a target owning the QoS information, that datawriter and datareader can link to each other.

• Publisher and Subscriber

Publisher and subscriber control the data delivery and data availability to it's owned datareader and datawriter.

Publisher only can have multiple datawriter, and Subscriber only can have multiple datareader.

• DataWriter and DataReader

DataWriter is the data provider and DataReader is the data consumer. They need to have the same QoS to their target topic.

DDS Topic naming:

Unlink other pub/sub model, they don't heavily use slash /, instead, they are object oriented.

ROS2

naming space and nodes.

• naming space

It's like the topic, but has the naming space.

ROS2 highly use naming space and slash /. It has naming space start with /. For example, /turtle/cmd_vel, turtle is the naming space and cmd_vel is it's base name.

• nodes

Simply the basic element which provide or consume data.

You can check the ros2 topic and service names for the ROS2 pub/sub naming design.

Conclusion

ROS2 is more focusing on the robotic application design, that eliminate the difficulty for composing the DDS complex pub/sub application.

I agree that ROS2 provides a higher level abstraction than DDS, especially for certain types of robotic applications. In addition ROS2 provides ready-made data types and components that are designed for robotics. So you get a lot of building blocks. This definitely makes it easier to build systems in that domain.

That said you need to be aware there is also a cost involved in using ROS2 rather than native DDS. One way ROS2 makes things simple is by pre-selecting a subset of Qos and information exchange pattern supported by DDS. So using ROS2 it is not possible to access certain DDS features and Qos. There is a significant number of things related to publish-subscribe communications that you can do with DDS but not using the ROS2 API over DDS. There is also lot of data types which can be defined using the DDS IDL that are not describable using the ROS2 IDL. So you are also limiting the data-types that can be sent and received, type evolution and compatibility rules, etc. For some systems these limitations may be significant. The features were added to DDS for a reason...

Performance is also negatively impacted by the added layers and the fact that certain DDS APIs are not leveraged.

Fundamentally the range of applications that DDS targets is much broader so the APIs, Qos, types etc. need to me more generic and flexible.

To add a bit on what Stoogy already wrote:

ROS is much more than just the communication layer. It provides, for example

• a lot of packages for tasks common in robotics, from basic things like transforming points between different coordinate frames to high level applications like generating a map of the environment and using it to navigate the robot through it without colliding into obstacles.
• a build system (catkin for ROS 1, colcon for ROS 2) for easily building those packages and specifying dependencies between them.
• a launch system to easily run a complex system of multiple applications that depend on each other and providing a way to easily change parameters.
• integrated physics simulation as well as visualization and monitoring tools

Thanks for adding more info about the fact that is it not only communication. It is much more as you said. For ROS2, isn't the build system colcon (the old build system was ament before the bouncy release) ? – Stoogy Jul 5 '18 at 16:10

• @Stoogy You are right about the build tool, I updated the answer. – luator Jul 6 '18 at 6:59

Indeed, ROS2 is based on DDS for the communication. (https://github.com/ros2/ros2/wiki/DDS-and-ROS-middleware-implementations)

ROS2 is used because it adds an abstraction making DDS easier to use. DDS needs lot of setup and configuration (partitions, topic name, discovery mode, message creation,...) which is done in the RMW package of ROS2. This package is also responsible to handle error when a message is published/received (taken).

You can use DDS directly (if you configure properly your publisher and subscriber you can also communicate with ROS2 publisher and subscriber) however you will have to create the message (.idl), call the generator to get the corresponding structure and sources files, create a domain, assign a topic, configure the datawriters/datareader,.. (have a look at some examples https://github.com/rticommunity/rticonnextdds-examples/tree/master/examples/listeners/c)

So ROS2 is making your life easier. Plus, there are lots of packages that can be used above the messages.