0
$\begingroup$

I am working with the openMANIPULATOR-X robotic arm and I am trying to implement inverse kinematics for it. I have found this article that talks about kinematic modelling:

https://pdfs.semanticscholar.org/56a0/9731772199fe77bcb0dbff3a69f1c623e0c7.pdf

But when I implemented it in matlab, theta_3 had a complex number indicating that it is not possible for the robotic arm which does not make sense. I understand how everything is derived in the paper but it seems I am missing something. Could anyone help me?

Improve this question
$\endgroup$
3
  • $\begingroup$ when I implemented it in matlab ... did you get an error? ... please edit any error listing into the question ... do not use comments $\endgroup$
    – jsotola
    Commented Feb 21, 2022 at 5:35
  • 1
    $\begingroup$ Hi @Midnight 2 as jsotola mentioned please edit your question to provide enough information to reproduce your problem including your minimal self contained example of your error. We can only guess if you're missing something without seeing your implementation. $\endgroup$
    – Tully ♦
    Commented Feb 23, 2022 at 18:22
  • $\begingroup$ The algorithm in the paper describes how to model how the joint angles vary over time to support the desired end effector trajectory. $\theta_3$ is a time series. Did you plot how it varies over time to get some insight into what might be happenning? $\endgroup$
    – guero64
    Commented Mar 27, 2022 at 12:36

1 Answer 1

Reset to default
1
$\begingroup$

There are smart ways of approaching this problem, and there are silly ways of approaching this problem.

One option of getting around Matlab imaginary joint values is to implement the code in python with regular floating point values and then import the package into matlab. That way, Python will throw errors when complex joint values are returned (rather than propagate complex values through the solver).

A more correct solution to your problem would be to implement datatype checking all throughout the solver. Each step of the Ik solver should check if you have imaginary values. Then, once you have found the imaginary value, you can figure out where the imaginary values are being generated. The most common problem in my experience comes from the use of inverse trig functions being given values outside of their domain. When I get imaginary values, I am passing a value of magnitude great than 1 into an inverse trigonometric functions like acos(). Matlab handles this problem by returning complex values, and that does not help in debugging. That is why I recommend moving to python (or better yet, C++). You might also be running into division by 0, but the most likely issue is that you are calling trig and inverse trig functions with improper inputs.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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