Having plenty of moving parts – like pinball machines – multi-legged walking drones tend to attract engineers, makers and hackers who like most of the men, never grow up. And now, when the honest reason why I started this project has now been told, we can move on. (Other reason being that I wanted a platform that I could use as a learning tool, like its eight-legged counterpart that I used to teach CNC machining to myself. This time I am into learning neural networks, which should be more attractive with a real physical platform, instead of boring Matlab sessions.)
Like their flying counterparts, when I saw one first time at the Web, walking around and doing some spooky dance moves, I naturally wanted to make one for myself. What has been holding me back, has been the price of suitable servos, which are something around one hundred euros per servo. And 18 of them are needed, making the hexapod a pretty expensive toy to build. However, one Chinese supplier that is beloved among RC enthusiasts, had one interesting servo in their catalog, which I decided to give a try and pull the trigger on the project.
The project is divided in three phases which are as follows: 1) Make a reliable, rugged, fully operational hexapod drone. 2) Add some cameras and pattern recognition. 3) Experiment with neural networks and learn the machine to walk with no pre-programmed gaits. Of these three phases, I have just completed the first one and I am about to start adding a camera and machine vision for it.
Phase 1: The basic hexapod
Frame parts
Although I have a capability to manufacture parts myself, sometimes it is more feasible to buy some of them ready-made and concentrate on developing and making the ones that you can’t buy from the Internet. Those parts usually require more careful thinking and designing, instead of plain, repetitive mechanical work, which I find boring.
The large top and bottom plates, like the aluminum leg parts are made by LynxMotion, out of rather high-quality brushed, anodized alloy. They feature pre-drilled holes and hardware to build a hexapod from their parts, but as making something “stock” is boring and definitely not for me, my CNC milling machine had once again something to chew.
The inner parts which attach the electronics to the frame, are designed and machined by me, out of 5 mm polycarbonate plastic.
Servos
A Chinese hobby store has a metal-geared TGY-S901D digital robotic servo available for something around 15 euros per servo. As real robotic servos cost up to 100 euros piece, these are really a bargain. But unfortunately the quality matches the price.
Quality versus price
When I am making something for myself as a hobby, I see no point trying to build something out of useless low-quality Chinese garbage. That is something I learned when I built my flying drones. Keeping those lessons involving sub-par, failing parts in my mind, I try to avoid purchasing parts and supplies from Chinese hobby stores when possible. But this time if I wanted the hexapod, I had to accept the drop in quality as purchasing 2000 euros worth of servos was out of the scope for this project.
I ordered 20 of those. One of them burned under static load in few minutes and one of them developed some other problem. Their gears have a lot of play and they oscillate very badly if not loaded. They also get destroyed if a static load is applied for few minutes. The servos are NOT robotic servos and they are definitely not suitable for robotics or any serious use. Do not put them anything that flies or drives fast unless you want to get rid of that device.
Bad, but acceptable
However, despite of the awful quality, my hexapod works really nice with them and they have plenty of power. Its movement is smooth and it walks rather fast. So I quess that they are acceptable, as long as the drone is kept in motion and the servos are not exposed to a constant static load. The quality of them is very precisely in-par with their price and you can not compare them to even entry-level Futaba or Hitec ones, the brands that I usually prefer. The femur servos carry most of the load of the drone and tend to heat up if the drone is standing still, which is why they are going to be replaced with higher quality ones.
Recommended?
Would I recommend getting these for a hexapod? If you are like me and want a nice and an affordable hexapod project – go ahead. But if you are planning to get serious about robotics – avoid these like you’ll avoid any other cheap china crap. You’ll make a nice fast and smooth hexapod out of these, but be prepared to buy some spare ones.
They make things out of metal for a reason…
Aluminum servo horns are mandatory. I tried to use the plastic ones that were supplied with the servos, ending up replacing them with aluminum ones. The servo horns or wheels are exposed to shocks while the drone walks and the plastic ones get damaged very soon. The TGY-S901D servos have 25-spline shafts that are compatible with Futaba wheels and horns.
Electronics
The 80’s called and wanted its 8-bit microprocessors back. I refused. Result: a hexapod full of 8 bit AVR processing power.
Servo controller and CPU
The hexapod is built around Lynxmotion SSC-32U servo controller. The controller is ready-made, AVR based 32 -channel controller which responds to commands transmitted over the UART link. The commands for the servo controller are generated using Arduino Mega, that runs a modified version of the Phoenix Code hexapod software. The Arduino Mega also interfaces the control link and other hardware.
Power supply
Hexapods like a constant and plentiful supply of electrons. 18 servos consume rather lot of power, and require a power supplies capable of providing enough amperes for them. The hexapod has three separate power supplies. One powers the electronics and two beefier ones power 9 servos each. The supply voltage for the servos is 6 volts, but I have not yet measured the total current consumption under load. The servo power supplies are rated for 8 A each and using only one to power all the servos, resulted in brown-outs when all the servos were working at the same time.
Batteries
The hexapod runs on LiFePo4 batteries, made of four 1100 mAh A123 16850 cells. The batteries last for approximately ten minutes. I prefer LiFePo4 cells over LiIon or LiPo because of their safety, when the weight of the battery is not a concern. Unlike all the other batteries based on lithium chemistry, the LiFe cells do not explode with flames all over the place initiate a thermal runaway when things go wrong. Cells made by A123 are among the best ones available. Unlike the genuine A123 cells, the LiFe batteries that can be bought from Chinese hobby stores are according the Interweb, among the crappiest ones available on par with the overall quality of Chinese hobby electronics stuff.
Visual treats
To enhance the looks of the drone, I added a small dot matrix led display and a vandal-resistant stainless steel button on top of it. The display provides information of the devices current state and battery voltage, while the button makes the bot to coil up for storage or extend its legs from stored position and make it ready to use.
The HDSP2000 series LED display
The LED display of the drone is made of three individual display modules, soldered on a custom-made circuit board. The LED modules are 1970’s mil-spec vintage displays, made by Hewlett-Packard. I chose them purely for their exotic look. Being old, they have absolutely no internal processing and they tend to be rather expensive, unless you’ll find a good deal of them. The displays are essentially a large shift register with LED’s attached. Driving them takes plenty of CPU time and is time-critical, which is why I added a separate AVR in form of an Arduino Nano to be a display controller for the dot matrix displays. The Arduino runs code I found from the web which transfers characters stored as bitmaps to the shift registers, modified to accept UART character input from the hexapod “main” CPU.
Rotating fading leds
The dot matrix display module is sandwiched between two white translucent acrylic plates. While designing the polycarbonate frame for the display module, I ended up embedding six small red LEDs to it because why not. I thought that when driving them using pulse-width modulation, I could make them light up the white acrylic lid of the drone in a visually appealing way, telling something about the status of the drone or just looking nice. While being a little bit nasty to wire, they ended up being quite nice addition to the lid. At the moment, when the drone is sleeping, the LED’s fade and rotate slowly around the lid. When the drone is active, the topmost LED which indicates the front side of the machine, is brightly illuminated.
Software
I am lazy and I really hate reinventing a wheel. So most of the software code that the hardware runs, is heavily based on some existing code I found from the Internet. But while I like being lazy, I see no point building things like the hexapod, if everything is copied from ready-made solutions with no own development and effort put into it. To suit my demanding taste (and my hardware), some major modifications to the software were made.
The Phoenix Code
The Phoenix Code , written originally for the Lynxmotion Phoenix hexapod which my bot is loosely based on, is a very ingenious piece of code. All the mathematical wizardry related to inverse kinematics and gait generation are done by this code.
The Phoenix Code is actually an programming-language implementation of a very sophisticated inverse kinematics calculation Excel sheet. That spreadsheet is quite of a work of an art. Even if you don’t have a hexapod, it’s worthwhile to take look at it. The spreadsheet even interfaces with the physical world, including a “connect” -button, which enables it to send commands for the servo controller using Visual Basic for Application scripting and make servos move.
The Phoenix Code, written originally for Basic Atom, was ported for Arduino that I use as a base for my development. Being a simple person, I’ve done some major reformatting to make it more understandable for me. As this is going to be an “one-off” -project, I stripped the code of all the alternative hardware options to make it easier for me to manage.
Being a very versatile piece of a software, I have not yet explored all the possibilities of the Phoenix Code, but to make the hexapod operational, I wrote some additional code for it. My additions include code to make the bot coil up for storage and extend the legs, making it ready for operation. A “sleep” function was also added which retracts the legs if the bot has been sitting for a while, to unload the servos which burn under constant static load. Interfacing the dot matrix display, LED ring and that steel button also required some programming.
Dot matrix display
Whether it was a good idea to selecting an esoteric, difficult to drive vintage display only for its looks for the bot is up to readers decide, but at least it looks nice for me. You rarely see this kind of displays, which was why I wanted to use it. As re-inventing the wheel is not my favorite thing to do when I have free time, I shamelessly used some ready made code that was available on the Internet. Some minor modifications later I had a three-module vintage dot matrix display that accepts characters over UART.
Controller
The Phoenix Code featured various control communication protocols, one of them being used by Lynxmotions own robot controller code. As the Lynxmotion guys, like I, seem to like AVR’s and Arduinos, I borrowed their code for the controller and enhanced it a little bit with a simple menu system and code to drive a character LCD display that my controller has.