Drew's Robots

Makerbot Upgrades Part 1

2012-01-27T18:24:00.000-08:00

The company I work for has, over thelast few years, ordered many parts from rapid prototyping shops. Wefrequently have need for one-of-a-kid jugs and fixtures, custom traysto hold parts for automated assembly, and prototypes for enclosuresand other mechanical parts. This year we purchased a MakerbotThingOMatic printer kit, as the cost of parts we've ordered in thelast year alone exceeded the cost of the ThingOMatic. Since we'vebought it, after the initial setup and tuning time, we've had itrunning nearly non-stop, as we've been constantly finding new usesfor it. It's amazing how after you buy a 3D printer, you start torealize how many uses it has beyond what you originally bought itfor. It's been a very worthwhile investment.

As useful as the Makerbot has been atthe office, it took a lot of tweaking and adjustment to get it towork. As initially delivered, the ThingOMatic has a lot ofmechanical and electrical deficiencies that needed to be correctedfor it to print accurately and reliably.

Makerbot Upgrades Part 1

Axis tensioning

The Makerbot ThingOMatic uses two beltsfor positioning the build platform. Both X and Y carriage movementuse a continuous belt stretched between the drive and idler pulleys,with the movable platform clamped to the middle of the belt. Youadjust the belt by loosening the motor mount screws and shifting themotor along oval mounting slots till the tension is right. This doesnot work very well. It's tricky to get the tension right whilesimultaneously pushing the motor sideways and tightening the screwsto clamp it down. The plastic base plate of the Y axis flexes enoughto make it hard to tell how much tension the belt will have when youlet it go. The belt tension is only held by the friction of themounting screws and motor face plate. Inevitably the motor slips outof position. If you clamp the motor down enough to make sure itnever slips, the screw heads dig into the wood or plastic structure,making permanent indentations that will make it hard to properlyadjust the tension in the future.

Slack in the belt shows immediately asuneven lines, circles with flat sides, and gaps in the finishedprinted parts. A way to properly set and hold the belt tension isthe most important improvement to make to the machine. There are alot of items on Thingiverse designed to fix this flaw, typically bycapturing the motor bolts and anchoring them to a nearby structuralelement with a bolt that can be turned to precisely set the belttension. Thingiverse item 14098 was the one I chose to fix myprinter. First up was the X axis tensioner. This was the firstfunctional part I made on the machine, and it was pretty ugly.

Gaps in the print, irregular lines,non-round holes that I couldn't fit screws through without lots oftrimming. It was still good enough to correct the X belt tension,improving the print quality for the next belt tensioner. This onewas still crude, but better than the first one. This one went on theY axis.

Another cause of poor belt tension isthe lack of support for the X axis idler pulley. As supplied thepulley is supported on a bolt screwed through the plastic base plate. It's really not very rigid – the base plate can flex under thebelt tension Thingiverse item 12528 fixes this by securing the topof the bolt to the printer frame. This also helps to prevent theloose cable from the heated build platform from getting caught on theprotruding bolt.

With the X and Y belts holding propertension, the quality of the build is much improved: the machine canprint solid surfaces without gaps and can make reasonably roundcircles.

The Z axis has its own tensionproblems. The Z axis is driven by a screw rather than by a belt, sthere are no problems with belt tension. The problem with the Z axisis that the print head is mounted quite far out from the screw, on anot very rigid wooden platform. Tension on the plastic filamentbeing pulled into the print head lifts the entire print head, as thefilament drive motor has more than enough torque to bend the Zplatform upwards. If the filament feed snags and pulls irregularly,the up and down movement of the print head leaves irregular-widthlayers on the printed objects. In the worst case, a sudden upwardsbending of the print head – caused by a snag in the filament feed –results in the layer being printed detaching from the object beingprinted, ruining the part.

At first, I just looped the filament onthe desk next to the machine and periodically unwound more filamentfrom the loose coils. Later, I propped up a metal pole behind themachine and placed the spool on that. This still required me tocheck the filament every few minutes as the machine printed. As mygoal was to have this machine run mostly unattended in a back roomeventually, this wasn't acceptable. I needed the filament to feedinto the machine by itself.

Thing number 12974 was one solution for this.

This was the largest thing I'd printedon the machine so far, taking several days for all the parts. Itdidn't print perfectly, with one part failed due to layer detachmentafter the filament snagged and I didn't catch it in time, and otherfailed due to static electricity induced lockup of a stepper motordriver.

The spool holder helped with thefilament feed issues. It still wasn't perfect – theplastic-on-plastic rolling of the spool on the holder had enoughfriction to pull the print head up, leaving uneven layers in theprinted objects. It was still good enough at this point for us tostart using the machine for production use at the office.

I later found some ball bearings in myjunk box, and printed inserts that allowed me to mount the filamentspool on some metal rod also from my junkbox. Now the spool rollswith very little friction, and the filament unwinds freely. It spinsalmost too easily at this point – the slightest tug from theextrusion motor starts the spool turning for a while, resulting inloose loops of filament around the spool. Not a big problem yet, butI do worry about the loose filament getting caught in the Z axismovement.

The next step would be to make atension sensor for the filament and attach a motor drive to thefilament spool, unwinding it so that the print head never feels anysignificant upward pull while printing. I probably won't bebothering with that – there are still a lot of other things I cando to improve this machine.

Physical assembly

2011-09-10T20:32:00.000-07:00

Physical assembly

The robot is built around a piece of 1/8" thick waterjet-cut steel plate, provided by Big Blue Saw. All the major structural elements - the leg mounts and the outer shell - attach to this center piece. Earlier versions of the robot were completely handmade. Investing in a waterjet-cut frame helped tremendously - everything was actually aligned properly and held securely, which can't be said for some of the handmade frames.

The power indicator is semi-permanently attached to the front of the frame. The indicator assembly is mostly built up from copper wire, which is wrapped around part of the steel frame at the front and soldered to itself to stay in place.

Physical assembly of the robot actually starts by securing the servo wires to the leg structure.

The servo wires are routed through some steel spring material I found in a scrapyard. I don't know what this stuff was originally used for, but it makes a decent wire loom, and looks better than just using zip-ties or heat-shrink on the servo leads. The two servo leads from each leg are run through a sleeve that is also slipped over part of that leg's support structure, and then all four leads from each side run together through a sleeve before plugging into the Pololu SSC board.

The shell of the robot's main body is made from a three inch copper tank float from McMaster-carr, caved up with my trusty Dremel tool. Each shell half mounts to the main structure at three points, connecting with hand-cut right-angle aluminum blocks. The mounting hole at the front of the frame is occupied by the robot's main power switch.

Actually getting all of the electrical parts inside the shell is challenging. The battery just barely fits into the available space, and all the other parts need to be placed in just the right locations for everything to fit. I haven't quite got the wires run properly in this shot.

Here I almost have everything in place. You can see the charging jack, attached to the upper half of the shell which is upside-down on the right side here. That will need to be carefully routed around the battery to the back of the robot.

The top half of the shell is attached now. On the back of the shell, above the charging jack, is the connector for an external antenna. I almost never actually run the robot with an external antenna, as even with just the jack the radio range is more than enough for the distances I usually let the robot get from me.

Flipped upside down and with the bottom cover removed, you can see the antenna lead connecting to the Xbee radio, mounted on the Xbee explorer board attached to the Pololu SSC. Once I manage to get the robot assembled, everything is very tightly packed. Other than the power switch, charging jack, and external radio connector, nothing is actually physically mounted. Everything is just wedged together so tightly that nothing can move or get loose. This is not actually the best practice, but there's really no room for mounting hardware inside the robot, and I take some care not to have anything rubbing against sharp edges or having wires with no slack that can get pulled loose.

Once the central body has been assembled, I can move on to the legs.

Each leg is made up of two servos, a 'knee' segment, and an outer leg and foot assembly. Assembly starts by mounting the inner servo, the one which moves each leg forwards and backwards, to the frame. On some of the earlier robots I built I'd cut the mounting tabs off the servos and glued them in place. That was a bad idea for multiple reasons. Not only did the glued joints fail too often and make it hard to maintain the servos, but the direct connection didn't offer any cushioning. Here I've made a point of using good quality rubber isolators and brass ferrules at all four mounting points on each servo. I'm hoping this will help prevent both broken gears and cracked mounting tabs by spreading out the loads and providing some degree of impact cushioning.

Here the 'knee' segment and the second servo is attached. The knee segment is cut from a piece of 2 inch aluminum tubing. I designed this piece in Autocad, initially as a 3D object, from which I generated a 2D pattern that I then printed out and wrapped around a tube, taping it in place. I then used a drill press to drill the holes for mounting hardware and axle points, and then cut out the openings again using my dremel tool. This design has worked very well.

Here you can see how the second shaft I've added to the servo fits into the knee segment. Having a second pivot point on the back of the servo in-line with the main servo axle makes the legs far more rigid. Servos made specifically for robot use often come with this feature built-in. Here I've carefully modified the cheap hobby servos to have a pivot, hopefully in a way that won't compromise the structural integrity of the servo case too much.

The last step is to attach the outer leg/foot assembly to the second servo. Each of these is made of up several pieces of metal. A waterjet-cut steel frame is attached to the servo, again using four screws to attach to the servo mounting points. Welded to that is a short length of half-inch diameter steel tubing. Inside the tube, at the end, is a oil-impregnated bronze bushing retained by a welded-on washer capping off the end of the tube. The foot is a brass drawer knob, which along with a spring and a shoulder screw that slides freely in and out of the bushing makes for a crude shock absorber mechanism.

The choice of the material for the foot came after a long period of trial and error. This robot walks with a somewhat sloppy ambling gait, where the legs move forwards and backwards in diagonally opposite pairs. At most points in the walking gait two legs are pushing backwards, one is raised and moving forwards, and one is moving forwards while sliding along the ground. Early versions of this robot had square rubber pads for feet. Those tended to get stuck on anything but very smooth surfaces. For walking on carpet, I found that smooth, round, slightly slippery feet worked best - the robot needed to be able to push against the ground yet not have the forward-moving feet catch on anything. I used nylon balls on the 2007 version of the robot, and those worked well, but for this version I decided I wanted a more steampunk look, with brass and copper parts, and went with some nice little brass knobs for feet.

That's the basics of the physical assembly. Still a bit of an annoying problem is what to do with the loops of excess servo lead leaking out of the leg joints. In the past I've looped these up and anchored them in place with a bit of tape or a zip-tie, but neither of those solutions really fits with the design philosophy of the robot.

2011-09-10T19:24:00.000-07:00

Electrical and Mechanical

The electrical system of the robot is built up around a Pololu 8-channel Serial Servo Controller. The SSC receives a serial signal from an XBee Pro radio modem, and drives all eight servos on the robot.

The XBee radio is mounted to a Sparkfun Xbee Explorer board. This regulates the 5V from the Pololu board down to 3.3V, and provides a handful of useful status LEDs. The whole thing is assembled in a rather inelegant dead-bug style. I've also attached tantalum capacitors onto all the power supply outputs to make it a bit more tolerant of noise on the power supply rails.

Power comes from a 2 cell, 1mAH LiPoly battery. The battery is directly connected to a management board which disconnects it in case of shorts, overvoltage, or undervoltage conditions. That keeps the robot from bursting into flames if I accidentally short the main battery connections. There's a jack on the back of the shell for charging, and a power switch to switch power to the rest of the robot.

The battery provides about 8V when fully charged, which is too high for the servos which don't run long on more than 6V. I use a Turnigy 15A ubec to drop this down to something the servos can handle. There's an additional and rather large power switch hanging off the ubec. I really should cut this off and solder the wires together, since it's really not needed. I really didn't want to put a regulator on the robot for a long time, not confident that it could handle the current draw of eight servos running at once, but it's actually worked out quite well.

The green blob wrapped in wire is a ferrite which reduces the noise coming from the switching regulator.

The only other electrical component on the robot is the power and direction indicator. This is made from a uranium-glass marble, surrounded by six ultrabright, ultraviolet LEDs. The LEDS are all aimed inwards at the marble, the UV light from the LEDs making the marble fluoresce green. The net effect is to make the marble seem to glow with its own internal light. I can excuse this even with my 'no purely cosmetic components' rule. It shows me that the robot is completely switched on, and unambiguously indicates which end of the robot is the front. As the design is roughly radially symmetrical, this is important.

Here's a everything electrically complete, being bench-tested. Now to assemble it.

Servos for a cheap walker

2011-09-10T15:13:00.000-07:00

This robot has always been built on a limited budget. The original used entirely leftover parts, and even when I started buying parts specifically for the walker I tried to keep the budget down. I can't afford to use the servos that are made specifically for robotics use, so I have learned to work with common hobby servos.

For a while, I used the Hitec HS-5645MG servos. These were ultimately disappointing - the gearbox was not robust enough, with the second largest gear being particularly prone to failure. I tried using the notoriously cheap HX-12K, which is actually a relabeled TowerPro MG995 servos. Those had more robust gears, but terrible position control and motors that rapidly burned out under load. I built up some hybrid servos using the motors and electronics from the HS-5645MG and the gearboxes from the HX-12K servos. Those worked well for a while, until the HX-12K cases simply disintegrated from the load.

As I was rebuilding the robot this year, I looked at options for replacing all the servos. I considered the Dynamixel AX-12A, but using it would require major structural redesign, and I was concerned with how much torque it could actual produce. I eventually bough eight of the new TowerPro MG996R servos, the replacement for the discontinued MG995. I knew they were cheap junk, and resigned myself to replacing them after every hour or so of run-time and coming back from GenCon with a completely broken robot.

I was very surprised with how much better the MG996 were than the HX-12K. It's still a cheap $12 hobby servo, but they seem to have redesigned every common fault or failure point in it. The biggest surprise was this:

The MG995 servos consistently failed as the central gearbox shaft gouged out its retaining hole, causing the gears to shift out of place and jam. Seven of the eight MG996 servos I bought had brass bushing inserts in the case where the two smaller shafts are held. The eighth still had the old plastic bushings. There was no indication on the outside of the servo as to which ones had the brass inserts and which didn't, so it may be a matter of luck whether servos you buy have these or not.

The MG996 servos also have a completely redesigned controller board, internal wiring secured with dabs of glue, and generally better quality of construction compared to the AX-12A/MG995.

I ran the robot for the entire GenCon weekend, putting an estimated two hours of run time on the servos. The only servo to have any problem was the one which lacked brass inserts. That servo is starting to show signs of classic servo case degeneration. The rest of them are still working smoothly.

Now these are still cheap $12 servos, with all the limitations you'd expect:

Not programmable
No feedback to your controller
Poor repeatability and centering
Limited to 6V max, so you need a voltage regulator if you're using LiPoly cells
Cheap potentiometer feedback
No rear shaft (I added one to all of mine)
Some degree of jitter and overshoot, although nowhere near as bad as the MG995

I wouldn't use these on a biped, or any robot where balance or precision is important. I wouldn't use them on a helicopter or airplane, or any vehicle where a momentary loss of control can mean disaster. I wouldn't use them in any competition robot. But for a cheap, just-for-fun quad walker, these are pretty good servos.

Little Walking Robot, AKA 'Puppybot'

2011-09-10T13:37:00.000-07:00

History and Origins

This robot started out as something fun to do with spare parts. I used to compete in robot combat competitions, starting with the original non-televised Robot Wars events in San Francisco, and then later BattleBots, as well as several other smaller events held around the country. I used to use cheap RC airplane radios to control the combat robots, and those radios always came with three or four cheap hobby servos, as well as a small battery for the servos and receivers. The servos were nearly useless for those robots, far too small and fragile, and after a few years I replaced the standard receiver and battery with a micro receiver and voltage regulator off the robot’s main batteries.

One slow weekend I took a receiver, battery, eight servos, and some silicone adhesive and scrap plastic, and built something that could limp around the workshop, slowly. It was fun enough for me to rebuild it a few times and tweak the design, eventually adding a microcontroller to automate the walking cycle. With that I ended up with something that worked well enough to show off to people. The main limitation was severely limited battery life. The little receiver battery I was using to power the robot, basically four rechargeable AA batteries, couldn’t handle running 8 servos under constant load for more than a few minutes. Switching to five heavy-duty sub-C sized cells, leftovers from combat robot battery packs, vastly increased the run time, and the additional voltage and current capacity made the robot much faster.

At this point the robot had passed beyond the point of begin something to do with leftover parts to where I was spending time and money specifically on it. I took the robot with me to one of the robot competitions, not as a competitor but simply to show off, had more fun with that than I’d had actually competing, and took home the ‘coolest robot’ award despite not actually being entered in the contest.

In 2004, my wife and I began attending GenCon. This was after the smaller local convention we had been attending (CastleCon) shut down - going from a 300-person local convention to a 30,000+ person national one. We’ve attended every year since. One early year - either 2005 or 2006, I’m not sure - I decided to bring the robot along, to show off to some friends. I had a lot of fun, not just with friends we were meeting but also walking the robot around the convention.

Since then the robot has been a fun way for me to show off my engineering skills, meet and entertain people at conventions and shows, and to experiment and learn with different ways of building it. Learning what breaks on the robot, fixing it, and then finding the next weak point has taught me a lot, that’s I’ve used at work and in other projects.

Overall design philosophy

Simplicity. The robot is made from as few parts as possible. Every part that is added is another part that can fail. It is easy to solve a problem by adding more components. It’s harder but far better to do so while also simplifying the design.

No purely cosmetic parts. As per the previous rule, the robot isn’t allowed any parts which are there purely to make the robot look better. Every part is required to in some way make the robot better in a functional way - more reliable, more durable, easier to control or more versatile, etc.

Every functional part has to be designed with aesthetics in mind. As I am not letting myself hide the functional parts of the robot behind cosmetic covers, I try to make the visible parts look good. This usually follows from good workmanship, and not taking cheap and easy solutions to little engineering issues like insulation and anchoring components in place.

No structural joins made with glue. The early versions of the robot were held together with silicone gel. The servos were glued to the sides of battery, the microcontroller board and radio were glued to the top of that, and the feet were glued to the outermost servo on the legs. This was easy but unsatisfactory - the glued joints would fail unpredictably while walking, had to be pried or cut apart to replace servos, and took hours to set after being repaired. Now I make all mechanical joins with easily detachable, reusable fasteners - screws and bolts - while mechanical joints I never need to detach are welded or soldered.

Ease of repair. Wherever possible, parts can be easily accessed and replaced in the field. I can rebuild the servos - replacing gears and electronics - without even removing them from the robot. I can’t replace the battery or other electrical parts as easily, but I don’t have spares for those anyway.

Crowd-friendliness. At conventions, the robot can come into direct physical contact with people. Children will poke it, people may pick it up or trip over it. I needed to design it to not injure anyone accidentally. The robot has no sharp points or edges, but uses spheres and large-radius curves wherever possible. I’ve also tried to design the joints to be open and have no tight finger-crushing pinch points, although it’s still possible to catch a finger painfully in some leg positions.

Smooth and accurate translation of stick position to leg motion. The earliest versions of the robot had no mixing, just straight connections from the radio receiver to the servos. Motion of the sticks were translated directly to motion of the legs. It was very difficult to control, but I found I could get a lot of expressive motion and gesturing with different stick positions. Later I experimented with automated walking cycles. I’d just have to push the joystick in the direction I wanted the robot to move, and it would walk itself that way. This was a lot easier, but a lot less expressive and entertaining. I switched back to direct control over the legs, but I also added custom mixing algorithms to make walking easier. Key to making the robot appear lifelike is accurately translating the motion of the joysticks to the movement of the legs. Getting the right joysticks is important. The joysticks on the old RC airplane radios I started with were lovely - very smooth motion, independently adjustable spring centering on both axis, and mechanically adjustable center point trims. When I decided to move away from the RC airplane radio and use an Xbee serial modem instead, I tried using a pair of Wii Nunchuk controllers. These were nicely compact, fitting in the palms of my hands, but the joysticks were terrible, having very limited range of motion, zero adjustability, and a plastic housing that gave them an octagonal range of motion. Walking with the Wii controllers was a lot jerkier, lacking the fluidity or ability for fine gestures that I had before. This year I took the joysticks out of the old airplane radios and built custom-made controllers around them, which gave me a lot of the old fluid motion back. Also important is that the leg joints themselves can move smoothly over their entire range of motion. This means no bodywork to hang up or impair free motion, and servo wires routed in such a way as to not get caught or pinched as the legs move. The last has been tricky, and a perpetual challenge to the design.

Videos

These were not taken by my, but by other people at the conventions, whose names I didn't get, but who kindly took videos of my robot and put them up on Youtube.

GenCon 2011

http://www.youtube.com/watch?v=syVsB-w_ieQ

http://www.youtube.com/watch?v=SMPTkkIAdhE

http://www.youtube.com/watch?v=238P7cKV7_E

http://www.youtube.com/watch?v=nQ-gir6VnB8

http://www.youtube.com/watch?v=R9oBin07chs

GenCon 2007

http://www.youtube.com/watch?v=DQXvaPQujFs

http://www.youtube.com/watch?v=DE05joI6gbs

Quick GenCon update

2011-08-09T06:09:00.001-07:00

I just attended GenCon Indianapolis 2011 with the robot. Over the course of the three main convention days (Thursday, Friday, and Saturday) I took the robot from fully charged to fully depleted batteries five times without a single mechanical failure - a new record, and actually quite astonishing considering I'm still using $12 cheap import servos. This translated to over two hours accumulated time walking the robot around the convention and entertaining the crowds.

With the new 60mW Xbee Pro radios I did not have a single incident of control failure, even when the robot was 30+ feet away and surrounded by people with cell phones. I didn't even need to use the external antenna on the robot itself.

The MG996 servos held up well, but a few are starting to sound rough. Quick examination reveals that while most of the MG996 servos have brass bushings on their secondary gear shafts, a few still have plastic bushings. I can't see any indication from the outside to tell which is which. When I get back from vacation next week I'll do a thorough teardown and inspection of the entire robot.

Adding a second hinge point to a common hobby servo

2011-04-17T16:07:00.000-07:00

When using servos as joints in robot limbs it is helpful to have a second axle point on the rear of the servo, opposite the servo output shaft, to increase the rigidity of the joint and reduce stress on the servo shaft bearings. Many high-end servos meant for robotics come with rear axles points built in, but I don't have the budget to afford those servos. There are a few alternatives that work with common hobby servos.

Attempt #1: Lynx Motion press-on plates

The first thing I tried, and where I got the initial idea from, was the Lynx Motion injection molded servo hinge. This is a plastic case that presses on to the back of any standard servo and adds a hinge point. It's fairly cheap and easy to use, and I used it on a few servos, but ultimately I found it unsatisfactory. There are several basic flaws here. The press-on hinge adds significant thickness to the servo, making it hard to retrofit into an existing design. The press-on plastic plate covers two of the servo case screws, so you have to remove it to open the servo up to replace broken gears or re-grease the gearbox. The piece is pressed on with pressure-sensitive adhesive, so you have to rip it off to open the servo. The adhesive isn't very strong, so the piece can tear loose by itself, and the plastic pin that makes up the hinge point also breaks or wears away easily. It's a good idea, but it's possible to do much better.

Attempt #2: Cutoff epoxied screw head

My first idea for making my own hinges was to cut the head off a self-tapping wood screw, then epoxy the head to the back of a servo. I used a phillips head, flat countersunk finishing screw, with the widest surface I could find, and sanded the plastic surface where it attached to the servo to try and make the epoxy joint as strong as possible. This seemed to work well enough, but I didn't test very long with this design before having a new idea.

Attempt #3: Weld nut epoxied to servo case.

The problem I found was that having a fixed post as a second servo hinge made it hard to assemble the servo into a single-piece bracket. A hinge that could be attached to the servo after the servo was placed in the hinge would make assembly easier, so I bought some weld nuts and epoxied them to make second hinge points on servos. I could then place the servo in the bracket, and then insert a screw and sleeve bearing through the hinge hole on the bracket into the weld nut. The sleeve bearing made for a smooth wear-resistant second hinge point. This design worked very well for several versions of my quadruped robot.

The failing of this design was the epoxy joint between the weld nut and the servo. Even with sanding the servo case and experimenting with several different kinds of epoxy and cement, a weekend of running the robot at a convention would result in several broken hinge joints as the weld nuts came free from the servo cases. I was also having a lot of problems with epoxied structural joints elsewhere in that version of the robot breaking. When I set out to redesign and rebuild my quadruped again, I set out to have no load-bearing epoxy joints anywhere in the design.

Attempt #4: Weld nut inside the servo case.

I have just recently purchased a full set of MG996 servos to rebuild my demo walker robot. I had expected these to be similar to the MG995 servos I'd used previously: barely usable crap needing lots of rework before I could use them. I was therefore very surprised to discover that the MG996 servos were a vast improvement on the prior model. Better electronics, better quality plastic and tighter construction, glue securing every wire, and most astonishingly brass bushings on the intermediate gear shafts, where the MG995 servos had been so prone to failing. They still don't have rear hinge points, of course, so I set about adding them.

I didn't want to epoxy a weld nut to the outside of the case, so I'd have to put it inside the case, with the barrel of the weld nut extending through the servo case. I hadn't wanted to use any solution that meant intrusion through the servo case, but I didn't see any other way to securely attach the hinge. I disassembled the servo and carefully measured the interior to make sure I'd have room to fir the weld nut without interfering with the motor, control PCB, or any other part inside the servo.

Here's the rear case, drilled out, and with a trimmed weld nut.

I used a larger weld nut than before, one with a 5/16 inch barrel diameter, mostly because it was what I had on hand. This one was slightly too large to fit inside the servo rear case, so I had to slightly trim it with a Dremel to fit snugly inside. I then pressed it in and used two-part epoxy to secure it in place. This does not violate the rule of no load-bearing epoxy, as the epoxy is only being used to hold the weld nut in place until the hinge is fully assembled.

On the left: Servo case inside with a weld nut epoxied in place. Middle: same thing, seen from the outside. On the right is the fully assembled hinge point, with washer to spread the load across the plastic case, bushing pressed around the weld nut barrel, and 1/4-20 machine screw holding the whole assembly together. Last step in assembly before putting the servo back together is to place a small piece of tape over the inside of the weld nut as a final step to prevent it from shorting out any exposed electrical conductors inside the servo.

Finally, a fully assembled servo with a very heavy-duty rear hinge point, inline with the servo output shaft. This can be used to make a mechanically rigid hinge in a robot leg, which I'll be showing next update as I reassemble my quadruped walker.

Deficiencies of the TowerPro MG995

2010-11-30T15:44:00.000-08:00

(and how to address them)

In my quest to build entertaining little walking robots on a slim budget, I’ve evaluated many low-end servos. When reviewing the options available at the moment, I keep finding myself drawn to the TowerPro digital servos (the MG995 and MG996 in particular). These servos have a deservedly poor reputation - they’re very cheaply made, have high failure rates and poor position-holding - but it’s hard to ignore that you get a digital, metal-gear, ball bearing servo with impressive speed and torque for about $10. I would never use one of these servos on a RC aircraft, where failure would mean an expensive crash, but for the little walking robots I make I’m prepared to accept occasional failures.

My current project is to see if there is a way to take these cheap, nasty, and unreliable servos, and modify them into something more reliable and accurate while still spending less than I would on buying high-quality servos in the first place. Bonus if I can add functions available only on high-end robotic servos such as telemetry feedback from each joint.

The MG995 servos have the following deficiencies needing to be addressed:

1. Generally cheap construction

The most obvious sign that these are very cheap servos when you open them is the general lack of care and quality control in the design and assembly. In the electronics compartment, the PCB is not reliably located in the case, but seems (at least in the servos I have opened) to have some freedom to move in the case. There are glue blobs on the motor wires where they connect to the board, but not on the potentiometer wires, nor on the wire connections on the motor or the external servo connection wires. I have not seen a wire break on any of my servos, but I expect it to be a likely failure mode with long-term use. While this could be improved with some additional hot glue or similar adhesive on the wires, I am thinking to completely replace the board and interior wiring.

In the gearbox section, I have found chips of metal and plastic in the gear assembly, and the grease is thin and uneven and is of unknown quality. I have gotten in the habit of disassembling, de-greasing, cleaning, carefully reassembling and re-greasing these servos before using them, as well as periodically between events.

2. Poor position control

The MG995 is notable for its poor position holding. There is significant ringing and overshoot when the servo is commanded to rapidly change position. When a heavy overhung load is attached to the servo output, such as the leg of a robot, the servo can actually start oscillating as it constantly overshoots and over-corrects while trying to hold position. This was very noticeable with some versions of my walking robot, when I had the robot stand with one leg off the ground sometimes the entire robot would begin shaking uncontrollably. Granted that I am running these servos at above their recommended voltage and with large overhung loads, which is not their intended application, but I have seen that other servos intended for similar use do not have this problem.

Other than asking the servo to do a job it wasn't designed for, I suspect a poorly tuned feedback loop and a motor with a heavy, high-inertia core. I have tried replacing the motor, control board, and potentiometer with those from a Hitec HS-5645MG, keeping the same case and gears. This gives much better position control and seems to be reliable, but is too expensive per servo - if I’m going to have to buy replacement parts for a Hitec servo for each servo I use, I might as well just use more expensive servos. I am probably going to stick with the existing MG995 motors for cost reasons, but replacing the control board is looking like an attractive option.

3. Weak case

The MG995 seems to have been made with the least possible amount of plastic. The most common failure I have found is the plastic lip around the center shaft in the gearbox. The torque on the main output shaft of the servo is effectively felt by this secondary shaft, so there is a lot of shear load applied to this point. There isn't much plastic around the wells in the plastic case top and center section that locate the ends of this shaft, so over time these openings start to oval out and allow the shaft to shift position. This leads to the gears on the center shaft getting out of alignment, leading to increased wear on the gears and increased load on the motor. I have even seen the gears be pushed enough out of line to hit the sides of the servo case, filling the case with gouged-out plastic chips and debris. This is a major problem with these servos, something that seems to happen inevitably even with moderate use. I have tried several things to solve this problem. The most recent and somewhat successful solution was to carefully shave down the interior of the servo case, cut a small piece of thin sheet steel, drill a small hole in the steel and insert it into the case to locate the end of the shaft. This works, the steel plate holds the shaft in place and prevents it from wobbling, but requires very careful work as the exact placement of the hole is critical to maintain proper gear spacing.

The second failure point is the mounting ears. The case is quite thin where the mounting tabs attach to the case, and I have seen them crack off on several servos. Admittedly I am subjecting the servo mounting points to forces they were never intended for, but this is still a failure I have not seen from other servos. On early robots I avoided this failure mode entirely by ignoring or removing the mounting points and simply gluing the servo case to the structure of the robot. I am now trying to avoid any king of adhesive or epoxy on load-bearing joints, and want to have every part of the robot easily replaceable in the field, so I am no longer gluing servos in place.

I have found that the mounting ears are less likely to break if I use oversize rubber grommets and proper mounting ferrules on all four mounting screws, and make sure all screws are securely tightened and treated with a thread-locking compound to prevent them vibrating loose. Even so the TowerPro servos are noticeably weaker here than other servos I’ve tried. I have on an emergency basis held servos with broken tabs in place with tape and zip-ties, but that is obviously not a method I want to rely on.

Ideally, I would like to replace the entire upper case of the servo with one that has stronger mounting tabs and intermediate shaft locating wells. Replacing the upper case with that from a Hitec HS-5645MG is not acceptable, as aside from the price difference the gear spacing between the two is off just enough for the gears to lock up with the Hitec upper case. It has been suggested that I could cast my own cases from aluminum or bronze. Aside from having no experience with metal casting, I live in a condominium and don’t have a suitable work space for metal casting. I have also been considering having new cases made by a rapid prototyping shop, provided I can have it done at a reasonable price. There is also the possibility of having metal sheets waterjet cut and inserted into the existing servo case to provide reinforcement, similar to my current hack but more consistently made.

4. Unreliable potentiometer

The MG995 appears to have a cheap potentiometer that wears out quickly. Admittedly, this flaw is based more on speculation and secondhand reports than direct evidence, as I have not opened up any MG995 potentiometers to personally measure the thickness of the resistive element or measured how they degrade over time. The assessment of poor quality is based partially on secondhand reports from people who have used these in more conventional applications such as RC aircraft as well as my own observation of poor position control that degrades over time.

Of course, the potentiometers in the MG995 suffers from the same deficiencies as any potentiometer-based position feedback. It has a limited arc of travel, is not capable of 360 degree position sensing, and is dependant on a sliding contact that inevitably wears down and can be contaminated by surface oxidation or debris. Also, as a purely mechanical observation, the Towerpro potentiometer is held in its well with an off-center screw which can cause the servo to bind if not tightened with just the right amount of torque.

Although I could probably live with the potentiometer as it is for my purposes, it would be an interesting project to replace it with a noncontact magnetic rotation sensor such as the Asashi EM-3242. These are fairly inexpensive (under $5 each) and take up a comparable amount of space to the original potentiometer (6 pin SOIC package, plus a small magnet). It would require making my own controller board, but that is something I was considering anyway. This would provide position feedback with no increasing inaccuracy due to wear over time as well as give me the ability to have full 360 degree motion of the output shaft. There are a few interesting robot designs I can pursue where a 360 degree movement would be useful.

5. Motor can't survive 8.4V

The MG995 is rated for a maximum of 6.0V. A two-cell LiPoly pack provides 8.4V when fully charged. Many 6.0V rated servos, such as the Hitec digital servos, will run at 8.4V for quite some time, just getting a bit hotter than they would normally. The control board of the MG995 seems to handle 8.4V, but the motors rapidly fail. I have not yet cut any of the failed motors open to identify the exact cause of the failure as these motors are designed to be opened nondestructively, so I do not know if the cause of the failure is in the brushes or commutator or wiring or elsewhere.

I have on some of my servos replaced the motor and control board with that from a similar Hitec servo, but this is obviously not a cost-effective modification. I would like to find a way to work with the existing motors for cost reasons. One obvious option is to use a commercial voltage regulator, either a hobby model designed specifically for this purpose or a scratch-built high-current switching regulator. If I am building and programming my own control boards I might be able to prevent motor failure by placing a limit on the PWM duty cycle to the motor FETs and/or monitoring the drive current and motor back EMF so that the motor is effectively only ever being subjected to 6.0V even if the input voltage is 8.4V. I’m not sure if that will actually work yet.

6. Limited communication method

The MG995, like nearly all hobby servos, uses the standard pulse code modulation system to transmit position control commands. This communications scheme, inherited from truly ancient analog control circuits in the earliest RC toys, has quite a few deficiencies. It can only send one type of information, position commands over a fixed range of angles at a fixed update rate. It requires a separate control line for each servo, requiring me to use a servo control board to translate the serial data stream from the radio into individual servo lines. It can’t return any data back from the servo, not even a basic ‘servo plugged in and working’ indication. Now it is true that most digital servos have a secondary digital communications mode which addresses some of these (the MG995, although digital, does not), and many of the newer servos designed specifically for robots dispense with the old PCM system entirely and use an addressed bidirectional data bus for communication. I approve of this trend, although those robot-specific servos are beyond my budget.

If I am replacing the control boards in these servos with custom-designed ones, I will design them to use a bidirectional addressed data scheme. This will allow me to dispense with the servo controller board, and return telemetry from each servo giving actual shaft position, current draw, temperature, fault indications, and other data such as I will think of.

7. Geartrain - not actually a deficiency!

The gear train in the MG995 is in my experience surprisingly robust, at least as compared with other servos I have tried. I have never seen gear teeth strip in a MG995, while stripped teeth happen with disturbing regularity in the Hitec servos I’ve tried. The Towerpro servo gears are thicker and appear to be more robust than the Hitec gears, which surprised me considering how nearly every other part of the servo was inferior.

I have seen the Towerpro servo gears fail in an odd and unique way, something I’ve never seen or heard of in other servos. Many of the gears are two-part, having a small steel pinion pressed into a larger brass gear. I have seen on a few servos the steel pinion pop out of the larger gear, accompanied by twisting or warping of the brass where the pinion was pressed in to it. This may be due to a manufacturing defect, with the smaller gear not properly pressed into the larger, but I suspect that gear misalignment due to the plastic case failing and letting the intermediate shaft wander out of position may contribute to the failure. Oddly enough, the gears which have failed this way still work if I manually press the loose pinion back into the main gear - the connection between them is not stripped, just not held together anymore.

I don’t intend to change the gears of these servos, they seem to be the one redeeming factor in an otherwise very cheaply made servo. Even if these turn out to strip as often as those in the HiTec servos after I’ve rebuilt the rest of the servo, an entire new MG995 is cheaper than just a replacement gear set for a Hitec HS-5645MG.

Our list of modifications is shaping up as follows:

New controller board with bidirectional serial data control and a better-tuned position feedback loop. Ideally, incorporating temperature and current sensing as well, and able to send telemetry back to the main control system.

Noncontact magnetic position sensing. Ideally, the magnetic position sensor would be mounted directly to the main PCB, provided this can be made to fit in the available space.

Structural improvements. The upper case needs to be stronger, both in the mounting tabs and the locating wells for the intermediate shafts. It is to be determined how I will do this.

You may look at this list of issues and ask why I’m bothering trying to work with these cheap little pieces of junk. To which I will repeat: $10 metal-gear ball-bearing digital servo with impressive speed and torque. The question to be determined is if I can make a reliable servo out of these and still have spend less than I would on a higher-end servo.

For those who wanted one

2010-05-20T18:07:00.000-07:00

I have these available now for $75, shipping included, via Paypal. Email me at ellindsey@gmail.com for details.

An experimental servo modification holds up for the Steampunk World's Faire

2010-05-17T17:09:00.000-07:00

After the gears, the next weak spot in the HX-12K servos is the case. I cracked several mounting tabs at GenCon last year. That problem seems to have gone away once I switched to larger rubber grommets around the mounting screws, and made sure all four screws were evenly tightened to spread the load. One servo cracked where I had installed a rear hinge point on the case, but that appears to have been an isolated case, probably due to assembly error on my part.

The main failure point now is the mounting of the axle shafts inside the gearbox. The gearbox main shaft is mounted by two ball bearings. I've yet to see that fail. The smaller hears inside the gearbox are located by two smaller shafts, which fit into plastic pockets in the gearbox housing. More expensive servos have brass bushings or even small ball bearings for the intermediate gear shafts, but the HX-12K and even the more expensive HS-5645MG servos have bare plastic there. I have seen on many servos, the HX-12K in particular, these mounting holes widened and even gouged out, allowing the middle gear in the servo to wobble back and forth. This lead to the geartrain coming unmeshed, locking solid, or even in one case a gear wandering into the side of the gearbox housing and gouging grooves in it.

As an experiment I took a few servo cases that were already trashed this way and carefully shaved out all remains of shaft mounting on the inside of the case. Then after carefully measuring an intact servo, I drilled and cut some .020 steel sheet to make locating plates to hold the top ends of the two intermediate shafts. Cutting and drilling by hand, it took several tries to make the locating plate precise enough for the gears to mesh properly and for the servo to run smoothly when reassembled. When the first servo I modified this way ran well during testing, I modified three more.

All four of the outer leg servos on the robot, the ones which raise and lower the leg segments, are now heavily modified hybrid models, having motors and control boards from HS-5645MG servos, the gears from HX-12K servos, and HX-12K cases modified with rear axle points and steel plates locating the intermediate gear shafts. The inner servos, which move the legs horizontally, don't seem to fail nearly as often, so I haven't modified them as much yet.

Pendants are coming along, and mix-and-match servos

2010-03-28T18:10:00.000-07:00

I have five more of the LED uranium-ball ring-circuit pendants finished and ready for sale. While my eventual goal is to have a dozen or so ready for the steampunk world's faire, I am aware that I had a backlog of people wanting theirs. Contact me if you were one of those.

I've been running the robot with HS-5645MG servos lately. I'm not happy with them. While they don't have the terrible problems with ringing and overshoot that the HX-12K servos had, they do have a weak gearbox design. The second-to-last gear in the gear chain is surprisingly thin. I've lost track of how many gears I've seen break on these servos, always in the exact same spot. The HX-12K servos had a much thicker gear in that same position, and I've never seen one fail that way. HX-12K servo failures I've seen tend to be electrical board or motor failures, or structural failures in the servo case.

I am experimenting with building a composite servos using the motors, potentiometers, and drive boards from the HS-5645MG servos and the gear train from the HX-12K servos. They have nearly the same gear ratio, and appear to have the same spacing between gears and same size shafting. There are some odd clearance issues. The HX-12K gears jam when installed in the HS-5645MG cases, although the HS-5645MG gears run fine in the HX-12K cases. I have installed the motors, drive boards, and potentiometer from a HS-5645MG in a HX-12K case with the HX-12K geartrain. The potentiometer is a tight fit and doesn't turn smoothly if I tighten the case screws tightly, but other than that the arrangement works.

The weak link is still the HX-12K case. The mounting tabs break off, the case itself cracks, and I've seen a few cases of total failure of the mounting boss for the small internal shafts inside the gearbox. Making my own cases from cast aluminum is out of the question in the condo, and having cases custom-machined would be unreasonably expensive. If I had that kind of budget, I would just buy higher-quality servos in the first place. Still looking for other options.

Exhibition at Wicked Faire

2010-02-21T07:02:00.000-08:00

Yesterday I took the walking robot to the Wicked Winter Renaissance Faire to show off and entertain with. The trip was quite successful, with many fairgoers entertained. Unfortunately the problems I've been having with the HS5645MG gearboxes resurfaced. In this version I was running with hybrid servos containing the electronics, motors, and gears from HS5645MG servos installed in HX12K servo cases. HX12K cases were used simply because the ones I had were already fitted to the robot frame, and because I didn't have enough intact HS5645MG servo cases. HS5645MG servo innards were use because the HX12K servos had terrible position control and easily burned out motors.

Over the course of the day I had two gear failures. Both of them were identical to the failure I've seen before, with the second-to-last (counting from the motor) gear in the gear train losing teeth. This gear is surprisingly thin for the torque it's carrying. The same gear in the HX12K servo is significantly thicker, and in my robot has never failed.

I had spare gear sets on hand and was able to repair the damage and keep the robot going, but this is an unacceptable and expensive failure rate. I believe it may be possible to construct a hybrid servo using the gears from the HX12K and the motor and control board from the HS5645MG, which if it worked would give me the solid position control of the HS5645MG and the durability of the HX12K. Once the weather improves I will start working on that.

The other failure, which stopped my showing off the robot for the night, was when the antenna broke off the transmitter. The wire antenna that can come attached to the XBee radio module is made out of some very cheap and brittle coarse-stranded wire. I had long ago replaced the wire antenna on the receiver with a length of ultra-flexible wet noodle wire. Now I'll be doing the same with the transmitter.

I sold a few of the Uranium Ring Oscillator Pendants I've made at the faire, and had enough interest from people in them that I've set up an Etsy account. There's nothing much there now, but when I have some more jewelry made I'll be posting it there.

Walking again for the holidays

2009-12-28T09:05:00.000-08:00

For demonstrations at various parties and family gatherings over the holidays I have rebuilt the walking robot. The issues which arose with the robot over the summer appeared to be due to the unsatisfactory reliability and poor accuracy of the cheap HX12K / MG995 servos. The combination of the higher than recommended voltage and amble gait was too much for the motors, which were failing frequently, but what was most unacceptable was the terrible servo feedback loops which made the entire robot shake uncontrollably when trying to hold a leg in the air.

I can't afford to buy 8 new higher-quality servos at the moment, and most of the choices of servos designed for operation above 6 volts would require significant redesign of the entire robot. I did have on hand the 8 HS5645MG servos used on the previous version of the robot. I had stopped using them because of the high rate of gearbox failure in that design, but the electrical and structural failure rate of the HX12K servos was a lot worse. I had also cut the mounting flanges off all those servos as on the previous version I was epoxying the servos to the robot structure.

The new chassis needs servos to be mounted by their mounting tabs, so I couldn't use the old servos as-is. Here I was in luck. Dissassembly and comparison of the HS5645MG and HX12K reveals them to be suspiciously similar internally. The HX12K / MG995 appears to be basically a cheap knockoff version of the HS5645MG, similar enough that I was able to take the electrical and mechanical guts of the HS5645MG and install them inside a HX12K case. I haven't figured out a way to use the HX12K gear train with the HS5645MG electronics and motor yet, so I'm still using the more fragile HS5645MG gears. The gears have the same pitch diameters and axles, which lets me install the gears from one servo in the case of another, but the tooth count is different so I can't mix build a hybrid gear train from both.

The HX12K does have somewhat flimsy mounting tabs, several of which failed at GenCon. For the rebuild I dug through my junkbox and found the largest rubber grommets and ferrules I had, in an attempt to spread the load out as much as possible. This is admittedly a temporary solution. I am still looking into ways to reinforce the servo cases where they mount to the frame.

One surprise when wiring up and testing everything is that the HX12K and HS5645MG seem to have the opposite direction of movement in response to servo commands. When adjusting the mixing logic and pre-programmed poses in the controller I'm having to change signs and invert position settings throughout the code. Although it's possible this is the result of something I did when rebuilding the servos and robot - I might have accidentally reversed the connections between servos on the left and right sides of the robot or something.

At the moment the robot seems to be working well, and held up for several days with family and friends through the holidays. I haven't stripped any more gears yet, but it remains to be seen if this is just a matter of time, or if the shock absorbers and other structural design improvements are actually making a difference.

Shiny uranium bauble

2009-10-31T13:54:00.000-07:00

My project for this weekend was to build a little decorative bauble, a piece of electronic jewelry. Seven high-brightness UV leds driven by a ring oscillator circuit arranged around a uranium-glass marble. You can see a few pictures of it here.

Some of you may recognize this as being similar to the power indicator on my walking robot. The difference with this piece, other than being stand-alone, is that the LEDs are made to flash sequentially rather than being on all the time. It makes it a lot more eye-catching.

Several of my friends are encouraging me to make and sell these as steampunk jewelry. That might end up being the only way I can afford new servos for the robot.

Looking for servos...

2009-10-30T08:08:00.000-07:00

The 2009 version of my walking robot was in part a test of the feasibility of using the cheap MG995 servo in a walking robot. I expected that even if these cheap servos didn't last long their cheapness meant replacing them wouldn't be unreasonably expensive. These servos lasted long enough in practice (although when they failed the failure mode what not what I expected) but their terrible position-holding ability made them unacceptable for what I'm trying to do. So the MG995 servos have to go.

I'm currently rebuilding the robot with some HS-5645 servos I have on hand, but I don't expect those to last long. One already has a stripped gear set, and the others don't look they have much life left in them.

I need new servos. Preferably metal-geared servos with motors rated for 7.4V lithium battery use. Unfortunately I'm also on a very tight budget for robots at the moment. My wife will only approve buying expensive servos if I can guarentee they will never fail, and who can guarentee that?

There's the HSR-8498HB. The low-end 7.4V robot servo from HiTec. Not cheap at $60, and a little less torque than the HS-5645MG. It has Karbonite gears, whose durability I would be very concerned about. The HSR-5498SG has steel gears, better torque, and is only slightly more expensive at $70. Both these servos are available with a rear axle point built into the case, which would remove the need for me to modify the case that way. On the downside these do not use the standard servo mounting points, which means they would not be useable with the current waterjet frame pieces. Although since all the strucural failures I had were at the standard mounting points, redesigning the servo-to-frame attachment method might be a good idea.

There's the $60 HDS-2288. Metal gears, rated for 7.4V, nice torque, uses standard servo mounting points. I'm not sure if they're actually available with any reliability, they seem to be sold out or on backorder everywhere.

The $20 Associated SHV1504MG has metal gears and is rated for 7.4V, and uses a standard servo case, but is terribly underpowered for this requirement.

Then Dynamixel servos. These look really interesting, having some amazing features way beyond normal servos in how they can be configured and what kind of feedback data you can get back from them. These don't use the standard servo control pulses at all, but instead have an addressed serial bus scheme, which I should be able to connect straight to the serial ports on the Xbee radio. I could use this to feed back voltage and temperature indications to the controller, maybe even translate joint torque into force-feedback somehow. Very interesting possibilities. And all these servos will run at 7.4V. They're actually designed for 9.6V, so 7.4V is a little on the low side but still within the rated voltage range.

On the down side most of the Dynamixel servos are completely outside my price range. The $45 AX-12 servo I could probably afford, but those have plastic gears which I'd prefer to avoid. The Dynamixel servos also would require a complete strucural redesign to use. That might be a plus after all, the AX-12 servos are far better suited to robotics from a strucural point of view than are standard hobby servos.

The last option would be to just make some frankenstein hack from my current servos, homemade die-cast cases, openservo boards, and rewound motors. Considering that as a backup plan.

LiPolys and servos

2009-08-20T17:26:00.000-07:00

Lithium-polymer batteries are inconvenient. They're physically fragile, awkwardly shaped (at least for fitting in cylindrical or spherical compartments), prone to turning into fireworks if mistreated, and have a nominal cell voltage of 3.7V. I can work around the shape and fragility, and installed a battery protection board to keep the cell from igniting, but the cell voltage is a real problem. Most cheaply and easily available servos are designed to operate at 4.8V or 6V, running off a 4 or 5 cell NiCad pack. One LiPoly cell is too low-voltage to run servos from, and two will deliver 7.4V nominal, and up to 8V when freshly charged.

I can't afford to use the high-end robot servos designed for 7.4V, but I also can't ignore the fact that LiPoly cells deliver three times the energy density of NiCads. So since 2007 I've been ignoring the manufacturer recommendations and running normal hobby servos off two-cell LiPOly packs. It's worked, mostly, and I think I'll keep doing it.

Looking at the components inside a typical digital servo does not reveal any obvious voltage limitation that would prevent operation over 6V. The components which limit the voltage at which the control circuit can operate are the motor drive FETs and the 3.3V voltage regulator for the microcontroller. The FETs in the MG-5645 servos have a breakdown voltage rating of 20V, which even assuming 2X overvoltage from EMF spikes should run safely off a 9.6V pack. The 3.3V regulator I can't find a datasheet for yet, but typically should have a maximum input voltage of at least 12V. Nothing on the PCB itself should fail to work at 7.4V.

The actual voltage limit seems to be in the servo motor. According to HiTec, the motor in their standard digital servos is limited to 6V. Now, back from my old robot combat days, I learned a lot about how much you could safely overvoltage motors, and just what caused them to fail when pushed to hard. Voltage alone does not destroy a motor. Armature windings can come apart from spinning the motor too fast, magnets demagnetized from too much current and heat, and too much load for too much time without enough cooling can cause the solder joints to simply melt, but voltage alone doesn't fry a motor. The actual point at which a motor will self-destruct is complicated and depends a lot on the gear ratio, actual load on the shaft, and thermal conditions.

It's probable that 6V is the point where these servos are rated for steady operation without failure. Pushing them past that increases the rate of failure, but the actual failure rate is also dependent on a lot of other factors including the quality of construction, load, and duty cycle. Running the MG-5645 servos at 7.4V, I had no failures of the motors or control boards, although I did break a lot of gear sets. The motors did get pretty hot after a few minutes of walking, but I didn't have any actually fail. With the HX12K servos I had two motors simply die, unsurprising considering their cheap construction. The MG996 servos will probably work no better at 7.4V. I may rebuild the robot with MG-5645 servos after all, since they seem to tolerate some degree of overvolting.

Post GenCon report!

2009-08-19T18:29:00.000-07:00

The robot ran at GenCon, getting in about half a dozen full charge cycles in over about three days before it was past the point where I could keep it going. Ultimately while it did succeed at the goal of entertaining others and myself, the performance and reliability weren't quite what I had hoped.

As I'd expected, all the reliability problems were with the servos. Unexpectedly, I didn't have a single gear failure. No stripped or broken teeth on any of the gears, and even the issue with the press-fit third gear coming apart that I'd seen early on one servo during testing didn't come up. I did have failure of the mounting tabs on three of the servos. The plastic web where the servo mounting tabs meet the cases is very thin on these servos. These mounting tabs can take the loads created by the servo torque, but the bending and twisting forces induced by the way all the forces from each leg are transmitted through the servo mounts appear to be more than they can take. I had servo mounting tabs break off on three servos, and so far have found cracks in the case of one more servo.

I also had motor failures in two servos. In both cases while walking the robot suddenly lost all power, apparently due to the overcurrent trip on the battery protector board. In both cases once power was cycled one of the servos no longer functioned, not even in the passive motor-braking mode the servos default to on powerup. I had thought it due to controller board failures, but on disassembly and testing found both motors had failed open. I haven't taken apart the motors to find out while they failed yet, but I suspect heat-induced failure of the connections to the brushes, or the brush holders or springs.

I had expected these servos to have a high failure rate, and designed the robot for easy access to the servos, so even with the high failure rate of these servos I was able to keep the robot working until I ran out of unbroken servo cases. I wasn't happy about having to repair the robot as often as I was having to recharge it's batteries, but I wasn't completely surprised.

The bigger problem was the poor control I had over the robot's motion. The lifelike movements people like about the robot, and the ability to make fins and subtle movements to interact with the crowd, depends on the servos closely matching the movement of the joysticks. On that this version of the robot failed. First of all, the precision of the HX12K servos is utter crap. There's a huge amount of play in the geartrain, which combined with a badly tuned control loop in the servo control board means that the position signal you're sending to the servo is going to be treated as at most a rough suggestion as to the position you'd like the servo to hold. There's a huge amount of overshoot and ringing, the robot's legs wandering and shaking randomly even when sent a steady position signal. Standing still with all four legs on the ground the robot would be stable, but it would shake uncontrollably when holding a leg in the air, and walking was jerky and unsteady. It was a goods thing thing that the ability to invert the legs and walk either side up was always a crowd favorite, because the robot would frequently fall over while walking.

The other problem was that the radio link, which worked fine at home, was unreliable in a convention hall full of cell phones and other electronics. Control was unpredictable - sometimes it would work fine at up to 30 feet, sometimes it would intermittently lock up at less than 5 feet.

I'm also not happy with the Wii Nunchuk joysticks. I just don't get the same fine-control ability as I had with the RC airplane radio set I used to use.

The radio range issue can be easily corrected. At the moment I'm using the 1mW version of the XBee radios. The Pro version of the XBee radio has a transmitter power of 60mW. More power might be the brute force solution of the problem, but that's fine with me. I also have some ideas for rebuilding the controllers with better joysticks stripped out of an old RC airplane set.

The control issues with the servos I can't do anything about without replacing them. Poor position-holding seems to be an unsolvable issue with the MG995/HX12K servo. I suspect that even if I transplanted the control boards from the HS-5645MG servos in my junk box the insane amount of play in the geartrain would prevent them from being accurate enough for my needs.

Some of the more astute of you might wonder, if I've got nice high-quality Hs-5645MG servos in my junk box, why am I wasting my time with cheap import crap like the HX12K? It's because the HS-5645MG gearboxes kept failing. The HX12K servos, for all their faults, at least have bulletproof gears. I may try rebuilding the robot with my old HS-5645MG servos anyway - the spring shock absorbers I built into this version of the robot's legs may be enough to save the gears from failing. There is also a new servo out, the TowerPro MG996, which is an upgraded version of the MG995/HX12K servo with better accuracy and reliability, which I might buy and try out eventually. For the time being my budget is shot and my wife's patience with robots that break after a minute of walking is expended, so buying any new servos will have to wait.

Servo failures

2009-08-13T19:22:00.000-07:00

I had another servo failure today, after a lot of walking around and showing the robot off. I'm seeing an interesting pattern. It's always the two servos which move the rear legs horizontally which fail. These seem to be under the most strain, being the servos responsible for most of the forward/upward movement of the robot with each step. Surprisingly enough, the gears are not failing at all. The cases are. The mounting tabs which connect the servos to the robot chassis have cracked on two servos now. I am also seeing failure of the case at the point where the gear shafts are held in place. Over time the shafts wear away the plastic until the shafts can wobble enough for the gears to jam or come unmeshed.

I have seem this type of failure before. Now that the problems with stripped gears appear to be solved it seems the plastic servo case is the next weak link. I have some ideas for reinforcing the servos but the machining involved may beyond the capabilities of my workshop.

Update - day 1 of GenCon

2009-08-12T17:42:00.003-07:00

Walked the robot around at the GenCon Stink for a while until one of the servos suddenly stopped working. Gears are intact. Seems to be a dead control board, although nothing is obviously burned out. Swapped the servo and the robot is walking again. Also one slightly cracked servo case and one loose servo horn screw, both easily fixed.

Radio range seems to be a lot shorter than at home. I blame the large number of cell phones. Must invest in higher power transmitter module after convention.

Design goals for 2009 walker:

2009-08-07T11:43:00.000-07:00

1. No structural joints made with glue or epoxy.

The first walking robot I made wasn't much more than servos, a battery pack and a radio receiver held together with silicone glue. That worked well enough as those robots were too feeble and lightweight to need much structural strength. Later, as I went to stronger servos, heavier batteries, and more rigid structure I experimented with various epoxies. To keep the weight down, I wanted to use the servo cases and batteries themselves as structural elements, which meant ignoring the intended mounting tabs and epoxying directly to the servos.

The glue and epoxy kept failing. In the end I had the best luck with cyanoacrylate superglues, but even those didn't hold reliably. And when I started showing the robot at conventions, gluing everything together had a second downside in making it much harder to easily replace broken parts. The final straw was when I switched from the hefty NiCad cells I had been using to LiPoly packs with minimal structural strength. When I needed to add a steel frame to take the place of the batteries that had previously made up the structural core, there wasn't much point in using glue rather than screws to attach to the servos.

When I set out to completely redesign the structure on the latest rebuild, I set a solid rule. No glued or epoxied structural joints. Everything structural would either be fastened with machine screws (if meant to be disassembled), or welded or soldered (if meant to be permanent).

I did end up having to use superglue to attach weld nuts (used to provide a second hinge point on each servo joint) to the inside of the servo cases. The glue is only needed to hold the nuts in place during assembly, as the screw which holds the hinge pin in place also holds the servo nut from coming loose. I also had to use gaffer's tape and zip-ties in a few spots to hold wires in place. Not an elegant solution, but acceptable for non-structural parts.

2. No purely decorative components

I've made the mistake in the past of loading decorative bodywork and cosmetic detailing on convention robots. On the 2006 version of the robot I built up complex anodized titanium bodywork around the servos and joints, with rubber tubing covering the servo and battery wires and thick aluminum tubes for the legs and central chassis. The result - excess weight, stiffness and interference in the joints, for bodywork and cable sheaths that the robot would work better without. That version walked about ten seconds before stripping a gearbox.

Faster battery drain and more frequent gear replacement made for less time walking the robot around and having fun. Having a robot that works reliably for a long time had to be my first priority. My second strict rule on this redesign was to have nothing on the robot which didn't in some way help the performance or reliability of the robot. This didn't mean no cosmetic details. It meant making those functional parts of the robot cosmetically interesting so I wouldn't have to add completely useless cosmetic parts. I was also willing to stretch my definition of what counted as a justifiable functional purpose. For example, the copper body shell technically serves the purpose of holding wiring in place out of the way of the legs, so that counts.

3. Easy to maintain

I've tried, and failed, to design the robot such that nothing breaks over the course of a busy weekend. Instead I've designed the current version for easy maintenance. Those parts which I carry spares for can be easily removed and replaced without having to break or cut anything. The servo gears which are the most frequently failing point can be replaced without even having to remove the servos from the robot.

Those parts which I don't have spares for can still be either removed for troubleshooting, or at least easily accessed by removing any bodywork and components around them. I don't at the moment have spares for the radio, the battery, the servo-control board, or many of the other internal components, but I can get to and troubleshoot all those parts in place easily. Having a thin waterjet-cut steel frame supporting an easily removable outer shell versus the closed-box structure on some previous designs makes maintenance a lot easier.

4. Safe for human contact

This robot is meant to be shown off at conventions, walking up to people, shaking hands, and even being picked up and handled. It needs to be able to do all this without injuring anyone. No sharp points or edges. I designed it with spherical and cylindrical body sections, and rounded feet rather than points. The antenna had to stick out somewhat, but I replaced the stiff wire antenna that came with the radio gear with a length of super-flexible wet-noodle wire.

It also means I had to try to avoid pinch points. The servos I'm using now have amazing torque, enough that a finger in the wrong place could be crushed if the robot moved while being held. Although the XBee radios are pretty good about rejecting bad data, I didn't want to rely on the control system to prevent any of the servos from moving at the wrong time. This robot is designed with large openings around the joints, with rounded edges on all the metal surfaces facing openings. This also helps with reliability - wide open joints with lots of clearance are a lot less likely to bind or jam, and make it easier to reach in and work on mechanical bits without taking the entire joint apart.

On feet.

2009-08-06T05:54:00.000-07:00

A lot of people ask me, mostly after seeing the robot slipping when trying to walk on smooth tile floors, wouldn't it work better with rubber pads on the feet? The answer has to do with how the robot walks and the kind of materials it's optimized for.

The little walking robot walks by moving its legs in diagonally opposed pairs, where at any time two legs are moving forwards and two are moving backwards. In theory, the two legs moving forwards are off the ground with only the two backwards-moving legs pushing against the ground. In practice, the robot makes no attempt to balance on two legs, so the reality is that while walking one leg will be raised, two will be pushing backwards against the ground, and one will be sliding forwards along the ground. The robot doesn't so much walk as flail at the ground and push itself forwards. It's cheesy, but it works.

Very early versions of the robot had big fat rubber pads for feet. These versions walked fairly well on smooth hard floors, although with a high current draw, but would bog down and get stuck on carpet. The effort to drag the rubber feet across carpet was too much for the weaker servos I was using back then. It wasn't until I tried covering the feet with electrical tape to make them more slippery that the robot was able to walk across carpet well. Traction, as it turned out, was less important than the ability to smoothly and freely move the feet, at least when moving across carpet or other high-friction materials.

The tape-covered rubber pads worked, but were an ugly solution and wore out quickly. I replaced them with hard nylon spheres. These were nearly optimal for walking on carpet, but a second problem arose. The nylon-geared servos broke developed an alarmingly high failure rate. The rubber feet had been cushioning the impacts from walking, and with hard feet I was averaging one blown servo for every ten minutes of walking. I switched to metal-geared servos, which helped but did not eliminate the problem. The latest version has spring-cushioned telescoping shock absorbers in the legs, which seems to be helping with servo reliability.

The optimal foot design depends on the surface walked on. My robot is meant for walking around convention halls, where carpeting is the most common surface. Trial and error has shown me that hard smooth feet work best with the sliding gait the robot uses. It does mean it slips a bit on hard smooth floor, and is especially hard to control when partly on carpet and partly on a hard surface.

FAQ

2009-08-05T17:00:00.000-07:00

What is it?

A walking machine, radially symmetrical, having four legs with two degrees of freedom each, controlled through a wireless link from a hand-held controller based on two Wii Nunchucks.

What's it for?

Amusement and entertainment. Mine, and that of people at parties and conventions which I bring it to. I make no pretense of any practical use of the robot, but it seems to draw a crowd and entertain. The robot also serves as an excuse for me to learn new skills in crafts and robotics, an excuse for me to experiment with microcontrollers, radio gear, metal etching and polishing, leatherworking, welding, and other such.

Is this something you bought or made from a kit?

This robot was designed and built from scratch. I am using quite a few off-the-shelf parts, including the servos, radio gear, and electronics boards, but the overall design is original and not based on any robot kit or toy.

How long did this take to make?

That’s hard to say. Building an entertaining little walking robot has been a hobby of mine for years. This particular robot has been a two-year project, starting shortly after GenCon 2007, worked on intermittently on spare weekends and evenings. It started with what was originally intended as an upgrade and repair of an earlier robot that then turned into a rebuild nearly from scratch. That robot was in turn based on an even earlier (and much less successful) robot I had in 2006, and so on. The earliest version of this quadruped design was built nearly a decade ago. It barely worked, but was enough fun for me to keep playing around with.

If I had to rebuild this bot from parts and raw materials, I could probably do it in a few weekends, but that of course would not include the time spent on research and design.

How much did it cost?

On this version of the robot, I estimate I’ve spend about a thousand dollars. Some of that was spent on parts that never ended up being used or broke and had to be replaced. On the other had the bot also includes some materials recycled from junk and scrapyards, so the actual cost to reproduce it from scratch is hard to estimate.

Why did you make it?

Many years ago I used to compete in robot combat competitions. Robot Wars (when it was in the US), BattleBots, Robotica, and various other local events. The RC airplane radio sets I used always came with a handful of little hobby servos. Meant for RC airplane use, they were too small and weak for combat robots. One bored day I took a look at the small pile of spare servos in my junk box and decided to do something fun with them. The end result didn’t walk very well or for very long, but was fun enough for me to continue refining the idea.

Years later I upgraded the design with better servos and higher capacity batteries, ending up with something that could actually walk well for more than a minute. I was by this time getting bored with the robot, but decided at the last minute to bring it along on a trip to GenCon. I had great fun walking the robot around the competition and entertaining people, although by the end of the convention the bot was pretty much trashed. Since then I’ve been working to improve the reliability and battery life, as well as the expressiveness and crowd-friendliness of the robot.

Are you making robots like this for sale?

I’ve considered it, but I do not have any plans to do so at this time. This robot is a hand-made piece of mechanical art, which I am constantly tinkering with and improving. I am not confident in the reliability of this design yet, and for what I would need to charge for my time to build it and the parts and materials I would not feel right selling anything but an absolutely finished and reliable machine. If I was mass-producing these by the thousand with injection-molded plastic parts and assembly by sweatshops in China I could sell these at a reasonable price, but I have neither the interest nor the startup money to pursue that path.

I have been working on making electronic jewelry with similar design themes which I may be selling on a limited basis in the future. I could also probably be persuaded to do custom work on commission. I don’t intend to offer standard pre-made robot kits of this design.

What's it made from?

The primary chassis of the robot is made from a single piece of waterjet-cut steel plate from Big Blue Saw. I was originally reluctant to order parts made for the robot as I wanted as much of it as possible to be hand-made, but having parts custom-cut turned out to be a very good idea. I was able to get some very complex and organic pieces of metal made with great precision, which eliminated issues with servo alignment in previous versions. The steel frame also takes up very little of the limited internal space in the robot, yet provides secure mounting points for the servos, bodywork, battery, and other internal parts.

The shell of the main body was made from a three inch diameter copper tank float. Spherical because I wanted to go with a rounded, organic-feeling design, and copper because I was aiming for a sort of steampunk theme, with hand-cut openings for the legs. Outward from that are the four leg midsection pieces which were also hand-cut from 2 inch diameter aluminum tube. The outer segment of each leg has another waterjet-cut steel piece, with a welded steel tube housing a spring-loaded telescoping ankle segment in the end. The feet are brass knobs, into which the shoulder screws which make up the mobile part of the telescoping section screw into.

The electronics of the robot are fairly simple. For me this project was always about mechanical design and packaging, with control electronics a secondary concern. The robot runs off a 7.4V 1100mAh LiPoly battery. I use a pair of XBee radio modules for communication. A Pololu micro SSC board receives a serial data stream from the transmitter via the XBee radios and generates the control pulses for eight HX12K servos.

What's the glowey thing on the front?

The power indicator. It tells me the main power is on and shows which side of the robot is the front. It is made from a 5/8 inch uranium-glass marble held in a copper wire cage, surrounded by six high-power ultraviolet LEDs. The UV light from the LEDs makes the uranium-glass marble glow a nifty green color when the main power switch is on.

A rule I set for myself on this robot was that it would have no purely decorative parts. Functional parts could also be made decorative so long as their function was not impaired. Showing that the power is on and indicating which way is the front is to me more than enough function to justify a glowing marble and LED array.

How long does the battery last?

I’m really not sure. I’ve never run the robot non-stop from full power to battery exhaustion. I originally estimated half an hour of total run time, but that might have been an overly optimistic estimation.

Is that a Wii Nunchuck?

Two, actually. Previous versions of this robot used a RC airplane radio set for control, but for this version I wanted something less obvious and more compact. Something I could hold in one hand and conceal easily. The Wii Nunchuck is a pretty cool option – you get a joystick, triple-axis accelerometer, two buttons, and a housing with some extra space for a battery and radio for a pretty low price. I originally planned to use a single Nunchuck, controlling the motion of the robot with the joystick and accelerometer-sensed hand gestures. Along the way I decided I wanted a second joystick after all, so I bought a second Nunchuck for two-handed control. I also didn’t quite manage to fit the microcontroller and radio into the housing of the first one cleanly. The controller is a bit of an ugly hack – I intend to improve it cosmetically in the future, but for now just having it work was the priority.

What kind of electronics are in there?

The left-hand Wii Nunchuck is mostly unmodified. It has a joystick, accelerometer, and a microcontroller which samples sensor data and communicates over a serial data line. It is taped together because I opened it up before deciding to leave it functionally unmodified.

The right-hand Wii Nunchuck has been gutted and rebuilt. I removed all of the internal electronics except for the joystick and buttons, and installed a FunnelIO Arduino board, accelerometer, LiPoly battery, and XBee radio module from sparkfun. The accelerometer, joystick, and buttons in that unit are tied to the analog and digital inputs on the FunnelIO. The serial lines from the other Wii are tied into the SDA/SCL serial port on the Arduino. I use the Wii Nunchuk communication code from Windmeadow Labs (www.windmeadow.com) to get the data from the left-hand Nunchuck.

The Arduino takes the data from the unmodified Nunchuck, the analog values from the joystick and accelerometer on the modified Nunchuk, does some math to determine servo positions, and transmits serial data at 38400bps through the XBee radio link to the Pololu serial servo controller board in the robot. There’s also a battery management board in the robot which shuts off the battery in undervoltage, overvoltage, or overcurrent conditions.

I did not make any custom PCBs for this design. Previous versions of the robot did have custom-made PCBs, but thanks to Sparkfun and Pololu I was able to build the entire control and power system with off-the-shelf boards.

How do you control it?

Control of the robot is through the joysticks on the two Wii Nunchucks. I have some plans for control schemes based on accelerometer data in addition to the joysticks, but I haven’t implemented them yet. I will be experimenting with that in the future.

The control scheme for the robot does not use any pre-programmed sequencing. That is, all the movement of the legs is based on the immediate position of the joysticks and the mixing mode selected, so that in order to make the robot walk I have to move the sticks back and forth with each step. I had in previous versions had pre-programmed sequences for walking, but decided that manual leg control resulted in more fluid, lifelike motion, as well as a lot of flexibility for posing and gesturing.

There are multiple mixing algorithms I can choose from by pressing different combinations of the buttons on the Wii Nunchucks, depending on what I want the robot to do. I can also press a button which inverts the movement on the up/down servos and swaps the left and right servo movements. Because the body is top/bottom and left/right symmetrical, this lets me reconfigure the robot to walk upside-down if it flips over. Which it does fairly frequently.

The robot has essentially no on-board processing, other than that required for error-checking and decoding the serial data stream from the hand controller.

What's the radio range?

Not very long – about 20 feet before control becomes intermittent. I am using the lowest-power version of the XBee radios. I may move to the higher-power version in the future, if I want better range, but for now I don’t like to have the robot that far from me while controlling it.

Is this based on a Dragoon from Starcraft?

No. I’ve never even played Starcraft. I didn’t even know what a Dragoon was until I went and looked it up after enough people asked me if I’d based this on that design.

So where did the design come from?

As mentioned above the first version was built as something fun to do with leftover hobby servos. I had eight servos, so a robot with four legs, two servos per leg, worked out well. I was also at the time considering the challenge of making a walking robot for competition use. Working with cheap and weak servos and not having the budget for elaborate balancing systems, I looked at turtles for design inspiration. Rigid body, not much need to balance, four short stubby legs – seemed like I could do that. I made it with radial symmetry to keep the design simple and make it able to walk in any direction. Being able to walk upside-down didn’t come till much later.

I never ended up adapting the design for any competition. Making it to be a free-form entertainment robot was more fun for me.

How much does it weigh?

2 lbs 10.9 oz, or just a bit over two and a half pounds.