Using information i have gathered from the good people here at LM.net
I am studying Gait pattens and im trying to find an efficient and effective Quadruped gait.
I have posted and also joined in on other quadruped discussions here but since then i have never had the pleasure of posting my own quad video nor SEEN another LM walking quad! well there was one…
*It is important for walking robots such as quadruped robots to have an efficient gait. Since animals and insects are the basic models for most walking robots, their walking patterns are good examples.
An excelent site full of information but i need code!
The gaits of a quadruped here are analyzed and compared to natural animal gaits. but is there a more efficient design-build that can improve quadrupeds?
Genetic algorithms have been applied to obtain the energy-optimal gait when a quadruped robot is walking with a set velocity.
The gait which consumes the least energy is considered to be the best gait.
The energy-optimal gait is analyzed at several walking velocities, since the amount of walking energy consumption changes if the walking velocity of the robot is changed.*
I guess the information i wish to discuss here is, what type of gait should be generated for a quadruped robot as its walking velocity changes.
Quadruped gait generation based on the primary/secondary gait
A gait algorithm is proposed utilizing a new method of gait generation called primary/secondary gait. The primary gait is a fixed sequence of leg transfers with modified leg-end kinematic limits according to the obstacle presence, while the secondary gait is a flexible gait which is generated to adjust the leg-end position. The primary gait is generated considenng the following four constraints: stability constraint, kinematic constraint, sequential constraint and neighboring constraints. Primary gait parameters are modified by the influence of the obstacle. Normally, the machine tends to move with the primary gait. When the primary gait cannot move the vehicle, the secondary gait is adopted to serve as a complement of the primary gait. With the proposed primary/secondary gait, it is expected to improve the efficiency of free gait generation while maintaining the mobility of the vehicle. Simulation results are given to demonstrate the efficiency of the proposed methodology.
I hoe i havent board you and i hope you find this of interest…
Thought this might be helpful for you and an interesting read. At least it was for me since I don’t even have any single component of my phoenix yet still doing a bit of RTFM if you know what i mean.
Here is a simple quadruped walking gait simulator. This version only simulate the straight gait (forward and diagonal) based on the creep gait developed by oricomtech.com.
I have stop working on the gait since, lack of time, and funding . Anyway, after returning to this forum, I decided to resume my research . Hopefully I can build my own quadruped, by end of 2009.
been looking over the structure of the file and as im not a programmer it first became a bit of a muddel but i understand it all and i must say im very impressed!
kind of like the Zenta’s PEP.
great work. glad to see this sort of thing is avaliable for quadrupeds!
as i said im not a programmer but im wondering how this converts to Atom code?
or is intergrated in a robot!
I don’t have SSC-32 nor familiar with Atom product. I have yet to go through Zenta PEP code development.
I use microchip product, PIC18 series due to cost constraint. PIC18 had a lot of limitation when it comes to trigonometry calculation. My experiment with microchip ended shortly after I developed the gait theory and did not proceed beyond implementing the IK in realtime. Next plan is to study and use dsPIC series
The objective of the simulator is merely to provide visual aid to demonstrate the straight creep gait. It still require some work to implement it into real quad, i.e. gait stability during tripod shift, rotational and transition gait. Had some idea of transition gait, but haven’t got the time to put it on paper and study it.
The force distribution basically serve to help me to size the servo and legs more accurately.
Wow!
Excellent work with this sheet! Did I count 9 layers of charts in the gait simulation chart? (I have to try that one time). Very good illustration of the force distribution and how the cog always are kept inside the tripod. I think I need some time to mind your work with the matrix on sheet2, way over my head at this moment… I loved your walking simulation on sheet4.
Thanks. I forget how many layers I have include there. By the way, you can change the resolution (aka number of steps per cycle) in Sheet3, L11. In real application, each step correspond to 1 servo cycle (typ. 20ms). Simply increasing the step count per cycle would result in different speed.
Do notice that the tripod switch (4 legs on ground), was design for only 1 step for each switch. In actual, it is preferably to have more than to achieve a more stable gait.
I have another spreadsheet which plot the working envelope of the legs at given force, servo torque rating, and members length. Unfortunately I misplace the file
I’m new here. I had a computer animation depicting a four legged walking robot back twenty years ago.
It only ran on an Apple Macintosh. But I printed out the BASIC program, scanned said program, and have uploaded it to another site, in pdf format.
I just registered to this site, so I can not give you a link for 24 hours.
It’s six pages long, and has 201 lines of data. I never got around to building the robot, but I am an aircraft mechanic, and I build custom bikes.
The robot in the program puts it’s foot down , with the leg at a 45 degree angle. The knees bend to keep the body at a constant height, and the foot doesn’t pick up until the leg is at a 45 degree angle trailing the body.
IIRC, the Macintosh had screen pixels numbered zero, zero at the top left corner of the screen, with numbers increasing as they go down, instead of up.
I look forward to participating in the discussion. Happy New Year.
good to see new people intersted in robotics and have ideas to back them!
be good t see once you can link!
do you have any designs?
quadrupeds keep an optimal gait when it is walking with a set velocity,
so it will be interesting to see the “trailing body”! imagining it pulls itsself along rather that steps in and out of its own COG!
It’s really just a set of x,y coordinates which plot the movement of the hips and knees.
The numbers change as the robot walks. The knee is at it’s highest when the shin is 90 deg vertical , and the knee is at it’s lowest when the thigh is 90 deg vertical. So the knee goes up, down, and then up again.
I have only gotten as far as plotting the movement for flat ground, i.e. I would like to have a parallel plot for uneven ground, like if the robot steps in a hole, it will keep going rather than fall over.
I hope someone can download this document and tell me if you can make any sense of it.
I have seen some interesting things on this site, and other sites when I did a search for “gait matrix”.
Algorithm… I initially programmed the computer to make a list of all positions of the knee as the hip moves. I used the distance formula.
Then I used that list to interpolate where the knee would be, with the foot planted at a fixed point and the body moving at a constant height.
One pixel forward for each frame of the animation.
I have no idea how to make this animation run! It ran on my old 128k Macintosh, but this computer doesn’t have a 3 1/2" disk drive. My goal today was to archive the printout of the old program, so other may have a look at it.
Quadruped Gaits
Quadruped: 4 legs
All quadrupeds use one or more of the following gaits
Walk
Amble
Trot
Gallop (rotary & transverse)
Canter
**
Gait Description**
A simple description of the timing of a
particular gait requires the following
information
Number of legs
Gait period
Duty factor & step trigger for each leg
Gait Phase
We can think of the gait phase a value that
ranges from 0 to 1 as the gait cycle proceeds
We can choose 0 as being any arbitrary point
within the cycle (such as when the back left foot
begins its step)
The phase is like a clock that keeps going round
and round (0…1, 0…1, 0…1)
For a particular gait, the stepping of the legs and
all other motion of the character can be
described relative to the gait phase
Step Cycle
In one gait cycle, each individual leg goes through a
complete step cycle
Each leg’s step cycle is phase shifted relative to the
main gait cycle
The step cycle is broken into two main stages
Support stage (foot on ground)
Transfer stage (foot in the air)
The amount of time a leg spends in the support
stage is the support duration (& likewise for
transfer duration)
SupportDuration + TransferDuration = GaitPeriod
**
Duty Factor**
The relative amount of time a foot spends on the ground
is called the duty factor
For a human walking, the duty factor will be greater than
0.5, indicating that there is an overlap time when both
feet are on the ground
For a run, the duty factor is less than 0.5, indicating that
there is a time when both feet are in the air and the body
is undergoing ballistic motion
Step Phase
The step phase is a value that ranges from 0 to
1 during an individual leg’s step cycle
We can choose 0 to indicate the moment when
the foot begins to lift (i.e., the beginning of the
transfer phase)
The foot contacts the ground and comes to rest
when the phase equals 1 minus the duty factor
Step Trigger
Each leg’s step cycle is phase shifted relative to
the main gait cycle
This phase shift is called the step trigger
The trigger is the phase within the main gait
cycle where a particular leg begins its step cycle
Step Data
class StepData {
float StepTrigger;
float DutyFactor;
Animation *FootAnim;
};
StepData contains all data necessary to describe how a
single leg behaves in the gait
The FootAnim stores channels for foot motion for one
step, normalized from 0 to 1 in time. This would probably
have xyz translation and xyz rotation, plus any other
DOFs in the leg (redundant DOFs, foot flex…)
Gait Data
class GaitData {
int NumLegs;
float GaitPeriod;
StepData ]LegData;
Animation *BodyAnim;
};
GaitData contains the top level gait information and a
StepData for each leg
The BodyAnim contains all the channels to animate the
body motion (not including the legs). It can be
normalized from 0…1 in time
Stepper
class Stepper {
void Update();
float StepPhase;
IKChain *Leg;
StepData *Data;
};
The Stepper does the runtime control of a single
leg. We create one for each leg
Walker
class Walker {
void Update();
Vector3 Velocity;
float GaitPhase;
Stepper ]Step;
Rig *Body;
GaitData *Data;
};
The Walker does the runtime management for the whole
character
Integrate to get current velocity (& angular velocity)
// Move ‘mover’
Move main matrix of character mover to current pos
// Optional: select appropriate gait & gait period
Use resulting motion & rules to make selections
Compute an actual interpolated gait to use
// Advance GaitPhase
LastPhase=GaitPhase;
GaitPhase+=time / GaitPeriod;
if(GaitPhase>1.0) GaitPhase=mod(GaitPhase,1.0);
// Pose body
Evaluate Channels in Data->BodyAnim
Pose body DOFs of Rig (not legs yet)
// Update Steppers
for(i=0; iNumLegs;i++)
Stepper*.Update();[/code]
Stepper::Update() [1]
[code]Stepper::Update() {
// Check to trigger stepping (if we’re not already)
Check if StepTrigger is between Walker->LastPhase
and Walker->GaitPhase
There are various cases that need to be considered,
and can be even more complex if StepTrigger itself
is changing as a result of a gait transition
One could also consider triggering steps based on
additional rules other than just the triggering (such
as comfort based rules, etc.)
// Update step
if(We’re stepping (or starting a new step)) {
// Compute ideal foot placement goal
This should be based on where we expect the body to be at
some time in the future corresponding to when this leg
is halfway through it’s next stance phase
This might also involve collision detection & analysis of the
terrain
// Increment step phase
Increment StepPhase counter
Check if we’ve finished the step (StepPhase>1.0-DutyFactor)
Compute normalized phase within the transfer stage (0…1)
// Set IK goal
Evaluate foot animation channels using the 0…1 transfer
phase as the time
Map these channels to a world space IK goal, based on
interpolations from where the foot took off to where
the foot is going to land
}
// Update IK
IKChain->Update();
Computes actual joint angles required to meet IK goals[/code]*
Correct me if I’m wrong, wave gait refer to lifting one leg at a time, while ripple refer to alternating gait? I’m more familiar with the terms crawl and trot, used in Oricomtech; which basically means the same.
For now, we should focus on wave (crawl) gait. Trot gait are much more difficult to implement and control.
. Anyway, after returning to this forum, I decided to resume my research 
. Hopefully I can build my own quadruped, by end of 2009. 
