# Generating IK solution for use in MoveIT for 5 DOF arm

I am working on a custom 5 DOF arm(image at the bottom). I have generated the URDF, the MoveIt configs etc for it.

I want to have the basic IK, planning and collision detection features of MoveIt. Before programming my application, I tried running the simple planning in RViz, using the interactive marker etc. Now, since it is a 5 dof system, I had to enable "Allow Approximate IK solutions", for it to let me use the interactive markers. It was using OMPL by default. I tried planning for some random-valid goal states. The problem is that the planning success rate was very very low. 4 out of 5 times the planning failed. I also tried changing the planners from the dropdowns, but none of them were consistent in planning succesfully, all of them were failing quite frequently.

After looking up this problem here on Ros-Answers and many other places, we found that IKFast would be what we should use, as it works reliably for 5 dof systems.

After installing openrave and ikfast via source, we ran the commands to generate a IKfast cpp file(using this tutorial) for our robot model. We tried the TranslationDirection5D ik type. Now here we are getting a tuple index out of range error which is something that others have faced before and have not been able to solve. See this and this. Basically, we've now hit a wall trying to get the IK on my 5 dof robot to work properly. Openrave is not even able to generate an Ikfast cpp.

Here'ss the exact error i get when i try to generate an ikfast cpp,

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 9521, in <module>
File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 2281, in generateIkSolver
chaintree = solvefn(self, LinksRaw, jointvars, isolvejointvars)
File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 2796, in solveFullIK_TranslationDirection5D
coupledsolutions,usedvars = solvemethod(rawpolyeqs2[index],newsolvejointvars,endbranchtree=[AST.SolverSequence([endbranchtree2])], AllEquationsExtra=AllEquations)
File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 5226, in solveLiWoernleHiller
hassinglevariable |= any([all([__builtin__.sum(monom)==monom[i] for monom in newpeq.monoms()]) for i in range(3)])
IndexError: tuple index out of range


Is there a recommended way to get IKfast to generate a cpp or maybe even get the normal KDL to work reliably for my 5 dof system? I would really appreciate any kind of help to get this to work, thanks

Here's the picture of the bot from RViz

edit retag close merge delete

Welcome to the 5dof club, I also had lots of problems. Note that OpenRave is very picky about sympy version. The combination OpenRave git b89980e with sympy 0.7.1 worked for me.

( 2017-01-05 02:51:49 -0500 )edit

I installed Sympy 0.7.1, but i still get the same error with openrave. I've added the exact error in the above question...

( 2017-01-05 03:17:35 -0500 )edit

Have you tried a known working robot, e.g. youbot?

( 2017-01-05 16:02:13 -0500 )edit

Sort by » oldest newest most voted

We have been trying to debug this issue since the past 2 days. With no clear reason for this problem, we decided to try solving the IK of robot of the same configuration with a simple URDF file. So we wrote a urdf by hand, with the same joint and link config as our robot. The URDF we used earlier was generated from our original CAD model using the Solidworks URDF Converter plugin.

With this simple URDF, we did the same process as mentioned above. From this new MoveIt config, the plans were working significantly better. With the earlier urdf, hardly 1 out of 10 plans would work and even simple plans where only 1 motor had to move were failing. But with this new URDF model, many plans are working realli good! Even with the basic KDL solver with OMPL. And this is the same 5 dof configuration we had before. Our guess is that the solidworks urdf exporter plugin, which is severely dated, might be causing the issues in the planning. But we are still figuring out the actual, fundamental cause for this issue.

As far as solving the above problem is concerned, building a URDF by hand solves this problem for us. Even the IKfast library generates an analytical cpp solution.

more

Have you looked at trac_ik?

I realize that this is not a direct answer to your question, but it's another IK option of which you may not be aware.

more