0
$\begingroup$

Rosanswers logo

Disclaimer that I know this question strays from the typical ROS Answers format a fair bit. But I still think this is a better medium to have this discussion than, say, ROS Discourse.

I've looked around a fair bit, and have yet to see a single "definitive" and up-to-date discussion of the steps that you need to consider to successfully launch multiple robots in ROS2. There are a number of questions already on ROS Answers, and elsewhere, that discuss things like namespaces, frame_prefix (recently readded), GroupActions, remapping topics, gazebo plugin considerations, etc, as well as a number of examples that have been posted (e.g. by Nav2, theConstruct, and others), but I feel like they are often a bit light on the "why" aspect of what's going on. I think it would be valuable to have a single resource that includes an overview of all the aspects that need to be considered, particularly when moving from a single robot to multiple robots, and of any "best practices" that people have developed.

Some questions that I've come across that would be worth answering for new users:

  • When to use namespaces vs remapping? When might you need to use both?
  • When its worth using GroupAction
  • When should you use frame_prefix? When should you add a prefix directly in your URDF/Xacro files?
  • Where do you need to apply a frame_prefix or namespace? (Gazebo plugins, ros2_control config files, robot_state_publisher)?
  • What are the best ways to avoid redundant definitions of robot parameters (e.g. in config files that could be identical except for a prefix or ID parameter)?
  • When should you use fully qualified vs relative names? Are there any common cases other than /tf where you would not want to use relative topic names?
  • When should you use a single tf tree for all robots, and when should you use a different tf tree for each robot?
  • What considerations should you take when writing an Xacro file to ensure you can easily extend from single-robot to multi-robot use cases?
  • What's the best way to spawn multiple robots in Gazebo?

I'd be happy to take a stab at answering some of these items myself, but really I'd like to hear from people with more experience to glean from their working experience. If anyone has any additional questions, please comment them below and I can add them to the list. I'd also be happy to compile feedback into a single wiki or tutorial type document.

Thanks in advance!


Originally posted by shonigmann on ROS Answers with karma: 1567 on 2021-10-12

Post score: 4


Original comments

Comment by gvdhoorn on 2021-10-13:\

When should you use tf_prefix?

According to p/robot_state_publisher/github-ros-robot_state_publisher, the parameter is called frame_prefix now. Not tf_prefix.

Comment by shonigmann on 2021-10-13:
Noted - thanks for the correction

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

The issue you're going to run into is that there aren't any.

I'd love to have an REP or some discussions as a broader community to set those standards so that we can meaningfully start to create multi-robot tooling and know how all of the data is going to appear (and probably build some wrapper utilities for). This is one of the major reasons we in Nav2-land haven't put any time or effort into multi-robot planners, fleet management, etc because its not worth our time to set some bespoke standards that won't be made available for other projects or tools in the future.

At some point in Discourse, I suggested we do such a thing. I think we're in a situation that's a mixture of "we don't know yet" and "we don't feel comfortable enough sharing that information". We need some ROS 2 users doing such a thing to be open to sharing their best practices that we can use to rectify across a few organizations and some key people to develop those standards/REP/best practices. I can guess at what I think I might want if I was building a set of intercommunicating warehouse robots, but since I'm not actually doing it, it would be a bit inappropriate for me to project my thoughts as fact.

I would very much so look forward to having those discussions and starting a small temporary working group to establish those practices and write something up that can be used as the basis of tools / ROS 2 integrations for multi-robot systems operating on the same or different DDS domains.


As to my thoughts on your particular questions, for one viewpoint

When to use namespaces vs remapping? When might you need to use both?

I would insert an entire robot's bringup/system into a namespace so that all of the topics / services / etc for a single robot in a multi-robot system are under the /my_robot_N namespace(s). I wouldn't try to remap individual topics, just throw everything out of the global namespace and into robot specific bins.

When its worth using GroupAction

There are many reasons to use this, but not all of them are multi-robot related, as you have probably seen from Nav2's launch directory. One reason to use it would be such that you can apply a PushRosNamespace for everything inside of the group like we do here. Makes an easy way to shove everything into a particular namespace for the above answer's rational on binning the robot sub-spaces.

When should you use frame_prefix? When should you add a prefix directly in your URDF/Xacro files? Where do you need to apply a frame_prefix or namespace? (Gazebo plugins, ros2_control config files, robot_state_publisher)? When should you use fully qualified vs relative names? Are there any common cases other than /tf where you would not want to use relative topic names? When should you use a single tf tree for all robots, and when should you use a different tf tree for each robot?

Can't answer that one articulately at the moment. The prevailing standard set up by OSRF is that they've removed "prefix" in TF2, which I disagree with for exactly these multirobot situations. So there's conflict there that needs more explicit discussion. I would want to bin my TF messages either by having different /<my_robot>/tf topics or having sub-namespaces to the frames in the TF topic to be easily able to distinguish one robot from another's updates. I would prefer different topics for obvious bandwidth reasons, but I think those were implicitly removed from ROS 2 as a parameter.

What are the best ways to avoid redundant definitions of robot parameters (e.g. in config files that could be identical except for a prefix or ID parameter)?

I wouldn't. You're expecting your fleet is homogeneous. I'd make sure I made everything explicitly clear that this wasn't an assumption. All robots should be treated as their own unique silos which may be different in hardware, jobs/tasks, sensors requiring different setups.

What considerations should you take when writing an Xacro file to ensure you can easily extend from single-robot to multi-robot use cases?

The usual Xacro best practices (make macros for common things and create URDFs of those primitives) will be just fine. The fact that you spawn N URDFs doesn't matter.

What's the best way to spawn multiple robots in Gazebo?

https://github.com/ros-simulation/gazebo_ros_pkgs/blob/ros2/gazebo_ros/scripts/spawn_entity.py


Originally posted by stevemacenski with karma: 8272 on 2021-10-13

This answer was ACCEPTED on the original site

Post score: 5


Original comments

Comment by gvdhoorn on 2021-10-14:
There have been some people/orgs pretty open about how they approach this. See Restricting communication between robots and the linked ros2/design#261 fi.

I agree though that without distilling generalised best-practices from those sorts of inputs, this isn't going to get solved any time soon.

The prevailing standard set up by OSRF is that they've removed "prefix" in TF2, which I disagree with for exactly these multirobot situations.

it took a while, but it was actually put back. It's not called tf_prefix any more (to decouple it from the old behaviour / user expectations), but frame_prefix is essentially the same thing.

Comment by stevemacenski on 2021-10-14:
Good to note! Thanks! I didn't see that TF change. It sounds like changes to add a prefix to the frames on the TF topic, not the ability to easily change the TF topic for separate ones for separate robots, correct?

Comment by gvdhoorn on 2021-10-14:
Afaik, tf_prefix never caused new TF topics to be used. It was only for prefixing all frames with a prefix?

not the ability to easily change the TF topic for separate ones for separate robots, correct?

Wouldn't that be done using namespacing? The prefixes are there to avoid name-clashes in consumers which subscribe to all, namespaced, TF topics.

Another option would be remapping, but that would be basically the same as namespacing I believe.

Comment by ljaniec on 2021-12-14:
There are some standards/sources which right now try to address control of many robots and communication between them:

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.