I’d like to bring our point of view from the Fast DDS development team. I apologize if the post is a bit long, but I think there are many things to consider here.
DDS domains concern the DomainParticipant entities, and they physically limit the discovery of peer DomainParticipants when using Simple Discovery Protocol (the standard discovery protocol in the DDS specification) by assigning different multicast ports for DomainParticipants in different domains. This way, announcements from DomainParticipants of one domain are not received by DomainParticipants in other domains. The way this applies to ROS 2 (since Foxy) is that each context has one DDS DomainParticipant entity, meaning that the domains apply to ROS 2 contexts (not nodes, which “live” inside a context).
Partitions on the other hand represent a logical isolation within a domain at the DDS Publisher/Subscriber level. This means that all the entities in the domain discover each other, but publishers and subscribers do not match unless they share at least one partition. Whereas the domain is set on DomainParticipant creation and it is not mutable, partitions can change at run time, meaning that a publisher/subscriber can be included in any partition at any time, which will trigger the matching mechanism with the entities in that new partition.
With these two concepts in place, it is possible to create different “sub-networks” using domains, and different “allowed” connections within a domain using partitions.
While domain configuration can be done on ROS 2 using an environment variable, partitions are not that straightforward to set up since there is no API (to my knowledge) to do that. However, Fast DDS offers a “tangencial” way of configuring the underlying DDS entities using XML configuration files (where you can configure partitions). This is explained here. However, this does not come without limitations that have yet to be worked out:
Since ROS 2 does not offer the possibility to create the context, publisher, or subscription with a user defined name, the only thing that can be done is to set a default XML profile for each entity kind (mind that it is possible to load different XML files for different applications, since the file is defined using an environment variable
FASTRTPS_DEFAULT_PROFILES_FILE). This of course limits the number of entities that can be configured this way, since the call to
ros2 runin one terminal session will configure all the DomainParticipants (ROS 2 context), DataWriters (ROS 2 publishers), and DataReaders (ROS 2 subscriptions) in the same manner.
Starting in ROS 2 Foxy, there is only one DomainParticipant per context (before there was one per node). This means that using XML profiles to configure nodes can only be done for the case of one node per context.
From my point of view, we are in deep need of APIs to fully configure the underlying DDS entities from the application layer, since it is often the case that users would benefit from DDS functionalities that are already available on the DDS implementations, but are not accessible from ROS 2.
Regarding the good old
ROS_MASTER_URI, we have been collaborating with OpenRobotics to bring a similar functionality to ROS 2 using our own alternative discovery protocol that we call “Discovery Server”. This functionality is already available on ROS 2 Eloquent testing branch and will make its way into Foxy in the upcoming weeks. With it, you can instantiate a Server much as the ROS 1 master, and then configure your nodes as clients using an environment variable. Even without the full mechanism in place in Foxy (executable + environment variable), you can still use the Discovery Server protocol, since Foxy’s Fast DDS version has it. I gave a presentation on how to do that for ROS 2 Eloquent in the last ROS Developers Day and you can see the video here (from 5:30:10 to 6:13:00). Stay tuned!