Unexpected -310040 error (could not converge) in LabVIEW for Robotics: Inverse Kinematics VI

[RIObotics]

Hi,

I downloaded the robot kinematics example Vis off of this page from devzone, and they work fine.

Basics of Robot Kinematics

http://zone.ni.com/devzone/cda/tut/p/id/10687

“This is great!” I thought to myself.  I really wanted to play with the IK Vis.  So I went about defining my own serial arm, using my own lengths and configurations for each joint.

First, I ripped out all the dynamic parameters in Create Puma 560.vi.  Didn’t think I needed those just for the IK calculations.  I went about defining an arm with only one link with a length of 1 and a twist angle of 0.  I set my desired position to (1,0,0) and lo and behold, the VI worked with no error.  I then set position to (0,1,0), but this time the -310040 error occurred (could not converge).  Why Is this happening?  Am I missing something in the arm definition?

I then went on to doing some more trial and error, I added a second link, again with a length of 1 and a twist angle of 0. I tried (2,0,0), and it worked.  Even (1,1,0) worked, to my surprise, the two links would form a 90 deg angle.  But still, (-2,0,0) didn’t work.

Another question I have is, can the Robotic Arm Vis account for singular points that may occur (positions with no solutions or infinite solutions?)  An initial sweep of the arm workspace would be nice.  Also, for positions that have more than one solution, is it possible to input constraints on the joint angles so that only one solution is possible?    

Thanks for your response.

John Wu

Project Manager

Riobotics Technology Consulting

[S_Kamath]

Hi John,
The dynamic parameters in Create Puma 560 are only required if running one of the Dynamics VIs.

Your problems can be attributed to a bug (reported as CAR 236687) in the visualization which incorrectly treats prismatic joints as revolute joints. So the visualization you were seeing was quite misleading, but numerically the results were correct.

Your first joint was prismatic and therefore it could achieve any position (0,0,z) for all positive z, the subsequent link of length 1 means that it can achieve (1,0,z), therefore IK could not converge to a solution for (0,1,0).

When you added the second link I think it was specified as having a revolute joint and therefore it could rotate about any pivot (1,0,z) and then have a subsequent link of length 1 in the direction of the rotated x axis. In your case rotate from (2,0,0) to (1,1,0) about the point (1,0,z)

I personally found it helpful when working with underactuated arms to play with the visualization of the forward kinematics first to get an clearer idea of the achievable workspace of the arm.

If the visualization issue is seriously affecting you please contact NI support and mention this forum thread.

As for how it all works the IK solver works by starting from the current joint position provided iteratively stepping in the direction of the jacobian. This is quite fast if the new position is close to the one provided but will fail to converge if

i) The desired position is not achievable.

ii) There is a sufficiently large local maxima or unachievable area in the convergence path between the current position and the new position. (We are interested in examples of these to improve our algorithms)

As a result inverse kinematics works best when it is solving over a sucession of relatively close positions created by your control code. Like any solver the algorithm has considerable jitter but can at least be deterministic by selecting an appropriately small maximum number of steps.

[RIObotics]

Hi,

Thanks for your reply.  Fortunately I'm not dealing with prismatic joints in my application, so the visualization bug that you mentioned won't be a big issue to me.  I'm only dealing with revolute joints for now.  Your explanation for the prismatic joint was right on the spot, however I found a couple more quirks with revolute joints.

Consider the case of only one revolute joint, length=1, twist angle=0.  I would expect that this single joint allows the arm to revolve around the base in the XY plane.  So I plug in (1,0,0), I get a solution.  I plug in (0,1,0), no solution (see pic).  Same with (-1,0,0) and (0,-1,0), no solution.  So I fiddled around and added one more revolute joint of length=0 to the series.  Now the VI gives solution to all of the 4 positions I tried earlier.

"Ok" I thought to my myself, maybe I just need to tag a joint of length=0 to the end of my series, everything should work out.  Not so.  I tried having 3 revolute joints in total, 2 of them with length=1, the last one length=0, tried some different positions but most positions failed to converge.

My goal is simple ... to define a serial arm with 3 revolute joints, all rotating in the same plane, and try out the LabVIEW IK algorithms.  For simplicity's sake, all 3 links lengths=1.  Do you think you can provide an example?

-John

[S_Kamath]

Your intention seems to be to ignore the angle of the end effector, but inverse kinematics by default tries to converge on all 6 dof. In your case since you are limited to one plane you have 2 displacement and 2 angular degrees of freedom. Since you are not explicitly setting the angles in the transform they are defaulting to 0. Therefore with only 3 joints Inverse Kinematics is frequently unable to achieve the desired position. When you add the 4th joint with 0 length you now have the ability to converge on all 4 dof. Your options are therefore to specify transforms where the position and orientation are achievable or to set the mask to ignore the dof that you wish to ignore. In this case your mask should be [1,1,1,0,0,0] because you wish to converge on x,y,z, but not the angles or even [1,1,0,0,0,0] if you decide that you don't care about the z value.