Software > Software

Inverse Kinematics Help

<< < (2/2)

The thing with IK is that a two-segment IK has a closed form solution (well, two solutions, as it's a quadratic equation.) Three segments can still be reduced to two, if you use the first axis to select a solution plane and then sove the two-segment case. This is what I do for my quadroped walker, for example -- the hip points the legs in the right direction; the two knees position the tip of the foot in the right place.

For more than three segments, or for the case of three segments that are all co-planar, you no longer have a nice quadratic equation that gives you the solution. There are generally infinitely many solutions, and the math is not closed-form anymore. There are two solutions used in general: Iterative solutions, and overconstrained solutions.

The idea behind iterative solutions is that, if you start out with a particular solution, and then move the goal a small way, then you can look for the smallest delta to the IK solution that solves for the new goal. This is popular in animation software, for example, where two characters may be holding hands, and we want the contact point to be roughly between the center of gravity of the two characters. The draw-back is that you're not guaranteed anything in particular about the solution, because what it is depends on how you got there.

The idea behind over-constraining is to add constraints to the solution that aren't necessarily encoded in the physics, and thus reduce it to a set of two-segment problems you can solve in order. For example, for a three-segment leg, getting the toe-top at a particular point could be done where the last segments joint is positioned anywhere on a circle around the desired end point. If you define that the last segment joint should always be straight up from the contact point, for example, the circle collapses to a point, and you can solve the first two segments for that point, and then solve the last segment trivially to reach the goal. (The "walker" solution I suggest above is actually a special case of this method.)

So, if you're not comfortable with the math just yet, now's probably a good time to pull up the textbooks, or go to or to brush up on it!

Thanks for the response, it answered a lot of my questions. I have been reading up on IK and think I have found a paper publish by MIT that seems to have all the information necessary to begin coding it into the algorithms to control the arm. I will most definitely read about the two solutions you mentioned and work on my math skills from some of those sites you mentioned, I haven't obtained the math skills yet  :'(  (in Algebra 2 right now). Tell me what you think about the paper, here is the link ↓


The book chapter/paper is an excellent find.  I saved a copy for my own reference.  It describes the same approach I've used for IK stuff, and is thus just what you need.


--- Quote from: idee17 on January 23, 2013, 11:00:57 PM ---

--- End quote ---

This is not actually a "paper" (as that typically means a peer-reviewed journal publication,) it is lecture notes / course materials for a class at MIT that teaches these things.
That being said, that's exactly what you want -- if you can figure this out, you'll be in good shape!
The more I get into robots, the more I find that the math I learned from computer graphics, animation, and physics simulation is totally applicable, btw. That shows all those who said computer games would amount to nothing ;-)

Oh, never really knew the definition of a "paper" thanks for the advice =)  I'll start getting it coded for the robot arm. When ever i get it finish i'll be sure to post the code that i ended up with, for others to use...

ps: I going to keep playing and making computer games  :D

~Thanks Idan


[0] Message Index

[*] Previous page

Go to full version