using two arms with moveit, unable to get joints for both
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:
print(arm_1.get_current_joint_values()
print(arm_2.get_current_joint_values()
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.
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 twomove_groupinstances?Yes, one in each namespace. Is that not correct?
If you are running two
move_groupinstances 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.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).
My suggestion was to use different group names regardless of whether you're using multiple
move_groupinstances, just to avoid confusion (yes, eachmove_groupcan use whatever names it wants, but in the end all of it is rather abstracted and you end up with code forarm1asking formanipulatorand code forarm2asking formanipulator; 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).
did you ever find a workaround for this?