I have been wondering this for awhile. Has anyone applied IK to bipeds? Would the process be any different than for a hexapod or octapod, except possibly for a greater number of joints being handled?
8-Dale
I believe that it can be applied to bipeds as well. People in 3D animations for movies/tv and video games constantly applies this technique to keep biped motion looking fluid.
I suppose one would be able to apply this to bipeds as well, but must keep COG shifting in mind 
Same process just more calculations.
there are some good books out there that explain the equations you just need to right the software.
Hi Dale!
I didn’t see this thread until now.
IK for more than 3 DOF are much more demanding. One factor is that the number of solutions depends upon the number of joints and the allowable ranges of motion of the joints. Say for a completely general rotary-jointed manipulator with 6 DOF there are up to 16 solutions possible.
My math skills are limited but I’ve tried to read “Introduction to Robotics mechanics and control” by John J.Craig and “Theory of applied Robotics kinematics, dynamics and control” by Reza N.Jazar. Some parts are way over my head But you’ll find some useful information.
For the time I’m working with a SES based 4 DOF Quad, and my goal is to figure out a working IK solution for 4 DOF. Maybe a combination of FK for one joint and IK for the remaining 3 DOF. 
Good luck with your research in Biped IK’s.
It can be done, but as you increase the DOF, the inverse kinematics solution gets exponentially more complicated. 3DOF IK is actually pretty simple. Not so for 4+ DOF. So much so that last I checked, nobody has found a generalized closed-form solution the 6DOF problem.
And to complicate things more, you need to find a way to pick the correct solution (6DOF joints have, I believe, up to 16 possible solutions? Someone correct me if I’m wrong there). It’s not always obvious which solution is the one you want.
The 3DOF case is trivial by comparison - you can work it out on paper if you’re good with trigonometry. The correct solution is usually pretty obvious and the one most computer languages would pick by default.
For certain robot configurations, it’s possible to get practical solutions if you’re willing to dig into the math. There are many approaches, but none are all that clear or fun unless you’re really into math.
I’ve been working on this problem. I think I’ve got it pretty much worked out.
I’ll give you all a hint- you really have to understand what problem (or problems) you are solving before you can come up with a solution. I think the classic mistake here is to over-generalize the problem.
The math isn’t bad. You don’t need anything more than algebra, geometry and trig - i.e. 10th grade level math. Making the leap from 2 dimensions to 3 dimensions is probably the hardest part conceptually.
I’ve been developing my own IK algorithm as well for my hexapod. I have all the formulas solved for the angles, just need to code it. I’ve begun coding and programming my mathematic yesterday, with surprising results… But a few key points I’ve discovered along this journey:
-
Remember to correctly model your legs/appendages/limbs with general diagrams. You don’t want to assume any angle or lengths are this and that unless it’s a given… Whenever possible, try to solve for any arbitrary triangles, not just for right triangles (which are the easiest to solve).
-
Keep your variables and naming conventions simple. When you start having 6 or 9 angles and lengths to solve for, it starts getting confusing if it’s not obvious.
-
Remember that all movements in 3 space are vector math. Just remember which vector components are involved when looking at the 3-space limbs in 2 or 1-space.
-
Don’t forget, to make your bot “walk” it involves more then IK. IK does not and will not tell you that you that you need to shift your weight/cog to balance for bipeds. IK will not tell you that you need to alternate the tripod on a hexapod. IK will only tell you what angles each limb must be in order to move the tip to coordinate (x,y,z) from coordinate (a,b,c)
-
Remember that there are two different spaces with two different references. You must be able to command the bot in one space, but translate that down to the another space, which your apendages are in. I like to call these two global and local space. Global space is where you command the bot to move, the local space is where you command the appendages/legs/limbs in order to accomplish the move in Global. The reference point for these two are often not the same. For example, my “global” reference point for my phoenix would be at the midpoint between the two middle hip-horizontal servos, looking at top view, for my (x,y) for my (z) I would orient this reference point at the midpoint between the top deck and the lower deck if you look at it from the side. This reference point would be my (0,0,0) or my origin in my global space.
This vector in global space is what will dictate where I want the phoenix’s body to be.
Now, this vector must be translated into each of the six (six for hexapods, two for bipeds) “local” space. Each of these six local vectors would tell the limbs where they need to be in order to accomplish the move that the vector in the global space is dictating.
Not all six limbs are going to relatively travel in the same direction or in the same relative position. Doing so will not create any motion. Some limbs will have to be up, some will be moving forward, and etc…
Which leads me to 6):
-
It might be several sequence of local vectors in order to accomplish one global vector move…
-
Know your limits. Make sure you know your limitations of each limbs. I don’t know about your servos, but my Hitecs can only do 180 degrees at the most, and even then, I do not like to hit this limit cause it’s non sensical. Also, if the body is resting on the ground and the tips of the each feet is floating in the air, I know that the darn thing will not walk, so there’s a limit for the clearance of the bot, which is a function of the limit for the limbs’ angles and etc…
I hope keeping these things in mind, you will gain a more understanding of how IK plays a part in the scheme of things. I was stuck on the notion that one can create an all-knowing all-encompassing formula that will direct your bot to walk and move. This is not true. IK is a low-level mathematical function. How to make synchronize it and how to coordinate the movements of the limbs sits at a higher level then the IK-layer of code…
Nice write-up, Tom.
I’ll share more of my ideas in the future after I have applied them to real mechanical motion.
A couple more tips:
I suggest reading up on the Denavit-Hartenberg (DH) nomenclature: it’s a standard nomenclature for describing the geometry of robotic manipulators, and will make your life easier when the numbers begin swimming about. Plus, all the engineering literature uses it, so you should understand it if you’re going to read up on kinematics.
Matrix math is your friend. Transformations between body coordinates and leg coordinates & forward kinematics are stupid simple once you develop the proper transformation matricies. It’s also required knowledge if you want to read any of the engineering literature.
Inverse kinematics is really nothing more than algebra & trig. The trouble is that the equations get HUGE and complicated with multiple branches. The more you can hone in on the specific geometry you are working on, the less complicated it will be. Nail down those DH parameters! Minimize the number of variables. 3DOF IK is not that hard and can be solved by hand on a page or two of notebook paper without resorting to matrix math or numerical techniques. Know your basic trigonometric identities and how to solve triangles. Remember SAS, SSS, ASA from geometry class? You need that stuff!
Plan on generating an IK solution for each limb configuration you come up with. Overgeneralizing, as A-bot said, while theoretically appealing (you never have to do it again if can just figure out the super-general 6DOF case with variable DH parameters), is a recipe for death by complexity, or a Phd dissertation.
Finally, an example: My Ruby method that calculates the inverse kinematics for a 3DOF hexapod leg:
def inverse_kinematics(position)
x = position[0]
y = position[1]
z = position[2]
#calculation break down for simplicity
#lengths
e = Math.sqrt(x**2 + y**2) - self.coxa.a
f = Math.sqrt(e**2 + z**2)
#angles
u = Math.atan(z/e)
v = Math.acos( (self.femur.a**2 - self.tibia.a**2 + f**2) / (2 * self.femur.a * f) )
w = Math.acos( (self.femur.a**2 + self.tibia.a**2 - f**2) / (2 * self.femur.a * self.tibia.a) )
@coxa.theta = Math.atan(y/x)
@femur.theta = -(u + v)
@tibia.theta = 180.degrees - w
@angles = [email protected], @femur.theta, @tibia.theta, 0.0]
endSee, it’s not so bad. the a variables are link lengths, and theta is a joint rotation. The other lengths and angles won’t make sense without a picture, but it’s essentially a breakdown of the geometry involved.
My method treats link lengths as variables, but assumes joint orientations and offsets are fixed. In DH terms,
(alpha indicates a joint orientation angle)
alpha1 = -90 degrees
alpha2 = alpha3 = 0
(d indicates a link offset)
d1 = d2 = d3 = 0
(theta is a servo rotation, if you will)
theta1, theta2, theta 3 are command variables
(a is a link length)
a1, a2, and a3 can be specified at runtime