L'Hexapod: Thoughts on the proto leg

The prototype leg has some fairly major failings from a mechanical point of view. The only part that may eventually find its way into a weight bearing leg is the lower leg where the cut out around the knee servo provides ample support for the servo itself and also a suitable mounting point for the servo. The hip servos need much more support before they could be used to form a weight bearing leg either in the form of metal brackets or more complexly cut board. I expect that, at some point, I’ll need to fabricate some metal brackets that have a bearing on the back, opposite the servo horn so that the servo’s shaft doesn’t need to take the weight of the leg and/or body. Ideally the skeleton of the leg should be self supporting with the servos needed only to move and hold positions.

Lynxmotion produces a ‘servo erector set’ (details here) which are brackets for standard sized servos that allow you to put together limbs and other contraptions with relative ease. I can see that the main issue with wanting to build my hexapod from scratch is initially not going to be working out how to design the various pieces that I need but actually fabricating them. There’s a nice set of custom machined aluminium brackets on show here. I wonder how hard it is to get that kind of thing made for you in the UK…

Anyway, I’m a fair way off from needing such things. The next thing on my list of things to do is to build the custom servo controller electronics and firmware. What became immediately apparent from using my quick and dirty servo controller program is that the sequences of servo moves that need to be made to move a limb from one position to another need to be blended so that all of the servos that are taking part can be moved at their own speed. My controller can easily send the three servos a set of position changing commands to move the foot from point A in space to point B in space but the end position, whilst important, isn’t all that there is to it. If each of the servos has to move a different distance and you just tell them all where you’d like them to end up then they’ll all complete their movement at different times. This works, but is rather, well, robotic to watch. I immediately decided that the controller should allow me to input the ‘key frames’ on a movement sequence and then be able to work out the intermediate points to move the servos along the way. Rather than using a single command to move each server from A to B I need a sequence of timed commands that move from A to B via a1, a2, etc. where the sequence for servo 2 takes into consideration the number of ’time slots’ that it will take servo 1 and servo 3 to compete their moves. Taking this one step further and scaling to multiple legs the blending could be continued between legs to convert a synchronised, robotic, tripod gait into a much more natural ‘ripple’. If the servo controller were to be doing this blending in real time then it could add an element of randomness into it which would probably result in an even more realistic movement (or something horrible). Interestingly this seems to be similar to the approach taken by the guys at Lynxmotion with their SEQ-01 servo sequencer product; so at least I seem to be thinking along the right lines.

Then there’s the whole question of where to move the foot to and how knowing that position in 3d space we can calculate the required positions of each of the servos that make up the leg. That’s where inverse kinematics comes in; see here for the details and the maths.