# What limitations does IKFast have?

I am currently running into low success rate issues with the IKFast plugin for the Kinova Mico.

Using the following test, I find IKFast fails to find solutions to roughly 1/5 of the valid poses in the space.

- Use moveit to find
**random valid joint positions**which are not in self collision - Use forward kinematics to compute the pose of the end effector
- Use IKFast to solve back for the
**random valid joint position**

Wikipedia and the MoveIt! documentation states: "IKFast can analytically solve the kinematics equations of any complex kinematics chain, and generate language-specific files (like C++) for later use. The end result is extremely stable solutions that can run as fast as 5 microseconds on recent processors"

I have always taken this for granted and have believed that IKFast uses some god like mathematics to compute the inverse kinematics for arbitrary 6DOF arms in closed form, after digging into Rosen Diankov's (Creator of IKFast) thesis it seems this might not be the case.

On page 78 He mentions "we will show that by sacrificing a little generality, the presented analysis can produce much more stable closed-form solutions to most of the common robot arms available today."

Dr. Diankov also mentions on page 91 (what I believe to be) his method for solving 6DOF IK:

"There are two classes of kinematic chains that can be solved using the above analyses as sub- modules by assuming the translation and rotation components are separable. Separability allows much simpler solutions where the most complex polynomials have to be solved are quadratic. The first type is when the last 3 joint axes intersect at a common point"

Under the assumption that the IKFast method requires the translation and orientation are seperable:
**What conditions have to be met in order for the kinematic chains to be separable?**

Which brings me back to my original question. What limitations does IKFast have? Does it require a certain class of robot which the Kinova Mico does not meet? If so that would explain why my IKFast solver is not working with a very high success rate for the Kinova Mico :)

For reference here is the issue that I have opened with Kinova here: https://github.com/Kinovarobotics/kin...

Not an expert either, but you seem to have quoted a very relevant piece of Rosen's thesis already:

You'd ..

.. have to check whether MICOs fall into that category. Note that the wrist axes need to intersect mathematically. Whether they are physically located near each other is not important.

Additionally: Rosen is most likely the authoratitive source for this kind of information. Have you already posted to either the issue tracker or the openrave mailing list?

You may be interested to know that IKFast (or really: OpenRAVE) includes testing functionality that you can use to see what the solve rate is for a particular plugin. See #q196753 and #q263925 for some information about that (

`--iktests`

in the command line shown there).