# Thread: Let's Discuss Kinematics, Shall We?

1. ## Re: Let's Discuss Kinematics, Shall We?

Yes actually, it is on youtube. I watched the course a few month ago. Pretty interesting stuff.

2. ## Re: Let's Discuss Kinematics, Shall We?

One more resource I just thought of: Steve Lavalle's Planning Algorithms Book is freely available on his website: http://planning.cs.uiuc.edu/

Hobbyists typically stop at 3DOF for their robots, since that's the highest level at which a closed-form solution is achievable (as far as I know). Once you pass that 3DOF level, you're looking at advanced algorithms, typically through search-based guess and solve the Forward Kinematics approaches. Chapter 3 of the book discusses kinematic chains and transformations. Later chapters are focused on methods for planning the motion of manipulators, both how to solve those higher DOF chains, and how to solve them with additional constraints such as obstacle avoidance.

EDIT: (one algorithm covered in there, that I think is very approachable, is Rapidly Exploring Random Trees (RRT), chapter 5)

-Fergs

3. ## Re: Let's Discuss Kinematics, Shall We?

Yeah, I've always pondered about how to implement an IK engine for my 6DOF Bioloid. I've always wondered how the "industrial" guys like Honda and other Japanese researches who are doing humanoids program their bot...

I can't see the ASIMO being just a bunch of sequence of gaiting, it looks too natural to be like that.. Unless Honda truly did derive their walking by just empirical methods (like what we do in hobby humanoid world)...

Does anyone out there have a biped have IK engine that's feeding their walking algorithm?

4. ## Re: Let's Discuss Kinematics, Shall We?

Originally Posted by tom_chang79
Yeah, I've always pondered about how to implement an IK engine for my 6DOF Bioloid. I've always wondered how the "industrial" guys like Honda and other Japanese researches who are doing humanoids program their bot...

I can't see the ASIMO being just a bunch of sequence of gaiting, it looks too natural to be like that.. Unless Honda truly did derive their walking by just empirical methods (like what we do in hobby humanoid world)...

Does anyone out there have a biped have IK engine that's feeding their walking algorithm?
I'd imagine that most bots are using a series of many gaits (which could be thought of as pre-solved IK solutions), very good interpolation, plus some dynamic response from foot sensors and/or gyros/accerometers. (I believe that pretty well defines how Giger works).

The issue with doing continuous IK at higher-dof is that you run out of processing power. I'd imagine most of us would run out of memory before we ran out of speed (MCMC methods like RRT are very memory intensive, as is any intelligent search...). 8-bit micros need not even try. An ARM with a decent amount of memory might be able to take a try at it....

-Fergs

5. ## Re: Let's Discuss Kinematics, Shall We?

Yeah I hear ya. The matrices not only gets complicated, but the processing power of doing matrix math for large dimension would be just insane amount of horsepower. Maybe an RF-tether to a biped is not so bad afterall? I wonder given a nice chunk of 6DOF kinematic engine, how my Core i7 would crunch it? So far, it eats any application I throw at it...

Back to the subject of kinematics, I'm starting to think if there's much more then rotation kinematic is needed for hexapods. I think orientation and movement kinematics needs to be incorporated too. So far, my assumptions are that the origin of all six of the legs are the same origin as the global (body) of the hexapod. With four of the legs having an angle offset...

6. ## Re: Let's Discuss Kinematics, Shall We?

I guess I should clarify my question:

So far, up to this point, I can my hexapod walk forward and backwards at any angle. If I fix the angle to 90-degree, then the hexapod starts to crab walk...

I've only used the principle of rotation kinematics:

Br = Q-1 * Gr

Where:

Br is your local coordinate [x y z]
Gr is your global coordinate [X Y Z]
Q-1 is the inverse of Q which is the rotation matrix

By adding a rotation offset (60-degrees) of the four "corner" legs, I can solve for Br. This Br is then fed into the "IK Engine" which will calculate the PWM for each of the three servos (Coxa, Femur, Tibia)

As for the other two legs, I just simply rotate along the Z-axis (which is the axis that goes THROUGH the body from the ground to the sky) with the variable Phi. If Phi is set to 90-degrees, then it "crab walks"

I guess it comes back this question. Since the "Phi" variable has to do with the YAW of the hexapod, and is accomplished by the rotation kinematic, can the same simple rotation kinematic (successive rotation) be used to solve for a stationary roll and pitch?

What I mean by "stationary roll and pitch" is the fact that the tip of each leg does not move, but the body will "roll" and pitch" according to the other two angles, theta and psi, which rotates about the Y axis and X axis respectively?

Are you guys (and gals) that are using kinematic-based code, only incorporating rotation kinematics to make this possible? I'm excluding the pulse calculation, since that part is just simple trig...

Or am I missing something here? Do I need to incorporate orientation kinematic and/or motion kinematic in order to do all the fancy roll, pitch, and yaw combination that I see like on the Powerpod program, Zenta's Hexapod, and Winchy Matt's (Matt Denton's) Hexapod?

7. ## Re: Let's Discuss Kinematics, Shall We?

Can you define what exactly you mean by "orientation kinematics" and "motion kinematics"?

What I've found (but I've only been playing with body kinematics for a few weeks) is:

• I store the leg end effector position (as measured in x/y/z from the coxa servo connection to the body) as well as the X and Y distance from the center of the body to the coxa connection.
• For each iteration, I calculate for each leg: (this is pretty similar to how Xan does his phoenix code)
• the gait offset on the leg for X/Y/Z.
• how the 3 body rotations affect the leg end effector, specifically, how much does it change the x/y/z coordinates of the endpoint.
• use the original end effector position + gait offset + the result from body distance, to do the 3DOF calculations on the leg.
• After all legs are calculated, check for valid positions, and write it out, to the servos

Note: my X/Y/Z convention is more like a rover bot than most walkers. X is the axis from the center of the body protruding through the front of the bot, Y is the axis from the center of the bot out the right side.

You can see a video of what I've got working so far, this is mostly crud because Issy doesn't have enough freedom in each of his joints (and his femur:tibia ratio is terribly low), but I'll be changing his leg configurations this weekend:

Note: his walking really isn't quite IK yet, it's hitting "out of range" frequently on the servos, so his legs aren't getting where they are supposed to yet, but it's a heck of a lot better than he was at robogames.

-Fergs

8. ## Re: Let's Discuss Kinematics, Shall We?

I guess I'll explain it more when I get home. I haven't grasped those chapters yet so I'd be embarassed to even try explaining what it is

As for the kinematics, I think the technique that I'm using is very similar to Xans, nearly identical. Except that I did some shortcuts which is causing me problems.

For instance, I have a resolution factor which I used to decrement the Global coordinates. I then "increment it back (so that the global coordinates are back to its original value).

During each increment and decrement, I make the end effector move to that position. So that let's say:

Start: Gx=0 Gy=0

End: Gx=0 Gy=5

The end effectors doesn't try to go from 0 to 5 immediately, since it doesn't work for walking (I tried)

So I make the resolution say 0.1:

Go to Gx=0, Gy=5

First move: Gy=0
Second move: Gy=0.1
Third move:Gy=0.2
.
.
.
Finally Gy=5

Then for the legs that needs to come "back" (the ones in the air)

Gy=5
Gy=4.9
Gy=4.8
.
.
.

So on. I think I need to modify the code like what zan does, keep each resolution size proportional to the total distance from the original location to the final location... That way, I don't need to fiddle with how much "stop and go" I need to put in between each incremental/decremental step...

9. ## Re: Let's Discuss Kinematics, Shall We?

Ok...so here is what I have.

I'm using a graph with a range of 200 for both X and Y. I then subtract 100 from both X and Y which gives me a range of -100 - 100 for X and Y. Then I multiply both by -1 so I have a range of 100 -> -100 for both...and finally I subtract each of these four things from the other. I use that for the offset value for Squidwords legs, and that makes him lean in different directions.

I hope the video makes it all clearer...sorry for the servo whine.

DB

10. ## Re: Let's Discuss Kinematics, Shall We?

Inxfergy, That is some fast quad you got there... I had no idea that the AX-12+ were capable of that sort of speed...

Darkback, your controller is pretty cool... What is it? Is it some tablet PC of some kind?

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•