IK Performance & IK vs. Grasp Manipulator Directions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

IK Performance & IK vs. Grasp Manipulator Directions

HenningD
Hi everybody!

After I had some problems to get the 5D GraspPlanning working with ROS for our Katana, but I finally managed to get it going!

A worked my way through the 5D Grasping Example and the graspplanning_openrave.py and with some minor changes in the latter file i can now compute grasps for our Katana.

But I stumbled upon several thinks that irritated me.

1) The IK performance is quite poor:

I made some tests and out of about 2500 attempted Grasps usually ~25 are considered stable. But if any, only very few (ususally 1, max.3) out of those acutally come along with an IK solution. Which seems not enough for me, or is this quite okay?

I visualized all Grasps and had a closer look and there are at least some more that should be easily reachable.

So I went back to test the IK alone and made a performance test again, and the results looks quite good:

rosrun openrave openrave.py --database inversekinematics --robot=robots/katana_450_6m90a.robot.xml --iktype=translationdirection5d --manipname=arm --usecached --iktests=1000

gives:

openravepy._openravepy_0_4.databases.inversekinematics: success rate: 0.880000, wrong solutions: 0.000000, no solutions: 0.120000, missing solution: 0.067000

But I sample some poses randomly within a reachable part of the workspace, i only end up with a success rate of ~2%.
And taking one of the successful poses and modifing it slightly about 1-2mm usually results in not finding a solution anymore.

We thought about randomly pertubate our intended poses until we find an approximate solution, but I guess that's not the intended way. ;)

Any ideas what could go wrong here? Or is this quite normal? Should it helpful to change the precision parameter while compiling the fastik code?
I tried different setups there but that doesn't seem to make the ik computation more robust. The results are nearly equivalent.

Could this be due to the fact that we do not specify the IK Solver fully within our robot description?

As we use auto-generated collada files from our URDF descriptions, we don't want to modify the collada files by hand, but use an robot.xml file to load the .dae file with some additional information. This is how the file currently looks like:

<robot name="katana_450_6m90a" file="katana_450_6m90a.zae">
  <manipulator name="arm">
    <base>katana_base_link</base>
    <effector>katana_gripper_tool_frame</effector>
    <joints>katana_l_finger_joint katana_r_finger_joint</joints>
    <closingdirection>-1 -1</closingdirection>
    <direction>1 0 0</direction>
    <translation>0 0 -0.03</translation>
  </manipulator>
</robot>


but the equivalent part from the neuronics-katana.dae file looks like this:

<extra name="arm" type="manipulator">
        <technique profile="OpenRAVE">
                <frame_origin link="kmodel1/link0"/>
                <frame_tip link="kmodel1/link6">
                        <translate>0 0.09 0</translate>
                </frame_tip>
                <gripper_joint joint="kmodel1/joint6">
                        <closing_direction axis="./axis0">
                                <float>-1.000000</float>
                        </closing_direction>
                </gripper_joint>
                <iksolver type="Translation3D">
                    <free_joint joint="kmodel1/joint3"/>
                    <free_joint joint="kmodel1/joint4"/>
                </iksolver>
                <iksolver type="TranslationDirection5D">
               <interface_type>
                       <technique profile="OpenRAVE">
                         <interface>ikfast_katana5d</interface>
                         <plugin>ikfastsolvers</plugin>
                    </technique>
              </interface_type>
               </iksolver>
      </technique>
</extra>


Is our description missing something?

2) IK Direction != Grasp Direction:

Before adapting the orrosplanning/graspplanning_openrave.py file, I played around with the GraspPlanning Exercises [2] and while running:

        openrave.py --database grasping --robot=robots/katana_450_6m90a.robot.xml --manipulatordirection="0 1 0" --target=thinbox.kinbody.xml

with different manipulator directions, I discovered that [0 0 1] works best, which is reasonable because our gripper tool frame's z-axis points forward between the fingers.

But the direction we use to plan the IK is different, namely: [1,0,0].
A comparison with the neuronics-katana.zae model showed me, there are 2 types of manipulators with different directions specified as well. So I guess this right. But I'm still wondering why this is?

Futhermore read read this: "The manipulator definition itself also supports specifying a ‘palm direction’, which the grasper planner now uses."

Is this necessary, has what are the advantages? How can I specifiy the palm direction (or is this the manipulator direction for the grasp manipulator?)?

Any help, ideas and comments, are highly appreciated! If you want to have a look at our robot descriptions, please check out our katana_driver repository.

Greetings,
Henning
Reply | Threaded
Open this post in threaded view
|

Re: IK Performance & IK vs. Grasp Manipulator Directions

Rosen Diankov
Administrator
hi henning,

these are excellent questions! i'm glad you took the time to make sure
the IK was working fine and at least it grasped something. Now we have
to figure out how to increase the success rate.

> Futhermore read read this: "The manipulator definition itself also supports
> specifying a ‘palm direction’, which the grasper planner now uses."

Where did you read this? Is it part of the openrave documentation? It
is an old comment and we should change it.

Actually, you can specify multiple manipulator directions for grasping
using the "manipulatordirection" parameters in the grasping plugin. If
none is specified, then the Manipulator.GetDirection() is used.

So what you should be doing is:

Use the manipulator with direction [1,0,0] since that is what the ik
works for. Specify [0,0,1] as an extra manipulatordirection parameter.

> But I sample some poses randomly within a reachable part of the workspace, i
> only end up with a *success rate of ~2%*.
> And taking one of the successful poses and modifing it slightly about 1-2mm
> usually results in not finding a solution anymore.

Of course, and this is expected. The katana end effector spans a 5D
manifold within a 6D space. even with a reasonable discretization, it
spans less than 0.1% of the 6D space.

what you should look into more deeply is why the grasps you think are
achieve are not getting chosen by the grasp planner. Perhaps they are
getting into collision somewhere that can be fixed with the grippers
more open? Or perhaps you need to set more standoffs?

When debugging, you can set openrave to Verbose mode to see what is
getting in collision.

rosen,

2011/10/21 HenningD <[hidden email]>:

> Hi everybody!
>
> After I had
> http://openrave-users-list.185357.n3.nabble.com/ROS-GraspPlanning-Service-fails-on-Katana-td3402991.html
> some problems  to get the 5D GraspPlanning working with ROS for our Katana,
> but I finally managed to get it going!
>
> A worked my way through the 5D Grasping Example and the
> graspplanning_openrave.py and with some minor changes in the latter file i
> can now compute grasps for our Katana.
>
> But I stumbled upon several thinks that irritated me.
>
> 1) The IK performance is quite poor:
>
> I made some tests and out of about 2500 attempted Grasps usually ~25 are
> considered stable. But if any, only very few (ususally 1, max.3) out of
> those acutally come along with an IK solution. Which seems not enough for
> me, or is this quite okay?
>
> I visualized all Grasps and had a closer look and there are at least some
> more that should be easily reachable.
>
> So I went back to test the IK alone and made a performance test again, and
> the results looks quite good:
>
> /rosrun openrave openrave.py --database inversekinematics
> --robot=robots/katana_450_6m90a.robot.xml --iktype=translationdirection5d
> --manipname=arm --usecached --iktests=1000/
>
> gives:
>
> /openravepy._openravepy_0_4.databases.inversekinematics: *success rate:
> 0.880000*, wrong solutions: 0.000000, no solutions: 0.120000, missing
> solution: 0.067000/
>
> But I sample some poses randomly within a reachable part of the workspace, i
> only end up with a *success rate of ~2%*.
> And taking one of the successful poses and modifing it slightly about 1-2mm
> usually results in not finding a solution anymore.
>
> We thought about randomly pertubate our intended poses until we find an
> approximate solution, but I guess that's not the intended way. ;)
>
> Any ideas what could go wrong here? Or is this quite normal? Should it
> helpful to change the precision parameter while compiling the fastik code?
> I tried different setups there but that doesn't seem to make the ik
> computation more robust. The results are nearly equivalent.
>
> Could this be due to the fact that we do not specify the IK Solver fully
> within our robot description?
>
> As we use auto-generated collada files from our URDF descriptions, we don't
> want to modify the collada files by hand, but use an robot.xml file to load
> the .dae file with some additional information. This is how the file
> currently looks like:
>
> /<robot name="katana_450_6m90a" file="katana_450_6m90a.zae">
>  <manipulator name="arm">
>    <base>katana_base_link</base>
>    <effector>katana_gripper_tool_frame</effector>
>    <joints>katana_l_finger_joint katana_r_finger_joint</joints>
>    <closingdirection>-1 -1</closingdirection>
>    <direction>1 0 0</direction>
>    <translation>0 0 -0.03</translation>
>  </manipulator>
> </robot>/
>
> but the equivalent part from the neuronics-katana.dae file looks like this:
>
> /<extra name="arm" type="manipulator">
>        <technique profile="OpenRAVE">
>                <frame_origin link="kmodel1/link0"/>
>                <frame_tip link="kmodel1/link6">
>                        <translate>0 0.09 0</translate>
>                </frame_tip>
>                <gripper_joint joint="kmodel1/joint6">
>                        <closing_direction axis="./axis0">
>                                <float>-1.000000</float>
>                        </closing_direction>
>                </gripper_joint>
>                <iksolver type="Translation3D">
>                    <free_joint joint="kmodel1/joint3"/>
>                    <free_joint joint="kmodel1/joint4"/>
>                </iksolver>
>                <iksolver type="TranslationDirection5D">
>                        <interface_type>
>                                <technique profile="OpenRAVE">
>                                  <interface>ikfast_katana5d</interface>
>                                  <plugin>ikfastsolvers</plugin>
>                             </technique>
>                       </interface_type>
>               </iksolver>
>      </technique>
> </extra>/
>
> Is our description missing something?
>
> 2) IK Direction != Grasp Direction:
>
> Before adapting the orrosplanning/graspplanning_openrave.py file, I played
> around with the GraspPlanning Exercises
> http://openrave.org/en/main/openravepy/examples.graspplanning.html#neuronics-katana
> [2]  and while running:
>
>        /openrave.py --database grasping --robot=robots/katana_450_6m90a.robot.xml
> --manipulatordirection="0 1 0" --target=thinbox.kinbody.xml/
>
> with different manipulator directions, I discovered that [0 0 1] works best,
> which is reasonable because our gripper tool frame's z-axis points forward
> between the fingers.
>
> But the direction we use to plan the IK is different, namely: [1,0,0].
> A comparison with the neuronics-katana.zae model showed me, there are 2
> types of manipulators with different directions specified as well. So I
> guess this right. But I'm still wondering why this is?
>
> Futhermore read read this: "The manipulator definition itself also supports
> specifying a ‘palm direction’, which the grasper planner now uses."
>
> Is this necessary, has what are the advantages? How can I specifiy the palm
> direction (or is this the manipulator direction for the grasp manipulator?)?
>
> Any help, ideas and comments, are highly appreciated! If you want to have a
> look at our robot descriptions, please check out our
> http://www.ros.org/wiki/katana_driver katana_driver  repository.
>
> Greetings,
> Henning
>
>
> --
> View this message in context: http://openrave-users-list.185357.n3.nabble.com/IK-Performance-IK-vs-Grasp-Manipulator-Directions-tp3440764p3440764.html
> Sent from the OpenRAVE Users List mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users