0
$\begingroup$

Rosanswers logo

With MoveIt!, I'm trying to switch between two end effectors for a single arm. The purpose is to have 1 camera end effector and 1 gripper end effector. Is this what the MoveGroup setEndEffector() method was designed to do? Has anybody tried this before?

I know that somebody else in our lab is doing .setEndEffector() when the URDF contains two arms and he wants to switch between arms. Maybe that's the intended functionality.

Would it be possible, as a workaround, to have a completely separate planning group for the second end-effector? Most of the joints would be duplicated.


Originally posted by AndyZe on ROS Answers with karma: 2331 on 2017-06-26

Post score: 1


Original comments

Comment by gvdhoorn on 2017-06-26:\

Would it be possible, as a workaround, to have a completely separate planning group for the second end-effector?

yes. You can have as many groups as you want. This is often used with IKFast plugins fi where special plugins are generated for specific robot+tool combos.

Comment by AndyZe on 2017-06-26:
Do I need to destroy previous moveGroup instances before creating a new one?

Currently, if I create a second moveGroup and plan a motion, the terminal output from my executable is Aborted: Catastrophic Failure. The output from moveIt is Unable to construct goal representation.

Comment by AndyZe on 2017-06-26:
OK, I found out that the Catastrophic Failure was caused by incorrectly using moveit_setup_assistant. I wasn't overwriting some of the files where manual editing was detected. Would still like to know if it's possible to use more than 1 EE per kinematic chain.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Hey AndyZe,

the use-case you describe (camera, gripper) is how I would use getEndEffector too. Multiple end-effectors per group are clearly the intended idea of this part of the code. You filed https://github.com/ros-planning/moveit/issues/522 rather recently, and I don't think it's unlikely that there is a bug in the code for some use-cases.

For the use-case with two arms, this is only a reasonable way forward if you need to plan for both arms to move simultaneously. Otherwise it is computationally more easy to use two different planning groups and MoveGroup instances instead.

Maybe you miss a call to clearPoseTargets() in between your different planning requests?


Originally posted by v4hn with karma: 2950 on 2017-06-27

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by AndyZe on 2017-06-27:
clearPoseTargets() could be it. Thanks! I will certainly close the github issue if I find a solution. In a way, multiple EE's for one arm doesn't make sense because there can only be 1 kinematic chain.

Comment by v4hn on 2017-06-27:
if you find a solution, please explain your solution in the issue :) Maybe we can add code to point the issue out to the next user running into this.

there can only be 1 kinematic chain

wrong. you can model arbitrary joint sets as group. Also you can have a group of multiple subgroups.

Comment by AndyZe on 2017-06-27:
Ok, thanks. I mean, you can probably do this:

Arm---EE1---EE2

But not:

Arm----- EE1
     |
     |--------------EE2

Comment by v4hn on 2017-06-27:
You can create this construct, the datastructures in MoveIt as well as the Planner should support it. At the moment inverse kinematics is usually the impasse for practical applications.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.