Inverse Kinematics

Inverse kinematics is the problem of calculating the joint angles, given the desired position of the end-effector. Typically the 'hand' of the robot would be treated as an end-effector, while the joint angles of the elbow, shoulder, etc. would be examples of the types of values calculated through inverse kinematics. I've seen numerous approaches to inverse kinematics that don't take advantage of the well developed game physics engines available. These game physics engines are often free, open source code. The more popular ones will be well maintained as they see a fair bit of use by game developers(every kid and college student who wants to be an indie game developer as well as the pro's). They can be easily modified to use doubles instead of floats if one needs more accuracy for the sake of robotics and high accuracy measurements. They contain all of the joint constraints one needs, and high speed constraint solvers to do all of the heavy lifting. They will work with many degrees of freedom. Consider a typical 'ragdoll', as a game developer would use the term ragdoll(You might want to Google this term and watch some videos). 'Pin' the body of the ragdoll, by declaring it to be static(immobile). Clearly when one grabs an end-effector with a picking tool, joint positions are calculated. Physics game engines typically allow you to define 'rigidbody' objects, and send them to the main 'world' object. You can also define 'joint' objects and send these to the 'world' objects as well. These 'joint' objects will also have a reference to two rigid bodies that they are attached to. Here's some pseudo code to outline the basic process I am describing. This algorithm will work with characters instead of robots as well.

Init: Create a new physics world instance, call it ikWorld. If you were already simulating physics then create ikWorld as an additional instance.
Load the new world with definitions of your robot's rigid-bodies and joints.
Remember to set all of the required properties of each rigid body and joint, for the current(start) position.
You can just load one limb or body part at a time if that is appropriate for speed.
Set the robot's base or body as 'static', or immobile. This 'base' will be a rigid-body in the physics engine.

Nest 1: Set the end-effector position to the target position(and rotation), this end-effector will be a rigid-body as well.
Turn on the ikWorld physics engine.
Wait until the new joint positions stabilize(this should only take a fraction of a second).
Stop the ikWorld physics engine.
Retrieve the position information from the rigid-bodies and joints.

The method above may not be as stable as the method below. Because you are moving the end-effector in such an abrupt fashion, the physics engine may fail, or you may get joint settings that are not appropriate given the initial joint settings. It's fast where it works if you want to test it though. A more robust algorithm will perform the following:

Algorithm 1:
Run Init.
Interpolate intermediate positions between the initial end-effector position and the final target end-effector position.
Repeat Nest1, for each intermediate end-effector position. Store the results from each intermediate position.
This will result in a sequence of intermediate target orientations of the rigid bodies and joints as you gather the results.

I use the c# jitter physics engine. C++ coders seem to like bullet physics. I'll post some further info here soon.

The gaming industry pulls in $78 billion in revenue. Take advantage of the benefits of scale.



Do you need custom 3d software written? Hire Me.