IkFast solver, MoveIt not working, model too complex

[Daniel Mezei]

Hello guys,

My main goal is to create a custom IKFast plugin for a 7DOF arm like this one.

Following this tutorial  I have managed to generate an ikfast solver for my arm and then also a custom MoveIt! plugin to test it on my arm.

However, I suspect that there is something wrong since the arm is not working properly with the IkFast solver, because when using MoveIt! from Rviz and trying to move the marker the arm is not moving, but when a random position is selected then the arm is able to get to that position.

I have searched for solutions on this and I have found possible solutions: this ,this, where it was suggested that the arm is to complex, probably there are some issues with the generated collada file.

Have you found similar problems when creating an IKFast MoveIt! plugin ?
How can the the complexity of the arm be reduced ?


Thank you,
Dani

[Gert Kanter]

Hi,

I tried to get an IKFast plugin working for Cyton Gamma a while ago, but it never worked properly. IKFast did manage to generate the analytical IK solution after some persuasion, but the solver couldn't find solutions (it did find degenerate solutions, i.e., in cases where the arm was fully extended). In the end I opted to use the built-in KDL IK plugin for MoveIt. If you do manage to get it to work, please let us know!

Best regards,

Gert

[G.A. vd. Hoorn - 3ME]

On 22-3-2016 13:30, Gert Kanter wrote:
> Hi,
>
> I tried to get an IKFast plugin working for Cyton Gamma a while ago, but it
> never worked properly. IKFast did manage to generate the analytical IK
> solution after some persuasion, but the solver couldn't find solutions (it
> did find degenerate solutions, i.e., in cases where the arm was fully
> extended). In the end I opted to use the built-in KDL IK plugin for MoveIt.
> If you do manage to get it to work, please let us know!

This is a bit I-heard-somewhere-that, but the IKFast plugin generation
script appears to have difficulty generating plugins for configurations
where joints have translations in more than a single dimension. It loves
simple, serial, 6 / 7 dof chains, such as industrial arms, especially if
they have spherical wrists (plugin generation times of 30 seconds aren't
uncommon).

For chains where this is not the case, KDL, or its more advanced
successor (and most of the times: drop-in replacement), trac-ik [1],
tends to work well.


Gijs

[1]
http://www.ros.org/news/2015/11/introducing-a-better-inverse-kinematics-package.html

> esmaspäev, 21. märts 2016 13:10.11 UTC+2 kirjutas Daniel Mezei:
>>
>> Hello guys,
>>
>> My main goal is to create a custom IKFast plugin for a 7DOF arm like this

>> one<http://wiki.ros.org/Robots/Cyton-Gamma>.
>>
>> Following this tutorial
>> <http://docs.ros.org/hydro/api/moveit_ikfast/html/doc/ikfast_tutorial.html>

>> I have managed to generate an ikfast solver for my arm and then also a
>> custom MoveIt! plugin to test it on my arm.
>>
>> However, I suspect that there is something wrong since the arm is not
>> working properly with the IkFast solver, because when using MoveIt! from
>> Rviz and trying to move the marker the arm is not moving, but when a random
>> position is selected then the arm is able to get to that position.
>>
>> I have searched for solutions on this and I have found possible solutions:
>> this

>> <http://answers.ros.org/question/207100/moveit-ikfast-plugin-working-with-demolaunch-not-working-with-move_group_interface/>
>> ,this
>> <http://openrave-users-list.185357.n3.nabble.com/ik-autogenerate-failing-for-the-6-DoF-Mico-arm-td4026861.html>,

[Gert Kanter]

Definitely +1 on trying TRAC-IK out instead, my experience was before they had released it (way back in Hydro, actually). Their results look very promising!

[Patrick Beeson]

I've seen lots of issues with IKFast in the past: 1) Non-convergence for >6 DOF arms, 2) IK "solutions" that when run back though FK are too far from the goal to be considered quality solutions, 3) similar joint solutions outside of limits.

Please try the TRAC-IK plugin if KDL isn't working.  I'm about to push (in the next few weeks as I document and clean up) a HUGE update to TRAC-IK that pushes self-collisions down into IK (if desired), so that when you get an IK answer, you know it is not in collision with any other part of the robot.  It only adds a slight 3x increase over KDL (still milliseconds per solve), but with the high solve rates of TRAC-IK and low-level collision detection!

If that robot has a reasonably conforming URDF, I can add it to the test suite results listed on the TRAC-IK Bitbucket README.