# Solving inverse kinematics for special configuration (IKFast)

I'm trying to solve the inverse kinematics problem for a custom made robot arm. The robot arm has a special design with the following 5 DoF in serial configuration:

• x-axis prismatic joint
• y-axis prismatic joint
• z-axis prismatic joint

Therefore, I can not reach every configuration in space, namely I'm limited in one of the end-effector angles. For better understanding of the model, I added the URDF at the end.

I was trying to use IKFast to generate an inverse kinematics .cpp file. But when using IK Type "Transform6D" I get an error:

CannotSolveError: need 6 joints


I must admit that it's not totally clear for me what this IK Types mean. I know how to calculate kinematics and inverse kinematics by hand and I can not imagine why this IK Type should matter.

Even trying "TranslationDirection5D" did results in:

CannotSolveError: raghavan roth equations too complex


So I'm wondering if IKFast can solve my problem or how I can do it. I just need the inverse kinematics calculations as "stand alone" (for simplicity) which I will then use in my ROS node. I was following this tutorial:

http://wiki.ros.org/Industrial/Tutori...

URDF file (Link 7 is just a tool frame with fixed Joint 6):

<robot name="or_robot">

<joint name="joint1" type="prismatic">
<origin xyz="0 0 0.2" rpy="0 0 0" />
<axis xyz="0 1 0" />
<limit effort="1000.0" lower="0.0" upper="0.05" velocity="0.5"/>
</joint>

<joint name="joint2" type="prismatic">
<origin xyz="0 0 0" rpy="0 0 0" />
<axis xyz="1 0 0" />
<limit effort="1000.0" lower="0.0" upper="0.05" velocity="0.5"/>
</joint>

<joint name="joint3" type="revolute">
<origin xyz="0 0 0" rpy="0 0 0" />
<axis xyz="0 0 1" />
<limit effort="1000.0" lower="-0.4" upper="1.57" velocity="0.5"/>
</joint>

<joint name="joint4" type="revolute">
<origin xyz="0.1 0 0" rpy="0 0.2618 0" />
<axis xyz="0 1 0" />
<limit effort="1000.0" lower="0.0" upper="0.785" velocity="0.5"/>
</joint>

<joint name="joint5" type="prismatic">
<origin xyz="0 0 -0.05" rpy="0 0 0" />
<axis xyz="0 0 -1" />
<limit effort="1000.0" lower="0.0" upper="0.048" velocity="0.5"/>
</joint>

<joint name="joint6" type="fixed">
<origin xyz="0 0 -0.02" rpy="0 0 0" />
</joint>

</robot>


Edit: changed units

edit retag close merge delete

Just a note: you have a robot spanning a volume of 50 by 50 by 48 metres? And the links are 20, 50, 100 and 200 metres apart?

I know how to calculate kinematics and inverse kinematics by hand and I can not imagine why this IK Type should matter.

So can you tell me then how to solve for an arbitrary 6D pose with a 5dof robot?

1

I just need [..]

Be careful with these types of 'just' sentences. They are typically not as simple as they may seem.

Ups, I was looking for units and couldn't find anything. So I was expecting mm. But this shouldn't be the problem. Will change it.

I was not expecting it to work for arbitrary 6D poses. But you are right. It can not work with a closed form solution which is generated by IKFast.

1

I was looking for units and couldn't find anything.

Everything in ROS is SI units (REP-103). That includes URDF.

It can not work with a closed form solution which is generated by IKFast.

if you mean: ikfast can't work for your robot in general, then I would not necessarily agree with that. I've generated IKFast plugins for 5dof robots in the past.

I mean it can't work with the "transform6D" mode because of closed form. I also tried to add an additional revolute link for the 6D solution. But I always get "too complex" errors.

Then can you tell me which parameters to alter or how to do it? I can just choose the IK Type.

Sort by » oldest newest most voted

Not sure if this counts as an answer, but I solved my issue by using Orocos KDL library instead of IKFast. IKFast couldn't find a closed form solution. So I was expecting a numerical solver to work better. And KDL obviously did the job.

more

1

If a numerical solution is good enough, I'd advise you to look at trac_ik. It's much more performant and has a much higher solve rate than KDL.

Thanks, I will consider that for the final version. But at the moment KDL seems to be very fast for my application.

trac_ik is faster, always. And has a higher solve rate + solutions will be more accurate. Check the paper + website.