using two arms with moveit, unable to get joints for both

asked 2019-03-17 20:30:56 -0500

dan gravatar image

updated 2019-03-17 23:51:52 -0500

I am setting up a robot that has two arms, setup in different namespaces (arm1, arm2), using ROS Melodic and moveit. They publish separate joint_state messages, based on the namespace (/arm1/joint_states and /arm2/joint_states) and those joint states show up correctly for both arms. The tf tree has both arms in it, with correct names (e.g., arm1_ee_link and arm2_ee_link) When I call:

arm_1 = moveit_commander.MoveGroupCommander('manipulator', '/arm1/robot_description', '/arm1'))

arm_2 = moveit_commander.MoveGroupCommander('manipulator', '/arm2/robot_description', '/arm2'))

and run:



The printed joint values are both from arm_1. If I swap the order of the MoveGroupCommander calls, so that arm_2 is created first, then the printed joint values are both from arm_2. Note that the arm1/joint_states and /arm2/joint_states topics continue to report correct results for both arms, unlike the results from the moveit get_current_joint_values() call.

I get similar results from calling:

robot_1 = moveit_commander.RobotCommander('/arm1/robot_description', '/arm1')

robot_2 = moveit_commander.RobotCommander('/arm2/robot_description', '/arm2')

and then running:

print('robot 1 state', robot_1.get_current_state())

print('robot 2 state', robot_2.get_current_state())

The printed joints are the same for robot_1_state and robot_2_state, the values are dependent on whether robot_1 or robot_2 is created first.

I am wondering if this problem is related to the one addressed by this pull request. I don't know if it got implemented.

edit retag flag offensive close merge delete


`arm_1 = moveit_commander.MoveGroupCommander('manipulator', '/arm1/robot_description', '/arm1'))`

I'm not sure this would be a problem, but it's at least strange: you're passing the same group name twice (ie: manipulator). Are you running two move_group instances?

gvdhoorn gravatar image gvdhoorn  ( 2019-03-18 02:25:29 -0500 )edit

Yes, one in each namespace. Is that not correct?

dan gravatar image dan  ( 2019-03-18 09:13:14 -0500 )edit

If you are running two move_group instances that can work, but personally I would give each group a unique name. It not only avoids confusing humans, but also potential problems with resources (ie: topics, services, parameters) being read/called/subscribed to from the/a global namespace. With unique names: you'll get errors. With identical names: you'll get none, but potential use of incorrect resources.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-18 09:41:09 -0500 )edit

Sure, that makes sense, but it does not address this particular problem. With two move groups, this is more like two identical robots than one robot with two identical arms. However, that actually makes more sense in this case, as we can scale to any number of arms by just adding move groups, rather than creating unique move groups for each case (e.g., three arms, four arms, etc).

dan gravatar image dan  ( 2019-03-19 20:51:51 -0500 )edit

My suggestion was to use different group names regardless of whether you're using multiple move_group instances, just to avoid confusion (yes, each move_group can use whatever names it wants, but in the end all of it is rather abstracted and you end up with code for arm1 asking for manipulator and code for arm2 asking for manipulator; even just for readability I'd use different names).

But as I wrote earlier: it's not an answer to your question (hence, only a comment).

gvdhoorn gravatar image gvdhoorn  ( 2019-03-20 02:24:38 -0500 )edit

did you ever find a workaround for this?

shu gravatar image shu  ( 2020-01-08 09:41:23 -0500 )edit