Running multiple move_groups and/or robot arms

[felixvd]

It appears that there is no solid reference for people who want to run multiple robot arms in ROS. There are a number of ROS Answers posts, but I actually have trouble finding them myself when I want to link them, so they are somewhat ephemeral knowledge. It is also unclear what the best practice is. It would be great if a tutorial covered multiple robot arms in a scene.

The tutorial should answer questions like:

• Should each arm have its own move_group?
• Should it be in a namespace?
• How to plan for multiple arms' motions at the same time?

The way I have done it in the past is (and my understanding of best practice) is:

1. All robot arms should be defined in the same URDF
2. Each arm should have its own move_group
3. If arms need to move in sync, they can be defined in a combined move_group

I have no experience namespacing MoveIt instances, or running robots completely separately from each other in different namespaces. I suspect that both may try to access a global namespace and clash (e.g. when publishing their robot_description to it by default), and that the two robots would not know anything about each other, which is obviously problematic. My impression is that it would be at best fiddly, and at worst unstable. It would be interesting to hear if there are valid use cases I am not thinking of. I suspect @gavanderhoorn may have some in mind.

If anyone else has comments about this, this would be a good thread to pool them. Links to relevant ROS answers posts or other resources are very welcome, too.

Lastly, since the solution I talked about at the MoveIt workshop 2019 is fully open, I could base an example for a tutorial off of it at some point.

edit: I added some example code to this ROS answer.

[welcome]

Thanks for reporting an issue. Because we're a volunteer community, providing a pull request with suggested changes is always welcomed.

[kappa95]

I have the same question... Actually I'm working on a Yumi and in order to move the same arms in the same time I tried to plan the motion for each arm and extracted the points of the joints in order to have the positions... Later I had used the group associated to the 2 arms and I used the points.
In anycase moving a single arm didn't consider the collision with the other in motion I think. So it is not a valid method, and anyway you can't provide information about the speed and acceleration planned...

[felixvd]

Related: moveit/moveit#2287

[jliukkonen]

I can start tackling this as part of WMD21. At PickNik, we've implemented running multiple arms simultaneously at least once, maybe even twice for different use cases. There are limitations of course. Simultaneous trajectory execution with overlapping workspaces will not be safe as the trajectory plans are collision checked once and not continuously during execution. Servoing, however, will work reasonably well as it utilizes continuous collision checking.

[ur10]

Hello, I am in the process of writing a short tutorial for this. Can someone kindly suggest best practices for writing such tutorials?

[AndyZe]

I would say, take a look at some of the examples here.

You can use an online RST viewer to quickly check how things look.

And the README has a nice hint on how to build the webpage and display it locally:

cd $COLCON_WS/src/moveit2_tutorials
source /opt/ros/$ROS_DISTRO/setup.bash
./build_locally.sh

I know that running multiple arms involves a lot of namespacing but I'm foggy on the details, so it would be great to have a tutorial.

[v4hn]

I just noticed this thread because of the new posts.

Simultaneous trajectory execution with overlapping workspaces will not be safe as the trajectory plans are collision checked once and not continuously during execution.

This is wrong. MoveIt's standard pipeline supports online collision checking, incorporating planning scene changes and it was even featured by Acorn Pooley in the announcement video.
But you are right, planning&execution of independent motions will not be safe nonetheless, because these checks do not consider the expected motions of other robot parts during validation (they don't know them).
Something like https://github.com/TAMS-Group/move_group_online_collision_predictor can work better there (but has other shortcomings).

Servoing, however, will work reasonably well as it utilizes continuous collision checking.

Just to avoid overloaded terminology, you mean online collision checking. The collision checks in moveit_servo are still done for discrete points in time.

Sorry for bitching @jliukkonen 🌷

[jliukkonen]

Thanks for the comments @v4hn! I didn't realize the selected path is validated against the latest planning scene online. But if I understand you correctly, my point still stands. It is quite possible, likely even, that there are two arms and both of their paths seem to be collision free at moment t and as they execute towards their next waypoints, they end up in collision with each other at moment t+1. My understanding is also that Servo has prediction in its collision checking, which helps quite a bit. Please correct me if I'm wrong.

[AndyZe]

My understanding is also that Servo has prediction in its collision checking

Yeah, it has a feature to do that but it really doesn't work so well, due to ROS message latency for one thing.

[jliukkonen]

By the way, my WMD21 plans to write a tutorial for running multiple arms failed miserably as I ended tangled up in modifying MoveIt Resources packages for different arms so that their URDF's (and the rest) would support namespacing. I might continue on this project later though but first I'd like to see those resource packages being improved. I posted a PR, see here for more details: moveit/moveit_resources#53

[v4hn]

It is quite possible, likely even, that there are two arms and both of their paths seem to be collision free at moment t and as they execute towards their next waypoints, they end up in collision with each other at moment t+1.

Whether or not it's likely depends on the tasks of course, but it's possible. Note that the logic I linked checks the whole remaining path, not just the next waypoint. But because the mechanism can't easily know about the whole trajectory of the other arm, it usually makes so much more sense to execute the plans together.

My understanding is also that Servo has prediction in its collision checking

Yeah, it has a feature to do that but it really doesn't work so well, due to ROS message latency for one thing.

Could you link some code here? I can't easily find it...
The approach I took in the online_collision_predictor was to extrapolate based on velocity, but knowing the full trajectory should always be preferred.

[AndyZe]

OK, that sounds similar to what I did. Find the closest collision and calculate minimum stop time based on current velocity.

https://github.com/ros-planning/moveit/blob/a8326da6cc420000b399e78f4048bf5df2abefca/moveit_ros/moveit_servo/src/servo_calcs.cpp#L905

https://github.com/ros-planning/moveit/blob/a8326da6cc420000b399e78f4048bf5df2abefca/moveit_ros/moveit_servo/src/collision_check.cpp#L162

[felixvd]

Simultaneous trajectory execution with overlapping workspaces will not be safe as the trajectory plans are collision checked once and not continuously during execution.

This is wrong. MoveIt's standard pipeline supports online collision checking, incorporating planning scene changes and it was even featured by Acorn Pooley in the announcement video.

In moveit/moveit#2287 I suggested to use TrajectoryExecutionManager to extend this online collision checking to multiple trajectories, since it knows about all active trajectories. Please feel free to share thoughts. It might fit well in that space of plan_execution.cpp too, if a new trajectory execution triggered something similar.

[Infinity8sailor]

It appears that there is no solid reference for people who want to run multiple robot arms in ROS. There are a number of ROS Answers posts, but I actually have trouble finding them myself when I want to link them, so they are somewhat ephemeral knowledge. It is also unclear what the best practice is. It would be great if a tutorial covered multiple robot arms in a scene.

The tutorial should answer questions like:

• Should each arm have its own move_group?
• Should it be in a namespace?
• How to plan for multiple arms' motions at the same time?

The way I have done it in the past is (and my understanding of best practice) is:

1. All robot arms should be defined in the same URDF
2. Each arm should have its own move_group
3. If arms need to move in sync, they can be defined in a combined move_group

i had made made one tutorial using ur5 arm. i just noticed that moveit tutorials are using panda arm each time.
can i continue with ur5 or should change to panda?

[tylerjw]

i had made made one tutorial using ur5 arm. i just noticed that moveit tutorials are using panda arm each time.
can i continue with ur5 or should change to panda?

For some historical reason all tutorials are based on the panda_moveit_config. If you based your tutorial on that it would make it easier to get reviewed/merged. However, using multiple ur5s as an example seems like it'd also be useful.

[v4hn]

For some historical reason all tutorials are based on the [panda_moveit_config](https://github.com/ros-planning/panda_moveit_config). If you based your tutorial on that it would make it easier to get reviewed/merged. However, using multiple ur5s as an example seems like it'd also be useful.

The "historical" reason was funding for PickNik to rework the tutorials if they make panda the main demonstration robot. Mike did a great job doing that. I'm not sure whether the terms of this contract are still in effect. - We can't force third-party contributions to use the robot if they use anything else - Nonetheless it's nice to have streamlined tutorials for new users - We should definitely avoid adding dependencies to packages we do not directly control in this organization

[ur10]

I have opened a pull request that provides tutorial for synchronous movement, here

[Infinity8sailor]

For some historical reason all tutorials are based on the panda_moveit_config. If you based your tutorial on that it would make it easier to get reviewed/merged. However, using multiple ur5s as an example seems like it'd also be useful.
The "historical" reason was funding for PickNik to rework the tutorials if they make panda the main demonstration robot. Mike did a great job doing that. I'm not sure whether the terms of this contract are still in effect. - We can't force third-party contributions to use the robot if they use anything else - Nonetheless it's nice to have streamlined tutorials for new users - We should definitely avoid adding dependencies to packages we do not directly control in this organization

it seems like UR5 tutorial is not prefered.
anyways i had uploaded the expected code to my github link to code
here is cpp code for multiple arm move.
here is youtube demo i wanted to add in tutorial
just wanted to ask, Was this your expectation or something else?

[omar1slam]

Hi, so I have a robot with two arms and I've made one planning group for the whole robot.
On RVIZ it plans for both arms and executes simultaneously, but when I try to do it in code it fails to find a path, even though when I comment out one target pose for one arm the other works just fine.
Can anybody see what seems to be the problem?

[felixvd]

Can't say, but my guess is that you are somehow not setting the targets correctly (e.g. unexpected orientation, target not applied to the correct end effectors etc)