Half man, half (ant, beetle, grasshopper, cockroach…), the ultimate dream of creepy sci-fi locomotion. I’m sat here with a 6 legged centaur like image in my head, somewhat like the Scorpion King from The Mummy (exceptional 1999 CGI). Probably about the strangest intro to a post I’ve ever written but hey! It’ll do.
This is a project that has been on my engineering bucket list for ages. Projects that move are always interesting and actually generate interest from other people (try and get a “wow” from someone after you show them a really efficient buck converter…). I’ve had my fair share of wheel based projects so I thought it was finally time to give a human sized walking project a go. Enter Anthrop (greek prefix for human) hex (six, duh!), the human sized hexapod! I’d had a go at designing a human sized walking device previously with one of my friends but project costs seemed to get the best of us.
Part and body design
The largest cost of the project is finding suitably powerful methods of controlling joint positions. On smaller non-human sized hexapods, this is generally done through directly interfaced servos where the mass of the hexapod is so small that directly connecting the shaft of the servo to the leg doesn’t produce enough torque to strip the internal gears.
Lynxmotion phoenix hexapod. This image was taken from Robotshop, all respective rights are theirs.
One issue that this kind of linkage would have for a human sized hexapod is that most of the time, the joint motors will be under stalled conditions and dependent on how well rated for the job they are (overrating = £££), chance of overheating will be large along with power consumption. It is therefore worth looking to joints where the motors don’t need to be energized to keep their position. This excludes standard geared motors and rack and pinion style gearboxes. By this point, its worth assessing what is available. One suitable option would be using a worm gear based gearbox directly attached to a joint. Worm gear based gearboxes are really useful as they allow for massive reduction ratios in a small volume along with begin self-locking meaning the leg won’t be able to move the motor. The issue here however is the cost of motors and worm gearboxes capable of taking the load of a leg. Different gaits will have different joint requirements with the tripod gait having the largest forces per joint. A gross simplification can be seen that the joint where the leg transfers the mass to the floor will have the largest force applied at all time and therefore must be able to support the entire mass of the robot with a minimum of 3 legs on the floor. This therefore shows that under the worst conditions of the tripod gait, the entire mass is supported by 3 legs meaning each leg joint must be able to handle mass/3 while also having enough power to lift this mass as some specified speed. Assuming a robot weight of 15kg and a Harris weight of 60kg (just over 9 stone…), each joint must be able to support ~750N/3 = 250N. While this doesn’t seem that much, its worth noting that sharp impulsive forces like bouncing on the robot or sitting down heavily could give transients that largely exceed these forces. Its therefore worth partially overrating each joint to account for these potential forces.
Toying with a worm geared leg, the sprockets were included to allow for large reduction ratios as large worm gears are expensive!
This therefore eliminates worm based gearbox motor combinations, mainly due to cost. Knowing about worm based gearboxes does however indicate the best form of gearbox for this task – gearboxes based on screw mechanisms. It is now worth noting that a standard linear actuator can be used along with a hinged joint to move a leg in a rotational fashion.
It was a linear actuator approach that I decided to take in the end. I’ve been tracking linear actuator sources for a while and waiting for them to be reduced. It wasn’t until I found a seller on eBay that I really considered doing this project. A point of mention is in realising how many actuators would actually be needed. I did a fair bit of research into this point and most hexapods are based with 3DOF/leg resulting in 18 actuated joints. 18 actuators was completely out of the question costing way too much money and also requiring 18 feedback inputs for whatever was controlling them! It was therefore time to look at the lesser common hexapods, 2DOF/leg hexapods. One of the issues that comes with a 2DOF hexapod is the controlled lifting of each leg. With only two degrees of freedom (a hip and the leg), lifting the leg can have frictional issues between the leg and the surface it is standing on. These issues can be alleviated by ensuring the leg is “resting” on the surface which can be demonstrated by an angle between the leg and the floor being less than 45 degrees.
Visualising the legs at different angles to ground. Theta 2 is a larger angle than theta 1 incurring larger frictional forces at the point of contact. T denotes the applied torque assuming the body position stays constant.
As well as lifting the leg (rotation around Z in the above image), the leg also needs to be able to move “forwards and backwards” (rotation around Y) to allow for net movement of the robot. These two rotational requirements are the two degrees of freedom required for movement. From this and some poor sizing diagrams for some linear actuators, I could whip up a quick CAD model of what each leg and hip should look like.
A fully CAD’d leg. Excuse the poor models, I never claimed to be a CAD expert!
From a single leg, multiply by 6, add a body frame, mirror and voila! A full CAD model.
A few pics of the “final” thing! I can’t really use raycast renderers yet so apologies for the poor first picture.
By this point, I’d already started to thing about what I wanted the final thing to look like. I’d decided to use 3″ x 2″ x 10swg (3.25mm) aluminium box for the main body parts and 2″ x 1″ x 10swg for the legs and body cross bars. I could’ve designed it using smaller parts but because I was getting it all precut by Aluminium Warehouse, it was cheaper to use as few variations of materials as possible. For reference, the cut tolerance was exceptional and materials arrived really quickly! I’d definitely recommend them.
As can be seen in the above picture, the legs aren’t symmetrical along the frame. This is due to the centre of mass being offset (i.e. my bum) as I’d be sat on the middle bar with my legs rested at the far end.
Control
Obviously its apparent that having 12x linear actuators capable of producing 900N of force each, attached to a hunk of aluminium isn’t the safest arrangement and positional feedback of the joints is required. There aren’t however any premade motor controller boards for 12 motors with positional feedback therefore requiring me to design one from scratch (about the only electronic part of this project, lets be real)!
As all of the actuators are designed around DC motors with integrated limit switches, the easiest bi-directional drive method is to use a H-bridge. H-bridges are really useful as they allow for current to flow through a motor in both directions along with the potential inclusion of a shunt resistor to ground for current measurements.
My initial design was based around discrete H-bridges made from SOIC complementary MOSFET ICs (DMC3025LSD) driven by 4504 level shifters. To many engineers, this would ring alarm bells due to the low current output of the 4000 series of logic (8mA when adhering to CMOS voltage levels) and the current required to drive two MOSFET gates. Under normal H-bridge circumstances where the gates are turned on and off very fast, I would whole heartedly agree that this is completely unsuitable however, I’m going to be switching these MOSFETS on second timescales reducing the average current consumption drastically to levels suitable for this task. For cheap PCBs too, I decided to rise to the challenge of fitting 12x motor driver H-bridges into a 5x10cm PCB with microcontroller and feedback. The 3x way jumpers at the bottom of the board are for the feedback. I was originally going to use flex sensors on each joint as feedback though I’m now veering towards directly attached linear potentiometers instead. This was my resultant PCB.
The resultant PCB for a 12x motor driver board with feedback!
I’ve got to say, I was really impressed with this PCB though soldering it was less than fun, especially the LQFP64 STM32F030 microcontroller. Once I’d soldered it up however, I sequentially tested it (single channel to multiple channels etc.) and soldered on the actuators! This was the result.
Testing the motor board with the actuators.
The black soldermask looks really cool (thanks Elecrow!) and makes the controller look proper high tech! I was running the board off a 12V 4.16A power supply that I think I salvaged from an old monitor (?). This power supply was not however powerful enough to drive all 12 motors at once so an alternate drive scheme was used where only 6x are driven at once.
I thought that this board would’ve been perfect first time (ha.) but I’d made a few mistakes on the PCB which were fixable but annoying. There was however an issue with the onboard 3.3V regulator where it would oscillate for some strange reasons. After some googling, it seemed I hadn’t used enough capacitance/the wrong type of capacitors. This was really annoying as its oscillating had coupled to the level translators meaning the MOSFETs were being driven with an oscillating signal (I’m sure you can see where this is going…) therefore translating (punny) to lots of hot burnt out MOSFETs and the magic electronic smoke. There was also the issue with the supply turn on rates. As the main 12V power supply powered up before the 3.3V power supply, the level translators were keeping the output MOSFETs in an undefined state. This wasn’t good and is mainly attributed to my rushed design! This therefore warranted a much better design which got sent off today.
Second PCB design, fingers crossed!
In this design, I decided to replace the LQFP64 microcontroller for a TSSOP20 microcontroller with a 16x analog multiplexer. This actually turned out cheaper than the LQFP64 microcontroller itself. I would’ve settled on some middle ground of a LQFP48 microcontroller but none of the STM32F0 range of microcontrollers have enough analog inputs at this size. The LQFP64 microcontroller also directly drove each MOSFET through the level translator. I replaced this for 4000 series shift registers. While this may seem like a poor design choice, this was done because the 4094 has an output enable input. When this input is low, all of the outputs are in a high impedance state. This in conjunction with pull up resistors on each gate pair ensures that during power up, every MOSFET complementary pair has a low output – bare in mind that complementary MOSFET pairs are wired up as CMOS inverters. To further ease routing, I chose a different MOSFET IC, the ZXMHC3F381N8. This MOSFET IC is another SOIC8 package though features 2x NMOS and 2x PMOS allowing for a full H bridge to be made from a single package. This halved the MOSFET SOIC8 packages required compared to the first generation board. To also alleviate space issues, resistor arrays were used for the MOSFET gate resistors and gate pullup resistors.
One minor issue with the 4094 shift register is that it expects input voltage levels identical to its supply voltage. This required some form of level shifting between the 3.3V microcontroller and the 12V shift register. This was accomplished using a RTL inverter based around a digital transistor, the MUN2233. I think that digital transistors are a pretty cool design as they’re essentially a transistor with base and base emitter resistor integrated into a single package. This means you can connect the “base” directly to a microcontroller, eliminating two discrete components and easing routing. One may say “why don’t you use a small signal MOSFET?” to which I answer: even though the gate capacitance is small, it can still put stress on a microcontroller GPIO pin potentially reducing the life of the microcontroller. MOSFETS also feature larger capacitances for inverting circuits. After some simulations, using that digital transistor, I could achieve shift register clocks of up to 500kHz (the 4094 has a typical clock frequency of 28MHz) translating to output update rates of 20.83kHz. From this, if I wanted to software PWM the motors, I could achieve 5 bit (32 level) PWM at an output frequency of 651Hz. This however shouldn’t be necessary until more complex gaits are required.
Software
As ever, I’d decided to use an STM32 microcontroller to control the entire thing. I have a feeling that people might say a lowly Cortex M0 at 48MHz isn’t enough to control an entire beast of a human sized hexapod – bearing in mind that Stompy the hexapod uses a Beaglebone Black (1GHz Cortex A8) for each leg! Looking at that seems to put it into perspective for me but realistically, I don’t need that much power other than “move to this position”. The actuators are so slow that the bandwidth requirement of control algorithms is minimal anyway. Even if I was to implement 12x PID controllers for each actuator and feedback, the bandwidth would be on the low tens of Hz range (maximum extension for the actuators I chose was 4s for 50mm) translating to a super slow control loop. For this reason, right now I’ve decided not to implement a standard PI or PID controller and have instead gone for a non-linear “bang bang + hysteresis” style control. The processing requirements for this are truly minimal resulting in a few store and loads, conditionals and a bit of analog scaling math.
Actually controlling the robot is still a point of decision. Originally, I was going to use a standard analog joystick but I’m currently thinking about controlling the robot through bluetooth. The port which the handheld controller connects to is connected to inputs that allow for analog reading or a UART connection. This means I could simply connect a standard bluetooth module (HC-06 or HM10) and write up a simple UART bluetooth driver for the STM32F0. I could then control the robot using my phone, reducing the need for a handheld design. This would also allow me to use it as a gigantic remote controlled hexapod!
By this point, all orders have been placed and waiting for materials to arrive is the main time consumer now!
