Halloween project: A safe non-contact automated candy dispensing device.

    Our neighborhood never has a large number of trick-or-treaters, even on a normal year, but I do always make a point of having candy on hand for the dozen or so kids that we get. This year, I wasn't certain we would get any at all, and I wasn't sure I'd feel safe handing out candy face-to-face with them if any did come by. I had for a while been planning to just shut the outside lights off and lock the door, but decided, a few weeks before holiday, that I could hand out candy in a safe, no-contact way after all.

    I saw how some people were setting up delivery tubes for safe remote candy delivery. I had a cardboard shipping tube on hand that I could use for that, but I realized that I could do better than just dropping candy in by hand. I designed a carousel mechanism based around a FIT0441 blushless gearmotor, which would have compartments for up to 10 loads of candy.

About a 28 hour long print on my printer, one of the largest single pieces I've ever printed.

Room for 10 loads of candy, although one will always be empty due to being over the dispending hole.

    A microswitch acts as a position sensor, telling the motor when to stop after rotating to release the next load of candy. The carousel mechanism was mounted at the top of the tube, so that candy would slide down the tube after being released.

Quick assembly of the mechanism.

    To control the system, I used some old Arduino Pro Mini clone boards left over from another project a few years back. I ran into a significant problem with these, as the power supplies on the board failed, and in once case literally exploded, as I tried to run them off the 12VDC power supply I had on hand. The Arduino Pro Mini has an on-board power regulator which is supposed to handle a 12VDC input, but every one of these boards failed when powered at 12V. This was especially surprising as I had powered these exact same boards off this exact power supply when I first bought them a few years ago. I can only assume that they somehow degraded while in storage, but I'm still baffled. Perhaps this is just a lesson that I should be using actual Arduino boards rather than cheap clones.

    I eventually resorted to desoldering the failing power supplies from the boards, and using an external 5V regulator to power them instead. This worked with one of the three boards I had on hand, the other two seemed to be completely dead.

    At this point, it was getting fairly late on the day before Halloween, after spending a full day on getting the Arduino board to work, so the remaining wiring is a bit of a mess. Driving the motors was easy since the FIT0441 has a built-in motor control circuit. It has one wire for direction, and another which is used as a PWM speed control line. There's also a feedback line indicating motor rotation, but I didn't end up doing anything with that signal. Position control came from a big old microswitch out of my junk box which would be pressed to stop the motor after rotating.

Somewhat messy wiring in the final assembly, but it worked. The motor is driving the carousel through an inside ring gear built into the underside of the carousel. I made spaces for three motors, but only one was needed.

    I could at this point have made the device dispense candy with a button push, but I wanted it to be truly non-contact, not requiring either the visiting kids or myself to have to touch anything. I had on hand an IR emitter/detector assembly from a broken hands-free paper towel dispenser. This was fairly easy to hook up to the Arduino Mini. The IR receiver this module was using to sense reflected light was originally designed for TV remote control use, and was only sensitive to light pulsed at 38khz. Getting the Arduino to output a 38khz signal requires my directly writing to the timer 2 registers, as there doesn't seem to be any clean way that I could find through the Arduino libraries. Once I figured out how to do that, it was easy to get the proximity detector to sense when someone was holding their hands, or a bag or basket, under the end of the tube.

Downward-facing IR LEDs and sensor on the board at the bottom. Big red LED at top.

    As a final touch, I added a blinking red LED to attract attention to the end of the tube. My wife drew up an instructional sign, and sacrificed one of her old pairs of tights to cover the tube and all the exposed wiring.

Finished candy dispenser.

    We ended up getting about half a dozen kids, in two groups. The dispenser worked well, and with some guidance from their parents and me calling out instructions from inside, all the kids were able to get candy from it. I did determine during testing that Twix bars would sometimes jam in the cartridges due to being just the right length to get caught diagonally, but once I pulled those out the mechanism worked well enough.

    This was a fun project for Halloween, built entirely with parts I had on hand. I'm not sure if I'll bother with something like this again next year, though if I do I'll probably redesign it from scratch, as the rotating carousel mechanism for dispensing candy was really crude and could be made a lot more reliable.

Building the Nemesis Staff

It's all a Nemesis plot

August 2019.  My wife is getting ready to go to DragonCon, mostly to meet up with friends that she knows from online games, including the recently resurrected MMORPG City of Heroes.  About two weeks before the convention, she tells me that she’s going to the steampunk-themed ball, where two of her friends are getting engaged. I decide to try and make a Nemesis Staff, a gear-shaped weapon from the steampunk themed Nemesis villain group from CoH.  I didn’t think it would be too hard, but what followed was one of the hardest and most rushed printing projects I’ve ever done.

In City of Heroes, Nemesis is one of the higher-level endgame villain groups, and Lord Nemesis’s signature weapon is the Nemesis Staff.  The prop I was building was not the full version wielded by Lord Nemesis, but the lesser version available as a temporary weapon for players to use.  Mostly because it was much easier for me to get screenshots of the readily available temporary weapon, rather than hunting down Lord Nemesis or one of his many duplicates.

I was ultimately going to have to work from screenshots for making the prop.  Extracting actual geometry files from City of Heroes is difficult. Object geometry isn’t stored in any easily accessible format.  The usual method to record scenes is with utility that runs on top of CoH and intercepts geometry data on the way to the graphics card, but that results in recording the entire scene, at which point I’d have to manually filter out just the nemesis staff geometry.  But even if I did that, I could already see that I’d have to redraw the staff from scratch anyway. The in-game prop is painfully low-polygon, big chunky triangles approximating a circular shape and gear teeth that were suggested by image mapping rather than being actually drawn in.  This game is about 15 years old, and the graphical models were quite crude, and would have looked terrible if I had simply printed them out as-is.

Instead, I decided that I was going to draw the Nemesis Staff from scratch, using the appearance of the item in the game as a rough guide, but ultimately redrawing the whole thing from scratch.  My goal was to try and intuit the concept that the artists who drew the game model were working from, and to come up with what it would have looked like if they’d had unlimited rendering resources to work with.

While peering at the screenshots and trying to figure out the design of the gear mechanism, I realized that there appeared to be a lot of subtle detailing on the part, especially on the outer ring.  In the texture map, there appeared to be suggestions of engraved and embossed details. I tried to reproduce these on the printed prop, although it was at times difficult to tell if what I was seeing was intentional detailing or image compression noise.  As mentioned previously, the source images were painfully low-resolution.

Recreating the fine detailing in Solidworks

In other places, the texture mapping had obvious rivet heads and other details, which I expanded into actual physical shapes, in places making them actual separate pieces so they could be different colors from the surrounding materials.

The outer ring was clearly intended to be circular, rather than the crude polygon of the game model, so I drew it as such.  The central hub was also clearly intended to be circular. The sun gears, on the other hand, had detailing that suggested that they were intended to be actual hexagons, with six well-defined gear teeth.  There were lines on the inside of the ring and outside of the hub suggesting gear teeth, but they didn’t mesh with the planetary gear in any meaningful way. I added actual working gear teeth to make the mechanism actually work as a planetary gear mechanism, with the outer gear rotating and the planet gears going around as they do in the game.

Side by Side. Redrawn nearly entirely from scratch.

However, you may have already noticed the problem.  The Nemesis Staff isn’t actually a functional planetary gear mechanism, as it only has only two gears and nothing else locating the outer ring.  If I built it as-is, it would be likely to simply fall apart if you tried to rotate it. I considered a few different options on how to fix this, including redesigning it to have three or four gears, or adding some kind of hidden internal support structure to hold the planets and ring in place. 

For this prop I decided on making two design changes.  First, I added a hopefully unobtrusive carrier frame to hold the planets in line with the sun gear.  Second, I added a small brace piece to the inside of the fork to grip the ring and hold it in place. The outer ring already had a black line that suggested an inset groove, and a ridge on the brace fit into this did a pretty good job of holding the ring in place.  I also designed the teeth on the planet gears to fit into the sun and ring in such a way to try and lock everything in place once assembled. The result was really tight, tight enough to be difficult to rotate at first, and to be in some danger of damaging the plastic from the forces needed to make it turn.  In retrospect, I could have made it a bit looser.

I had decided that to save time, I would design the part to be completely unpainted, using the colors of the bare plastic. I had seen some amazing prints done with metallic Silk PLA, and wanted to try that out.  While I was designing the part, we ordered a few reels of copper and gold silk filament for overnight shipment. These arrived with a free replacement nozzle and a bag of nozzle-cleaning needles. I should have taken this as a warning.  The printing process saw repeated nozzle clogs, the Silk PLA was somewhat tricky to work with, and I think I may have ruined the nozzle in the process.

I had the design mostly done after a weekend of work.  Printing took much longer. The printer was exiled to the spare room where it wouldn’t keep anyone up as it was printing all night, and I had my wife check on it while I was at work as it was printing during the day.  The total print time on all these parts was over 100 hours, but that doesn’t include the multiple prints wasted from clogs that happened halfway through. This was the most demanding print project I’ve ever done, in terms of how many long prints I had to do back-to-back.  Not long after finishing, I did a complete teardown and rebuild of the arms and hot end, as everything was showing a lot of wear although I had been using the printer for years before this.

My big fancy custom Delta printer

The biggest problem was nozzle clogs happening midway through long prints.  I had a really surprising amount of difficulty printing with the silk PLA. Doing a nozzle flush with clear filament between every print with silk appeared to help, along with cleaning out the nozzle with the cleaning needles that came with the filament.  In retrospect, I suspect I may have been running at slightly too low of a temperature, as Silk should be printed at higher temperatures than normal PLA.

Printing took place over about a week of solid day and night work for my printer.  I was still designing parts of the piece during printing - the outer ring was designed first, with the inner part and fork printed while the large ring pieces were printing.  Some of the larger parts took over a dozen hours to print each, and there were a few print failures due to clogs, with many hours wasted.

Normally, with a complex piece with moving parts like this, I would go through multiple iterations and tweak the geometry until it was right.  But with the schedule I was under, there just wasn’t time. Nearly all of the parts on the finished staff were first draft parts. The clearanced were too tight on many of them, I had to do a bit of sanding to make the ring rotate smoothly, and there was some ominous creaking from the plastic as I tried to make it rotate.  If I was to make another one of these, I’d tweak the geometry and open up the clearances a bit. (Actually, I’d probably redesign the entire thing from scratch, but a quick cleanup would be acceptable if I wanted to make another one of these as-is).

Parts coming along. Getting ready to assemble everything.

Done. Attached to the first walking stick, which was not the one taken to the convention.

The last part to be designed was a mount to go on my wife’s lightweight walking stick.  Originally I had designed the Nemesis staff topper to attach to the top of her usual walking stick, which had a knob that could be unscrewed to reveal a threaded rod.  While packing she decided that this stick was too large and heavy to take on a plane, so she switched to a lightweight collapsible pole instead. This lacked the threaded rod, so I needed to at the last minute design and print a sort of clamshell clamp that went around the top of it.  It worked, sort of. It was ugly, and in the end relied on zip-ties, tape, and epoxy for structural strength. Not my best work.

My wife at DragonCon

The piece was finished just barely in time to be packed up for her flight to Atlanta.  She went to the City of Heroes meetup, and attended the steampunk ball, and showed off the piece to a lot of people.  It did eventually break, the last-minute walking staff adaptor breaking apart, and there was also some cracking around the planet gear frame and hub, but nothing that couldn’t be repaired on site.  Overall I consider it a successful design, especially considering how rushed the project was.

After this piece, I started working on a complete redesign.  Aside from the structural problems mentioned previously, this Nemesis Staff was too small.  Comparing the finished piece to the screenshots from the game, it came out about half the size it should.  It’s hard to tell exactly, since all character objects scale with the size of the character, but from comparing the picture of my wife to the images from the game, it’s clearly too small.

Scaling it up would make some of the mechanical parts easier to make, I’d have enough thickness for better axles and bearings.  In fact, with a bit of work, I could even fit motors and batteries in, and make it rotate. And if I was making it rotate, I might as well also install lighting and sound effects, to make it look and sound more like the actual weapon from the game.

Motors and bearings and working gears, and eventually lights and sound.

That fully working design has been put on hold for now.  I did enough modeling to determine that it would be practical, but haven’t done much more work than that for now.  If my wife wants to cosplay at a convention again, I’ll probably finish the design, but until then I have other more pressing projects to work on.

STL files for this have been posted at Thingiverse.

Building my PSP (PiStation Portable) Retropie gaming station.

After seeing this project on Thingiverse, I decided to build my own portable Retropie gaming console.  It looked easy enough to do, there were software builds available ready to install on a SD card, and it would be an excuse for me to gain more experience with Linux and on the Raspberry Pi.  Of course, I couldn’t just build the existing design as-is, eventually redesigning the entire case for the features I wanted.  I really wanted to improve the ergonomics and packaging efficiency of the design, to make something that would fit well in my hands and be easy to play and that wouldn’t be any larger or heavier than absolutely necessary, something that I could sit and play on a long car or train ride for hours without getting hand cramps.  I also wanted some features lacking on the designs I saw, including built-in battery charging, headphone jack, and a USB port available for loading ROMS.

I designed the printed parts in Solidworks.  I've been slowly teaching myself Solidworks over the last half a year, after finally getting completely fed up with the terrible 3D drawing capabilities of AutoCAD.  AutoCAD is a fine 2D drafting program, but a terrible 3D drawing program, and I'd been hitting against its limitations for a while.

Of course, I bought the original parts for this project about a week before the Raspberry Pi 2 was announced.  The Pi 2 would have made certain parts easier, having more processing power, more convenient mounting holes, and more USB ports, but I decided to press ahead with the parts I already had rather than start over with new parts.  If I build another one of these, I’ll redesign it for the Pi 2.

Nearly all of the parts came from Adafruit, the main exception being the video screen which is a cheap car backup camera.  The screen claims to need a 12V input, but I found that it runs just fine on 5V - the 3.3V switching regulator on the screen interface PCB still handles the lower voltage.  It does get a bit warm, and I suspect that there are parts in the regulator that are running more current that intended at the lower voltage.

I initially was going to use the same cheap multi-color membrane pushbuttons that everyone seems to use, but after trying them didn’t like the way they felt.  Too stiff and too clickey for my tastes.  I decided to use these slightly more expensive illuminated mechanical pushbuttons instead.  They cost more and take up a lot more space behind the panel, but they have a really smooth action and actual mechanical contacts inside instead of a membrane switch.  Being illuminated in a range of colors was a nice added cosmetic bonus.  I’m still using one of the membrane buttons for a control mode switch, and intend to use a second for a power switch once I get the soft power circuit working.

The controls are all managed through a Teensy 2.0 acting as a joystick/keyboard USB device.  The Raspberry Pi doesn’t have analog input, and I wanted an analog joystick, so the USB solution was the easiest way to go.  

I originally had a design involving 2 analog joysticks plus a D-pad and about a dozen buttons before coming to my senses and realizing that a single joystick and 8 buttons were enough for any game I’d be emulating.

There is one additional button not being directly used by the joystick.  This button is an input to the Teensy which changes its mode from a joystick to a keyboard.  When in keyboard mode, the joystick is mapped to arrow keys, and the buttons are mapped to a handful of selected keyboard buttons:  escape, return, tab, and some of the function keys.  This lets me navigate the setup menus and file transfer utilities without having to plug in an external keyboard.  The second USB port on the Pi is still accessible from the outside of the case, so I can still plug a keyboard in if I need to.  Mostly the external USB port is to be used to transfer game ROMs with a USB thumb drive.

Originally I planned to use a large 5V USB power pack for power.  This did not work out well.  These battery packs are designed for charging cell phones and don’t like to be used for other purposes.  The output protection circuit trips very easily, I wasn’t able to get it to play nice with a Mausberry soft power switch, and trying to use an audio amplifier to power speakers would trip the battery off when any loud sound played.  The voltage output from this pack is badly regulated, the screen would flicker as the voltage varied and there was a lot of noise in the audio from the Pi when using it.  It was also impossible to play games while charging the battery - when the charger was active the voltage output would get very low and erratic, the screen would flicker and the audio buzz, and plugging or unplugging the charge cord would cause a momentary power interruption that would reset the Pi.  

That battery pack was also a giant inconvenient brick that I had trouble fitting in the case.  

 After several frustrating weeks trying to get it to work I switched to a discrete battery and power boost /charger board, which works much better.












I still haven’t managed to get a soft power function working, with power on via button and power off automatically after shutting down Linux. The Mausberry doesn’t seem to have any easy way to work with the boost/charger board, so I’m working on my own latch circuit that uses the enable pin on the boost regulator.  It shouldn’t be hard to get to work, but until then I’m just using a toggle switch for manual power control.

The audio noise went away when I changed the battery, but the audio quality is still not great.  This is mostly due to the default audio output on a Raspberry Pi being rudimentary at best, but also apparently partly due to the game emulators not being quite powerful enough to smoothly reproduce the audio output on some of the consoles.  The SNES is especially bad, when there is a lot of movement on the screen the audio output gets really choppy.  If I really cared I could install a HifiBerry I2S plugin board, and then overclock the Pi to better handle SNES emulation.

I went through a lot of design iterations getting the shape right.  I wanted something that I could print in as few pieces as possible, with controls that were comfortable for my large adult man hands.  Widely spaced mechanical buttons and an smoothly-acting analog joystick won out over a D-pad and membrane buttons, even if it made the wiring and placement harder.  I struggled with getting everything to fit until I decided to solder the video, power, and USB connections directly to the Raspberry Pi board rather than use the provided connectors.  This saved a tremendous amount of space, especially for the composite video feed, although it means the Pi isn’t likely to be re-used for another project now.

The other breakthough on the design was having the video screen front panel outside the printed case.  I figured that it had a nice-looking front bezel already, so why not use it as-is?  Fitting the screen outside the case rather than wrapping the case around it saved space and made the packaging easier.  With directly soldered connections to the Pi I was able to fit the Pi, Teensy joystick board, battery, and power boost/charge board entirely in the space behind the screen.  That just left small extensions on either side for the joystick and buttons.  This was the point that I decided on the “PiStation Portable” name.  I hadn’t originally intended to model it after a PSP, everything just came together that way.  Ironically PSP games are quite hard to emulate, well beyond the capabilities of a Raspberry Pi.

The end result is quite compact and comfortable to hold, and I was just barely able to print the front and back halves as single pieces on my 3D printer.  It was very tight - the case is about 237mm wide at the widest point, and my printer has a 250mm diameter circular print area, so it was coming really close to the edges of the print space.  It did take several tries to get the back case to print successfully, it has some really difficult overhangs.

I’m running a standard copy of Emulationstation 2.6 on an 8gb flash drive.  I know that 3.0 is out now, but it looks like changing over to that will mean having to replace all of my ROMs from scratch.

So far I have Atari 2600 games working very well.  I found a ROM pack of what appears to be every 2600 game ever made and installed it - they only take up a few kilobytes each, so I had plenty of room.  Most of them haven’t aged well, but I do still enjoy Yar’s Revenge.  I have managed to get the Gameboy and Gameboy Colors emulators to work, but Gameboy Advance emulation still doesn’t work.

NES emulation seems to be the sweet spot for this design - there are a lot of fun games available, and the Pi emulates the NES very well.  

SNES emulation works, but the framerate suffers at times and the audio is choppy.  Getting MAME working will be my next goal, I should be able to play a lot of the older classic arcade games on this.

The only remaining hardware changes I intend to make to this one are to try to figure out a soft power switch as mentioned above, and to add a low battery light to the front panel.  There is a low battery light on the power management board, but it’s shining out the back of the case at the moment.  I need to find a spot to put another light visible from the front, so I have some warning to save my game and shut down before the battery dies.

If I had to do this over from scratch now, I’d start with a Raspberry Pi 2.0.  More USB ports, faster processor, better audio circuitry, and a more compact SD card slot.  It would mean a significant redesign of the case, and probably different wiring for the video and audio connections.  I’d also try to fit miniature speakers in somehow, so I could at least have some sound without having to plug in headphones.  An amplifier board and volume control would also be nice - the full volume output of the Pi is still fairly quiet.  The joystick/keyboard mode switch should probably be a small slide switch instead of a button, but other than that the ergonomics are perfect.

Plans, such as they are, are posted here.

Building the new robot for GenCon 2014

My little walking robot, that this blog was originally created to describe, gradually beat itself to death through performing at conventions and Makerfaires over a period of several years.  Broken servos were easy (if expensive) to replace, but eventually welds cracked in the legs and the servo control board developed intermittent faults.  Fixes to the structural problems just made it heavier and pushed the already overloaded servos further.  About a year ago I gave up and declared it dead.

Earlier this year I decided to rebuild a new walking robot from scratch.  I had at one point looked at tiny inexpensive plastic-geared micro servos as a possibility for a walking robot.  Initially I thought them too weak and small for use in any walking robot, but after seeing several successful robots using them I decided to try and rebuild my walking robot based around them.

I knew from my earlier experimenting that these micro servos would burn out if I ran them at 6V like I had in the earlier robot.  Rather than drop the 8V from a two-cell LiPoly down to 5V or lower, I decided to just run the servos directly off a single cell LiPoly instead.  4V is less than the maximum these servos should be run at, but I figured that it would help them last longer without overheating.  I wasn’t going to be getting much torque out of them, so I’d need to make the robot as lightweight and small as possible.

I made as much of the structure as possible out of 3D-printed parts.  My original justification for getting the 3D printer was to print parts for robots.  I spent a few years making homemade transformers and other fun things instead, but now I’d finally be getting to making robot parts.  The printer was really great for this job, the fact that I could make parts in complex arbitrary shapes, compound curves which would be very difficult to make with sheet metal and internal stiffening ribs without welding or machining, really helped with my goal of making the bot with as few overall parts and fasteners as possible.  

Thanks to the 3D printer I was quickly able to go through multiple sets of test hardware, tweaking the design to get the clearances and geometry just right. It also meant I could fairly easily make an entire set of spare structural parts.  I didn’t expect to need them, but once I had the design finished it cost very little in materials or time to print more out.

I kept the same overall proportions as the previous robot, but scaled down everything by about five-eighths compared to the original.  I wanted to try and make the legs as short as I could get away with, reducing the torque load on the servos while still keeping the legs long enough for decent speed and mobility.  The center sphere, which in the original had been made from a three-inch copper tank float, would now be a plastic ball about two inches in diameter.  The leg span at full extension would be just about eleven inches.  I expected to be able to reduce the weight to about a quarter of the previous design. 

Sadly the printed plastic parts don’t quite have the aesthetic charm that the old polished metal ones did.  My robot’s gone from a steampunk inspired hand-made design to one that looks more like a mass-produced toy.  The final colors were somewhat accidental - I had a different color scheme in mind originally.  I printed out some test pieces in white, then switched to red and yellow, colors I don’t use much outside of test prints.  I liked the resulting look enough to make the entire robot in those colors.

I decided to switch to easily replaceable battery packs rather than attempt to cram in a single battery capable of running for an entire convention.  I got a really good deal on five single-cell 380mAh battery that would just fit inside the two-inch sphere, with enough space left over for the radio receiver. Of course, I added battery protection boards onto each of them to make sure that the robot wouldn’t go up flames in case of a short circuit.  I designed a printed shroud to go around the battery which I hoped would make it easy to swap out batteries without needing tools at the convention.  Unfortunately the plastic snaps came out stiffer than I'd have liked, and I needed to use pliers to pull the battery out at the convention.  It was still reasonably easy to swap the battery packs out.

With the battery pack and the Xbee radio taking up nearly all the space inside the robot, there wasn’t enough room for the Xbee breakout board I had used previously, let alone that and a Pololu SSC or Arduino Mini to do the serial-to-servo conversion.  I had to make my own controller board, using tiny right-angle headers mounted sideways on the board and fitting the PCB itself directly between the pin headers on the Xbee radio.  The board would have to hold a PIC16LF873A microcontroller, 3.3V regulator for the MCU and radio, clock generator and other required components, as well as the connectors for the battery and servos.  The servo leads and connectors actually took up a lot of the interior space - when you only have a 2 inch sphere to work with, trying to fit 8 3-pin headers takes up a painfully large chunk of the available real estate.

I designed the PCB using the layout tools I have available at work, and then ordered it through OSH Park.  OSH Park was quite easy to work with and helped me configure my PCB design software to produce the right output files for their process.  The cost for the three boards they sent me was amazingly low compared with other prototyping services, only $9 for three identical boards which was even less than it would have cost me to set up to etch them at home.  The quality was a lot better than I’ve ever been able to do with etching myself too.  They also had no problems with the boards being odd, non-rectangular shapes, unlike most prototyping services that require rectangles of predetermined sizes.  The only downside to OSH Park’s service is that it’s not speedy, the batch-process system they use to keep costs down means they have to wait until they get enough orders before they can send boards to be manufactured.

The radio receiver, controller board, battery, and connectors occupy a box about an inch square down the center of the two inch sphere center body.  It's really tightly packed in there.  I had to make cutouts in the PCB and battery support structure for the inner mounting tabs of the leg servos, and leave channels in the surrounding support structure wide enough to feed the servo leads through.

The firmware I wrote for the controller in the robot is really simple.  It’s essentially doing the same job as the Pololu SSC I used previously, but with a simpler protocol, lower data rate, and coarser resolution.  The receiver takes a data stream at 8929 baud (it was supposed to be 9600 baud, but a PIC16LF873A running off a 4mhz crystal can’t actually match a 9600 baud rate) with each servo encoded as a single byte of data, and outputs eight 0.524ms to 2.500ms pulses, one for each servo.  The output resolution is fairly coarse (about 0.7 degrees per LSB) but I figure that these cheap all-plastic servos are going to be lucky to be within five degrees of the commanded position anyway so it really doesn’t matter.

I used the same transmitter as on the previous version of the robot.  The only change I made was for the new serial output format for talking to my controller instead of the Pololu SSC board.  I did have some problems with the transmitter at the convention, and I’ll probably be completely redesigning it for next year.

The controller board was the long pole in the project, once it was done and programmed everything came together quickly.  There were a few design issues with the board that I had to fix with cutting traces and soldering additional parts on. For one thing, the Xbee receiver uses a lot more current than I realized, requiring me to solder a larger 3.3V regulator on.  I’ll be updating the PCB files and publishing them once I’ve cleaned up the design.

With these cheap little servos, and my previous experiences with them failing after a few seconds of running under load, I wasn’t sure that this robot would even be able to hold up its own weight without breaking.  I was therefore pleasantly surprised when the new robot not only stood but nimbly walked around, waved and rolled over just as well as the old one had.  Some quick testing showed that a single fully charged battery would be good for fifteen minutes of solid walking, and that I was able to go through several full batteries walking the robot around my living room without any servo failures.  Testing at work showed that the radio range was more than sufficient for the robot to still walk while at the other end of the longest hallway in the building, something that I had been worried about as there was no room for any kind of external antenna on the robot.

With everything tested and seeming to work, I packed the robot and all its spare parts and was off to GenCon.

Adding a second hinge point to cheap micro servos

Several years ago when looking for cheap servos to use for my walking robot I purchased a handful of HXT900 micro servos from HobbyKing.  They seemed like an incredible deal for less than $3 each, but after brief experimenting I gave up on them.  They were very jittery, not terribly strong, and when run at 6V the motor would burn out quickly if the output was stalled.  I tossed them in the junk box and forgot about them, writing them off as not usable for my robots.

Later, at Makerfaire NYC I talked to a maker who was developing kits for a hexapod robot that used 18 HXT900 servos, who had been having some success getting them to work.  I also some very impressive projects online of robots based on these servos, which was enough to make me reconsider my first impression.  My old quadruped walking robot was completely wrecked from many weekends of running demos, so I decided to build a completely new one from scratch based around the HXT900 servos.

The first thing I needed to do with these servos was add a second hinge point to them.  The knee design my robot has uses the servo case as half the hinge joint.  I'm using the same design as on the previous robot, but scaled down, using a 4-40 weld nut, 1/4" OD spacer, and 4-40 machine screw for each servo.

The first thing that needs to be done is completely removing all the stickers from the outside of each servo.  They'll prevent you from opening the case, and the tolerances on my design were tight enough that the stickers were being damaged when I installed the servos into the prototype chassis anyway.

The hole for the rear axle needs to be directly opposite the output shaft.  In theory I should have made up a jig for this, but just eyeballing it seemed to be close enough.  The hole doesn't precisely locate the axle point anyway, so it only needs to be approximate.

For plastic this thin, a drill bit would be overkill, and would probably risk shattering the case.  I used a good sharp Exacto knife to carve out the hole.  Again, the diameter of the hole is not critical, it just needs to be large enough to clear the barrel on the weld nut.

 Then glue a weld nut to the inside of each servo case.  The weld nuts I used just barely fit inside the rear of the servo case.  This helped with alignment - the sides of the servo case held the nut in place, so the position of the hole in the case didn't really matter so much.  You'll also want to make sure to remove any inspection sticker or other residue from the inside of the case before this step so the glue bonds effectively.

The spacer and screw are then temporarily put on to help clamp the weld nut against the inside of the case while the glue sets.  I'll be having to remove them later to install the servo in the knee joint.

 Finally here are two of the servos (pre-modification) installed in a test prototype for the new 3D-printed knee joint, next tot he same structure on the old robot.  You can see that the new design will be much smaller and lighter weight.  I'll also be taking a lot of advantage of the 3D printer's ability to make complex arbitrary shapes for the new robot's structure.

Drew's Dalek Transformer

Decepticons ... Exterminate!

After the 3D-printed Transforming Tardis I designed, the next most requested design was for a transforming Dalek.  This was to be a much more complex design - both because of the more geometrically complex nature of the Dalek compared to the Tardis, and because I wanted to be a bit more ambitious with the complexity of the transformation geometry.

Unlike the Tardis transfomer, which was strongly modeled on the classic Optimus Prime design for the robot mode, my goal for this design was not so much to make a Transformer with a Dalek altmode, as to make a Dalek with the very unusual feature of being able to turn into a large humanoid-ish robot.  As such it isn't based on any actual Transformer, although I did draw some inspiration from Octus, a Generation One transformer that apparently had a Dalek as its alternate form.  I decided early on that I wanted the robot mode to still be recognizably Dalek in design, including having the actual Kaled mutant for a head rather than a recognizable Decepticon face, but I did take from Octus the idea of having the model have more than two arms.  Originally I wanted to give it six full arms, but was only able to make the geometry work with four proper arms and two vestigial ones holding the Dalek gun and plunger.  The robot mode actually ended up being more similar to the Transformers Animated Octus, although this was not at all intentional.

My main art reference for the model was the 2005 Doctor Who episode Dalek.  This episode was the first in the new series to show the new-series Daleks, and really gave a good look at them.  I liked the fact that most of the exterior details were the same color as the basic shell, which would simplify printing as I wouldn't have to make those bits separate parts.  That episode also had a remarkable scene in which the Dalek's casing split open to reveal the Kaled mutant inside, and I decided early on that I wanted my model to be able to do the same thing.  I used pictures of this amazing sculpture as an art reference for detailing the inside of the Dalek.

Purple is about the closest color I had on hand.  I also tried green and grey, but this seems to come out the best.

The Mutant itself was one of the most complex individual parts I've ever drawn.  AutoCad is not terribly good for drawing this kind of three-dimensional, organic shape, but after much effort I manged to make it acceptably well.  I may redraw it from scratch in ZBrush in the future.

Designing this feature into my model meant that the upper body had to be essentially hollow, made up of movable cosmetic panels that weren't able to do much more than hold the shape of the upper body when in Dalek mode.  The bulk of the robot mode - the arms, legs, and most of the torso - all needed to be folded into the skirt of the Dalek, which ended up as a tricky engineering challenge.

Unfolding the limbs - the bottom and front of the skirt become the legs and feet...

Then the arms can swing forward and straighten out.  Two of the arms have fists (actually just copied-and-pasted from the Tardis transformer) while two have more traditional Dalek claws.

Elaborate locking tabs on the feet, knees, and hip joints allow the robot mode to stand upright on its own, not even relying on friction to hold upright.  I learned from the mistakes of the Tardis transformer.

Having the Kaled Mutant taking up most of the available space in the upper body also meant that there was no room for a proper robot head, but that was fine with me.  I was inspired by the mad human-hybrid Dalek Sec from the episode Daleks in Manhatten.  I thought that was a terrible episode, but I did think the form of a human with a Kaled mutant for its head was visually interesting, so I decided to make that part of my model swing up to form the robot-mode head.

The torso unfolds, straightening up with a fairly tricky 4-bar linkage, and the mutant on its pedestal swings up out of the main body.

The two front quarter-panels, holding the plunger arm and gun, swing down and lock to the abdomen parts.  This hold the entire torso upright, and was a really complex bit of geometry to figure out.

Then the rear quarter-panels swing down and tuck in behind the torso, clearing out the space behind the head.

Finally the dome turns around to point backwards, then folds down on its support arms and locks in between the folded quarter-panels.  The dome support arms also carry the front grill panels, and these fit in to fill out the area between the head and torso.

When completely transformed, it stands about twice as tall as when in Dalek mode.  As with my Tardis transformer, it's bigger on the inside than on the outside.

When designing the robot altmode, I wanted to keep aspects of Dalek design philosophy in mind.  First, Daleks were intentionally designed to be menacing and inhuman, lacking in familiar and relatable details.  I wanted to keep that feeling even when the Dalek was transformed.  While it might have arms, legs, and a head, it should still be inhuman and menacing in form.  I tried to evoke an insectile, claw-like shape for the legs, and make the connection between the arms and the torso more similar to how the forelimbs of a grasshopper or similar insect are connected.

Secondly, the Daleks, by their own admission, have no concept of elegance.  Dalek machinery looks functional and brutal, with no care given towards appearance.  Parts are never streamlined or carefully matched, and exposed pipes and hanging wires are common.  This actually meant more work for me, adding those details to exposed surfaces throughout the model.




















I think the overall theme of ugly yet brutally functional worked out well.

The finished model has just over 10 ounces of plastic, and I estimate takes at least 24 hours of machine time to print.  (Total design time for me was at least 4 weeks of weekends and evenings, and a large number of scrap parts getting the design right through trial and error).  There are about 100 printed parts in the finished design.  It's not as clean a print as the Tardis transformer was.  There are several parts that need to be glued together, as I wasn't able to make everything snap-fit.  On the other hand, there are still no metal screws or other non-plastic parts involved, and no painting other than a single dot with a black Sharpie to make the pupil of the mutant's eye.

There are also quite a few small, fragile details that are tricky to assemble properly, and the transformation sequence is difficult.  The torso is made up of a lot of parts that want to flop around loose until you lock them together, and when going back into Dalek mode it's tricky to get all the body panels in place.  There are a few bits of geometry I still could touch up to make everything go back together more easily.

I will probably be posting build files and assembly instructions for this on Thingiverse, once I've cleaned up a few details and had a chance to put together a good assembly guide.  This design was mostly a learnign experience for me, as I gained a lot more experience on designing complex 3D assemblies with Autocad.  Autocad really isn't the best tool for this, I was really running into the limitations of the software on this project, so I'm hoping to gain more experience with ZBrush and Solidworks for future projects.