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

Restricting communication between robots

How will ros2 work with multipel robots and restricting communication between the robots?

Is there any mechanism now that can be used? Is this supposed to be solved by the Quality of Service specification?

I want certain topics to just be available inside the robot were the network is on cable.

1 Like

You can set the DDS Domain ID. On ROS2 it’s called ROS_DOMAIN_ID (Not sure about the spelling)
I think it should be enough to export it as an environment variable.

For that to work I think you need to be able to set the domain id on a topic. Is that possible? Or have different namespace for internal and external messages and possibility to set domain id and QoS per namespace and topic.

We also have the caser were data sent intenrlly have different QoS specification than data sent externally. Is that supported in any way?

Ahh sry, didn’t see you wanted certain topics for both robots available. In this case I think using namespaces for the other topics should be the thing you are looking for.

In theory DDS supports applications that use multiple DDS Domain IDs but I don’t think ROS2 allows this.

But even if I use different topics somebody can start a subscription by mistake and kill the wifi.

The solution I am thinking of is:

  • Use namespace topics inside the robot
  • For all inter robot communication use topics without namespace

I then just have to trust that nobody subscribes on the namespace topics between robots. What I wantes was a techical way to make it impossible.

If you want to enforce connection limits we are in the process of adding support for the DDS Security specification. That would allow you to prevent connections between the robots if you deploy certificates appropriately.

A DDS person would tell you to use partitions, probably. For us, since we’re currently using DDS partitions in our implementation and don’t expose them through the ROS 2 api, I would advise you to just use ROS namespaces. We’re planning on having more sophisticated at runtime and during runtime topic manipulation to help with this.

I gained a lot of insight on what would be needed to deal with situations like this when working on the capabilities package as part of the rocon project. I think with some more options to configure the namespaces (remapping and aliasing) it will be a more tractable problem, but we don’t have those features yet.

A stronger separation would be to have different domains and have some bridges to expose parts of one domain to another.

What about a capability to specify that a specific namespace uses a specific domain? It sounds clunky, but if a neat way could be found to do it, that would give proper separation.

Has there been any advancement in this regard?

Specifically I believe there are two issues here, how to handle multiple independent robots on a same physical network, and how to have some sort of multirobot communication.

Regarding the first issue, from the comments above it it looks like either setting a different ROS_DOMAIN_ID or using namespaces might be enough.

But each seems to be either limited or cumbersome when compared to the old “use different ROS_MASTER_URI”.

If we need a separate domain id per physical robot, as more robots are distributed, having non-conflicting domain ids seems extremely difficult.

On the other hand, using a different namespace for each robot’s nodes and topics might do the trick, but in my opinion it needs to be implicitly supported in ROS2, so that it can be transparent to the user after configuring it.

Let’s say you want to distribute an rviz2 configuration for visualizing the tf data of the Robot Foo, you add a display of /tf.

If you have two of these robots in your office, foo-1 and foo-2, in ROS1 you’d export the ROS_MASTER_URI to the corresponding hostname and open rviz.

There needs to be a way of doing this so that when the user opens rviz (or any other tool, or launches a node of it’s own), it doesn’t need to change the topic manually.

Is there anything that I’m missing?

As a DDS person and someone who built distributed industrial robotics systems I can tell you that partitions are by far the best way to go when trying to build such a system. DDS partitions are hierarchical and support wildcards.

So the general approach is to publish all robot internal data on a partition called ‘robot-X’.

It gets more complicated when other systems like a global TF is involved. So a robot might want to know all local TFs and TFs provided by a external map server but not TFs from other robots. In this case the robot can subscribe to its local partition and to a global partition.

Also, the use case of remote diagnostic systems is covered as they can on demand access all topics of a specific robot by just accessing the proper partition.

I think it is really important to remove dependency of ROS 2 from DDS partitions and open them up for usage of the end user.

To be clear, as of the Bouncy release of ROS2, we have stopped using partitions for ROS2 internal use. That means they now should be available for end-user usage (though there are no provisions for them in the RMW API right now, so it would have to be configured “outside” of ROS2).

Great news! Thank you!