prefix for multi robot system

[DaisukeUra]

Hi,
I'm trying to control multi robots using ros2_control.
The information in this repository has been very helpful and I appreciate it.

Now, the code says that "If changed then also joint names in the controllers' configuration have to be updated."
So, I must modify a .yaml file for each robot, right?

I think it is useful for multi-robot control to be able to automatically add a prefix for the controller's joint name.
Is there any chance that this feature will be implemented?

ros2_control_demos/ros2_control_demo_bringup/launch/diffbot_system.launch.py

Lines 58 to 62 in 2dc7c37

	"prefix",
	default_value='""',
	description="Prefix of the joint names, useful for \
	multi-robot setup. If changed than also joint names in the controllers' configuration \
	have to be updated.",

Thanks,
Daisuke

[olivier-stasse]

This is an interesting feature.

Could you elaborate on the scenario ? Do you have a working example to start with ?

[DaisukeUra]

I assuming multi-robots controlled with autonomous or teleoperation.
They are homogeneous and have a unique identifier (such as hostname or mac address, anything unique).
I'll use the identifier to divide the namespace.
Basically, they work autonomously but when any trouble occurs, it should solve by teleoperation.

I would have to modify controller.yaml for each robot.
It might be good with few robots but the more we have, the harder it gets.
Ideally, I would like to be able to join the multi-robot ROS2 network as soon as I clone the system and turn it on.

For now, I put the substitution characters in controller.yaml and replace them in launch.py.

[destogl]

Hi, this is very intriguing feature. Just to clarify your use-case:

• you are using the same URDF/XACRO for each robot in our multi-robot system
• then for each robot you set different prefix so that their joint names are unique
• the issue you have is that you theoretically need a separate "controllers.yaml" file for each robot because of mapping of controller to joints

Did I get this right?

Your approach seems correct and simplest to implement as of now.
What is actually disturbing with it?
How do you imagine this should be handled?

Which controller are you using? A potential solution could be to add "joint_name_prefix" parameter in the controller and then support it. (Not sure if this will solve the problem directly).

[DaisukeUra]

use-case

Yes, that's right.

I use forward_command_controller/ForwardCommandController ( rrbot_system_position_only.launch.py based).
I want to handle multiple similar groups easily, like namespace.
My approach seems symptomatic.
Getting it to work well is a very enjoyable task for me, but it can be very annoying for others.

to add "joint_name_prefix" parameter

It seems a good way than my approach.
I consider making a controller that ForwardCommandController based for use that method.
It might be confusing with namespaces and prefixes, but I'll try it anyway.

I think the multi-robot use case is one of the most important features of ROS2.
It would be nice to have some typical use cases as an example in ros2_control.

[olivier-stasse]

I agree, but they are several possible scenarios.
For now the most "simple" one seems to have one HardwareInterface with several systems.
Checking already this scenario would be interesting.
It could be for instance two rrbot and a slider which have all a fixed base.
It seems to me that this one could be done with the current version of ros_control

Another scenario could be an intemittent compound robot. A mobile robot with an arm (mobile_robot=diffbot + rrbot) moving around independently, approching another rrbot (snd_rrbot), create temporarly a combined robot (mobile_robot + snd_rrbot) to interact. This one seems way more complicated. Several implementations are possible and honestly I do not have a strong opinion on this and would be interested to have feedback on this one.

[DaisukeUra]

I assumed the first scenario but interesting in the second one.
It's a task like an excavator loading a dump truck.
The idea which creating temporarily a combined robot looks good to me.
We can attend to main tasks and be able to don't care which robot we teleoperate with.

I haven't enough idea about the second scenario.
However, the collaboration of robots will increase in the future.
I'll think about it.