# Hexapod walking algorithm

Hi everyone, I am working on a hexapod, so far I have constructed one leg and now I am working on the programming. Because first I want to make sure that the programming will succeed and for that I need to solve some problems.

But first some info about the hardware, I am using multiple PIC microcontrollers with JAL as programming language.  One PIC will be the “High-level” PIC which will send commands like: “move feet A to cords(X,Y,Z)”. The other PIC will receive that command and act accordingly by sending the signals to 9 servos. So for all the legs the High-Level PIC will send data to two other PICs.

(The reason that I have two servo PICs is because a servo needs a signal of length 1 to 2 ms every

20 ms .  So 9 * 2 = 18 ms, which gives me 2 ms of extra functions like receiving data.)

The robot will eventually have 18 servos (3 for each leg). The first goal is to have a platform that can walk, other functions like Sensors, etc. will come at a later stage.

I have two problems I can’t solve;  1) How can I send a message from the first PIC to the other without interfering with the 20ms interval of the PICs? Because when the low PIC is looking for an incoming message it will pause until it receives a message. This will interfere with the 20 ms servo interval.

(I hope someone knows JAL or has a solution that applies to most languages)

I was thinking about a shared Eeprom where the High level PIC writes the data and the two low level PICs read the data. But this method probably has a lot of flaws.

2) I have programmed the Inverse kinematics part for the Servos, so when I give a coordinate the program will calculate which angels the servos must have.

But I now need to make a piece of code which has makes a trajectory from the old cords to the new cords while sending the cords in between to the low level PICs. So I can slow the servo down at the new cords. Else the servos will shoot to the new angle.

I have no idea how to make this part of the code..

I hope anyone has some tips or ideas to point me in the right direction.

Jorik

## Comment viewing options

What particular PIC micros are you using? I don't know anything about JAL, but the USART communications protocol that many PIC micros have built in is fast and convenient. It's also almost entirely managed by dedicated on-board hardware, so it doesn't clog up you micro's main processor.
I strongly suggest you grab the datasheets for your micro/s, if you don't already have them, and read up on all the USART options.

Sounds like you're looking for an interpolator for your servo movements. You've got several options here depending on what you want to acheive.
The slave micros know where the legs are at the start, and they know where they need to be at the end of the move cycle, but what exactly do you want them to do in between? You can break up the motion into a series of tiny steps, and vary the % travelled per step to adjust the speed at that point in the movement. Probably a good idea to tell the servos to go to a point slightly further than they'll actually reach by the time the next command is sent, that way you get less jitter during a movement.
If you could describe what you want to acheive with the interpolation we can help with the coding.

I'm probably going to use the 16F877a with 20mhz, maby a smaller one if possible. And I will take a look at the USART I have not worked with that yet, but does it support multiple PICs?

With the leg movements It would be best if they make an arch to the new cords when the feet is of the ground and a straight line when it is on the ground, but I think that is a bit to hard, so only a straight line would be fine, as long as it can slow down at the end.

Last night I was thinking about calculating the length (between the cords) the leg has to travel with some trigernometry, devide that into tiny steps depening on the time (just as you suggested) and when the remaining length is shorter then a given amount the steps get smaller. But then the jitters get back I guess?

It doesn't take much effort to make USART work with multiple PICs, at least so long as you're using less than 256 =D
There's an address detection function you can use to identify the individual slaves, or you can devise you own prefix system so that the correct slave listens to each message. Whichever way you do it, USART across multiple PICs is almost the same as between two, although I recommend using synchronous mode with one master and two slaves instead of asynchronous mode in this case.

Sounds like you've got a good idea about implementing the servo control. There are many interpolation algorithms out there so it probably pays to have a look around. If you make each of the tiny steps a little longer than necessary (so they overlap each other) you should be able to avoid jittering, as the servo won't have reached the target, and therefore won't stop, because the next position command will reach it before then.
It'll probably take a bit of trial and error before you can get the step size calibrated for the speed you want and the servos you're using, but I'm sure you could get accurate and smooth movement with this method.

Thank you :).

I will read up on the USART and start testing with it. For the servo control I will put my brain into thinking mode to work it out into programmable steps.

Only one question remains; will this allow me to change the servo speed, because when a 'tiny' step is bigger then necessary, won't that automaticaly mean one set speed? And if a tiny step is to small the servo's will jitter?

The servo controller will adjust the servo speed to be proportional to the difference in angle between the current position and the current target position.
If you're sending servo control pulses at a rate of once every 20ms, then we can define an angle 'Φ' (phi), where Φ is the angle the servo will travel in 20ms at the lowest speed. If you tell the servo to move Φ degrees, it will finish moving just as the next command arrives. Any angle less than Φ and the servo will finish moving too early, so there will be repeated pauses during the overall movement (a.k.a. jitter =/). If the angle is larger than Φ then the servo will be jitter free, and secondly, the further past Φ you go the faster the servo will move to try to reach the next position, thus increasing the overall speed.

Naturally, when you reach the end of the movement, Φ will have to start decreasing because you're nearing your target. This provides an automatic slowing motion as the foot touches down at the final target.

Oh oke, so the bigger the gap between two cords the faster the servo (automatically) tries to got get there? So if I make the Φ bigger in the middle of the movement and as small as possible (without jitter) at the start and finish (start cords and target cords) the leg will go faster in the middel?

Yep, this is the principle behind hacked continuous rotation servo. The further away the servo is from it's target, that harder the servo controller pushes the motor to try to get there. With a bit of trickery you can abuse the controller to do some cool stuff =D
Nice, that's good to know ;)