The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
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
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
