0
$\begingroup$

I'm a complete beginner with LabView and I have been practicing forward kinematics with the help of a tutorial I found. It's been a learning curve but I've managed to understand a few things.

However, I have not been able to implement an inverse kinematics vi.

I've been trying to replicate this tutorial but I have been unsuccessful so far.

I'm working with a SCARA serial arm. The image below shows my work-in-progress attempt.

enter image description here

When I run my vi I receive the following error:

Error -310040 occured at NI_Kinematics.lvlib: Inverse Kinematics (Point).vi->Inverse Kinematics Attempt-1.vi

LabVIEW Robotics: (Hex 0xFFFB44E8) LabVIEW cannot converge to a solution in the number of steps you specified. Make sure that the serial arm can achieve the transform you desire.

My objective is to set the X, Y and Z input fields to the values representing a point in space and move the endeffector to that point.

I would really appreciate some guidance?

| improve this question | | | | |
$\endgroup$
  • $\begingroup$ What exactly is your issue? You can add a screenshot if you think it will help $\endgroup$ – Agent56289 Apr 4 '19 at 21:57
  • $\begingroup$ The issue is I am unable to successfully create an inverse kinematics implementation in LabView duplicating the same setup as in the linked video $\endgroup$ – sisko Apr 4 '19 at 22:13
1
$\begingroup$

There could be a few generic reasons.

  • Ensure that the desired Cartesian pose is actually achievable by the robot, i.e the position is within the workspace.
  • As the error mentions about max_steps parameter, I believe they are using random restarts for something like a Jacobian pseudoinverse based solver; so indeed try giving more steps because intricate Cartesian poses might need more than normal trials.
  • Finally, confirm if it is not a singularity which could trouble the computations.

I found the information on IK module for LabView on their webpage Inverse Kinematics VI

| improve this answer | | | | |
$\endgroup$
  • $\begingroup$ Thank you for your feedback. I have been able to confirm the IK used the default number of maxsteps of 100. In line with your suggestion, I increase that to 1000 and then to a million but it made no difference. $\endgroup$ – sisko Apr 8 '19 at 9:29
  • $\begingroup$ As for confirming it is not in a singularity AND confirming the pose is achievable, can you please offer suggestions on how to accomplish both? The only way I know how is to add the 3D picture graph in my front panel which would have allowed me to see how the robot is positioned BUT the error prevents me from doing so. $\endgroup$ – sisko Apr 8 '19 at 9:33
1
$\begingroup$

It's telling you it can't reach the solution in the number of steps you've given it. As Akshay Kumar stated, you need to be sure that the robot arm can actually reach the desired target. I've used LabVIEW, but it's been a long time - I don't know what your parameters are doing or what you have set on the front panel, but it looks like you're passing a lot of zeros to the arm initialization. What are the arm link lengths that you're providing? If you've told it that every link is length zero, and you're commanding it to reach <1, 0, 0>, then it's going to fail because no combination of zero-length links will ever reach a position of 1.

You asked how to determine if the pose is achievable. The real answer is complex, but you can do a quick check by finding the distance to the target position from the base of the arm (target = t, base = b) $\sqrt{(t_x-b_x)^2 + (t_y-b_y)^2 + (t_z-b_z)^2}$ and comparing that to the sum of the link lengths. If your target position's distance is greater than the sum of your link lengths then there's absolutely no way you can reach it.

It is possible to have a point inside your "sphere of maximum reach" that is still not reachable, because of joint constraints or link lengths, but that is a much harder problem to solve (generally no analytic solution, only iterative approaches).

If you're trying what should be a simple test case, then I think you may have initialized your arm incorrectly, or your length and target units are in disagreement.

| improve this answer | | | | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.