Page 1 of 1

Is there a Inverse Kinematics solver for end-effectors in the C++ API?

Posted: Thu Sep 03, 2020 7:29 am
by docvi
Hi,

I have a question regarding inverse kinematics. I know and have been using the C++ API for performing traditional inverse kinematics using markers placed on (almost) all segments. But now I would like to try to solve a motion where only the end-effectors segment (hands, feet and head) are known. This process or end-effector inverse kinematics is commonly used in robotics for example.
Is there any solver that can perform end-effector inverse kinematics in the C++ API. If yes, can you provide example or ressources?

Thank you

Vincent

Re: Is there a Inverse Kinematics solver for end-effectors in the C++ API?

Posted: Fri Sep 04, 2020 12:31 am
by mitkof6
Hi Vincent,

Do you mean that you want to specify the end effector position and orientation and perform the inverse kinematics? This is possible with OpenSim/Simbody to track only specific goals (e.g., foot, head, etc.). Also, there is a PR that tried to expose tracking of marker positions and orientation in real-time.

https://github.com/opensim-org/opensim- ... 2855/files

Also you can check the OpenSense tutorial for orientation tracking:

https://simtk-confluence.stanford.edu/d ... h+IMU+Data

Re: Is there a Inverse Kinematics solver for end-effectors in the C++ API?

Posted: Fri Sep 04, 2020 6:56 am
by docvi
Hi Dimitar,

Thank you for your reply.
We looked at the PR and are waiting to be completed (if it happens)

You are right about end-effector IK.
We want to "specify the end effector position and orientation and perform the inverse kinematics".
We are doing it already by using a workaround where we create markers from our IMUs/Rigid bodies data and use the InverseKinematicsSolver to solve the motion and get our coordinate values.
We get a solution but not a pleasing one. The arm adduction/abuction is not natural and we do not know how to solve that.
This is why I asked for the existence of another type of solver.
This is why I also created another post where I was asking if we could add some weights to the coordinate so that the use of the arm adduction/abduction coordinate is down-prioritised when solving the motion: see viewtopicPhpbb.php?f=91&t=12419&p=0&sta ... ac4d941ad2

Thanks anyway

Vincent