What's the difference between ROS2 and DDS?

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.

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

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.