Category Archives: Processing

Walking – gaits

1 Reply

Now that we can control the position of our feet and move them along a trajectory we can organise the leg movements into a walking gait.
To start with I’ll implement a static gait. In a static gait at any time during the walk cycle there will be at least tree legs in contact with the ground.  Contrast this with dynamics gaits like  trot or pace where two legs at a time are in contact with ground.

A static gait is defined by the order at which the legs are lifted during the walk cycle. In a crawling gait, for example, the legs are lifted in the following order:

gait

  1. front left leg
  2. back right leg
  3. back left leg
  4. front right leg

To implement a static gait we can split our step trajectory: one segment will be the flight phase (the complete arc trajectory) and the ground phase trajectory will be divided into tree segments.

The start of each segment will be represented by a key position. We can the use this key positions to describe our gaits in a compact data structure. A crawling gait can be then represented as:

int[][] gait = {
{1,4,2,3},
                        {2,1,3,4},
                        {3,2,4,1},
                        {4,3,1,2}
}

Each row represents a step. The four numbers in the row represent the key position for the corresponding leg, starting with the back left leg and moving in clockwise direction.
If we take for example the first row (first step in the cycle), the key positions for the four legs are:

back left leg: 1. key position
front left leg: 4. key position
front right leg: 2. key position
back right leg: 3. key position

With this setup we can generate a trajectory for each leg between it’s current key position and the key position in the next step in the cycle. Then we move each leg through the generated trajectory points until we reach the next step and a new trajectory is generated.

You can download the Processing sketch that illustrates this approach from my repository:  https://github.com/Traverso/Felix/tree/master/Processing/Gait.

In this sketch you will find two different types of static gaits and their corresponding “backwards” versions. Just set the variable “CURRENT_GAIT” to 0,1,2 or 3 to test the different walk cycles.

Walking – trajectory

Leave a reply

Once we can control the position of the foot, we can make it follow a trajectory. One cycle through the trajectory is a simple step.

A step has two distinct phases, a ground and a flight phase. During ground phase the leg push the body forward, during the flight phase the foot is lifted and placed ahead of its previous contact point.

The trajectory is constructed as a list of points in space. So we need to generate points along a straight line for our ground phase, and points along an arc for our flight phase.

The number of points in a given path is specified by a “granularity” variable. With cheap servos, there is no need to generate a lot of points. Same goes for implementing any type of “easing“, so we keep it simple and linear.

The geometry of the trajectory can be edited. This is going to be useful when implementing steering. To turn slightly to one side or another, the two legs on one side can take wider steps than the two other legs.

Once again I use processing to test a simple trajectory implementation.
You can download the sketch from the repository (https://github.com/Traverso/Felix/tree/master/Processing/Trajectory), and play with the step width and height, and the offset of the step in relation to the position of the hip.

trajectory

I wanted to upload this sketch to jsFiddle as well so you could play with it directly in your browser, but as this sites motto says “in theory there is no difference…”.
I couldn’t get the sketch to work  on the browser as it is and I currently don’t have the time to do the necessary tweaks.
Anyway if you haven’t downloaded Processing yet, is about time.

Walking – IK

Leave a reply

This is an overview of my approach to implement a static gait for Felix.  I’ll be explaining the needed concepts in a series of posts, but if you want to speed things up you can grab all the Arduino sketches from my repo (https://github.com/Traverso/Felix/tree/master/ARDUINO). 

Felix is a four legged robot, each leg has two actuators. To control the position of the feet, I need to provide a rotation angle to the servos controlling the hip and the knee of each leg. But thinking  in terms of rotation angles is too complicated, it could be much easier  if we could set the angles according to where we want to position the feet.

To do that we can use inverse kinematics. Calculating the inverse kinematics for complex systems can be quite daunting, but in our case we have a simple planar two link setup, so we can use basic law of cosines and Pythagoras to calculate the two angles.

Even though Felix legs consists of three links, we can still consider it a two link system, because due to the parallel linkage constraining the pastern, the relation between the endpoint of the shin (the hock in dog anatomy) and the foot is one of relative displacement.

There are a number of references on the web explaining inverse kinematics for this type of systems:
http://www.engineer-this.com/IK.shtml
http://www.oliverjenkins.com/blog/2012/9/inverse-kinematics-and-robot-arms
http://www.learnaboutrobots.com/inverseKinematics.htm
http://www.lorenzonuvoletta.com/simple-inverse-kinematics/

When trying to understand this method I spend some time implementing it in Processing.
Processing is great for this sort of thing because you can quickly “see” if your calculation is working.  Processing shares some common ground with Arduino, so it’s relative easy to move code between the two systems. In my repo you can find a simple Processing sketch implementing a simple IK solver for two links (https://github.com/Traverso/Felix/tree/master/Processing/InverseKinematics).

If you prefer to play with the same sketch online, you can do it here:

IK FIDDLE

http://jsfiddle.net/ronaldxavier/Et4Vj/embedded/result/