multi-robot in ROS2

[Shawn Schaerer]

I am interested to find out how multi-robot support is being planned in ROS2.  I am currently working on my own solution using FASTRTPS (ROS1 based) and have some high level questions.

I'll start the discussion off with a top level question:

Will each robot be a separate domain or some other logical grouping?  I assume that ROS2 will follow DDS and not build some additional protocol / discover mechanism on top
.


Shawn

[Dirk Thomas]

Hi Shawn,

we haven't gotten around to multi-robot use cases with the ROS 2 development yet. We are still very busy getting the various parts for a single robot working well. Therefore I don't have an answer for you atm.

That being said I certainly expect us to use DDS for the communication between robots as well since the protocol is perfectly capable to handle that use case. I don't see a reason to use a different protocol.

If each robot should use a separate domain, a separate partition, or some namespacing approach is not clear to me yet. The pros and cons need to be considered carefully (probably with some benchmarking), e.g. the overhead to discover "everything" when they share the same domain vs. the overhead to join multiple domains for local and remote communication.

- Dirk

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ros+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shawn Schaerer]

Thanks Dirk.

I will move forward with my own testing.
I'd be interested in dissing this further when you are working on it.

Shawn

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.

[William Woodall]

I'll just add to what Dirk said, by saying that I don't know of a "best" solution for multi-robot as the use cases in that category vary quite a bit. In my experience working on the capability_server with the Rocon project:

https://github.com/osrf/capabilities

http://www.robotconcert.org/index.php/Main_Page

I found that a lot of what was lacking was functionality in the middleware for partitioning and dynamically adjusting the robots communications during runtime. Now, whether or not that partitioning needed to be virtually/logically separated (discovery is shared, but communication is logically segmented) or physically separated (the two parts of the system talk on different ports but there is some extra-middleware coordination between the physical groups) is not clear to me. I think the physically separated groups made since for the applications of the ROCON project, but for other projects you might want discovery between robots to be shared, but communication logically partitioned.

If you go with physically partitioning the systems, then you have to figure out how to relay information between the groups. ROS 1 didn't make this easy because you could not have two nodes in a single process much less two nodes in a process, each on a different physical network. In ROS 2 you'll be able to have two nodes in a single process, one node on each physically separated network that share information between each other in the processes' memory. But even that strategy may not be preferred, which is part of the problem (it's not clear what is the best way).

If you use logical partitioning, then you have a few ways of organizing that. In ROS 1 you'd do it with namespaces, but with DDS you also have the option of using "keyed" data. I believe that you can accomplish anything with one that you can the other, but there might be implications about the intuitiveness of the design and introspection or implications to do with performance which might make you prefer one over the other. We don't expose the keyed data feature in ROS 2 yet, but it would be interesting to figure out if it is needed for multi-robot applications.

Whether you're physically or logically separating the parts of the multi-robot system, you need to pass some information between parts of the system. I found it frustrating that I could not dynamically remap a topic or alias a topic to another name after a node was running. This was a desirable feature in the ROCON system because apps which used the robots started after the robot was started. And services, like navigation, could be used by multiple other things simultaneously which lead to the need to be flexible with routing of information within the robot and without. Without these features, you had to change the application code or restart the navigation processes, or in some situations you could not resolve the conflict. I think that some of these flexibilities which we want to have in ROS 2 will help with this. On the other hand, there are almost certainly systems where the flexibility is a liability not a feature and so, as I said a few times now, there is no clear best solution. So instead, I'm just trying to identify pain points from experience and talking with people and then address them in the design of ROS 2.

Not sure that gives you any helpful direction, but that's how I see the issue. Trying to address symptoms to support a variety of solutions.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ros+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[Shawn Schaerer]

Thanks William.

I am going to explore keyed topics.  From what I have read on DDS, this seems to be the proper way of grouping robots.