MakerBot Print is our newest print-prepration software, which supports native CAD files and STL assemblies,
allows you to interact with all your printers via the Cloud, and many other exciting new features.

Download Now

MakerBot Print is our newest print-prepration software, which supports native CAD files and STL assemblies,
allows you to interact with all your printers via the Cloud, and many other exciting new features.

Download Now

Vorpal Combat Hexapod

by vorpal, published

Vorpal Combat Hexapod by vorpal Sep 12, 2017

Featured Thing!

4 Share

Thing Apps Enabled

Order This Printed View All Apps


Here's a 1 minute Intro Features Video

This project has an associated Kickstarter where you can buy all the non-3D printed parts (and even the 3D ones if your printer isn't big enough). We even offer them fully assembled if you want.

I made this all open source and respectfully ask you to consider supporting the project. We successfully funded on Kickstarter with hundreds of kits sold, and now we are accepting pre-orders on Indiegogo.
Vorpal Hexapod Indiegogo Kits

What in the World Is It?

This is an awesome 3d printed, open source, Bluetooth controlled, Scratch programmable combat hexapod with a 3d printed gamepad and a bunch of accessories to play different games. I mean, seriously, let that concept wash over you for a moment. You absolutely need this little guy running around your house!

Related Things

The Vorpal Combat Hexapod was built to be extensible. We've already published a bunch of items that are compatible and hope the community will contribute even more.
Thing 2539659: Vorpal Joust Game
Thing 2546533: Vorpal Capture the Flag Game
Thing 2555606: Vorpal Fidget Spinner Challenge Game
Thing 2538181: Vorpal Eye Decorations
Thing 2538179: Vorpal Name Plate Decoration
Thing 2548308: Vorpal HC-SR04 Rangefinder Sensor Bracket

What in the Heck Can it Do?

Quick feature list (See complete details at the Vorpal Combat Hexapod Wiki:

  • All parts print with no supports. Some parts do require brims or rafts for proper bed retention to avoid warping. But generally, this is a fairly easy print.
  • 60 different motions directly accessible from the 3D printed gamepad, including modes for walking, dancing and fighting. These can be used for many fun activities for Makers or the classroom. Here are a few sample activities, more are on the Vorpal website:
    Fidget Spinner Challenge Activity Video
    Joust Game Video
    Obstacle Course Activity Video
  • Gamepad has a cool RECORD mode allowing you to record a set of gamepad actions then replay them with a touch of a button, great for classroom activities like "Dance Party!" where students program a choreographed dance routine to a popular song:
    Dance Party Video
  • Magnetic accessory attachments surround the cap, great for decorations, name plates, or small sensors
  • An accessory port on the front of the robot allows you to attach optional accessories for games and combat styles, such as Joust, Capture-The-Flag, heavier sensors like ultrasonic rangefinder, etc.
    We've provided a bunch of 3d printable accessories; feel free to develop more yourself!
  • Plug the gamepad into a computer USB port and it becomes a transmitter for the MIT Scratch drag-and-drop programming language!
    Xylophone Scratch Activity Video
    We have a fully developed set of Scratch extension blocks that let you totally control the robot using Scratch, including reading sensors from the robot and using the values to modify behavior.
    Scratch Obstacle Avoidance Using Ultrasonic Rangefinder Video
    Because many schools use Scratch to introduce programming, this makes the Vorpal Combat Hexapod perfect for educational use!
    For more information see our Vorpal Scratch Programming Guide.
  • We went beyond the call of duty with Scratch: you can program new hexapod actions in Scratch then upload them to gamepad buttons!
    You can have 60 custom actions, triggered by "long tapping" on the mode buttons.
    Short tapping executes the default actions again.
  • 1 hour battery life from commonly available, inexpensive "18650" Li-On batteries (used in many rechargeable flashlights).
    It's like a big fat AA battery and they're about $3 each (two required for the hexapod) and can be recharged 1000 times! Tons of them available on Amazon or other places.
    Gamepad takes a standard 9v transistor battery.
  • All 3D model source files posted publicly on OnShape.com so hack, remix, or extend this design to your heart's content!
  • All Arduino and Scratch source code posted publicly on GitHub (github.com/vorpalrobotics/vorpalhexapod)

Where Do I Get the Electronics Parts List And Build Instructions?

For complete build instructions and bill of materials, see our build instructions page.

IMPORTANT NOTE: We are in a Beta phase right now and all docs should be considered DRAFTS. In some cases info may be sketchy, diagrams not available yet, etc. We're working hard to get this up to speed as quickly as possible.

We are perfectly fine with you acquiring all the parts yourself from local sources, but if you want to help support this project and gain a little convenience, consider buying the electronics kit from us. You get all the right items in one simple package, and you'll make it possible for us to continue developing and releasing open source projects. See the Vorpal Hexapod Kickstarter for details on how to purchase kits containing the parts.

The kit that comes from us has these features:

  • Every single non-3D-printed part you need is included, electronics, servo motors, Bluetooth modules, screws, bearings, the whole 9 yards.
  • No soldering required; we did the soldering for you! Great for schools who don't what to deal with soldering.
  • Arduino Nano processors for both gamepad and hexapod are pre-flashed with the control programs; just plug them in and run.
  • Bluetooth modules in each kit are configured to auto-pair on boot. That means, no cryptic "AT" commands or other frustrating setup to do. Again, plug and play.

The only thing the kit does not include is batteries. See below for battery info.

We also do sell the 3D printed parts if you don't have a 3D printer that meets the minimum requirements (5.8" cube build area).

We also sell fully built and tested hexapods for those schools or hobbyists who just want to use this to learn or teach programming, use the activities, etc.

Does This Thing Really Work?

In development for over a year, this has been worked, reworked, an honed to perfection. It was used during a six week STEM program for Appalachian Girls this past summer (8 hexapods) and was a smashing success. We've been invited to the NYC Maker Faire, we've done teacher technology training on board the USS Intrepid Sea, Air, and Space Museum in New York City, gave presentations including hands-on activities at the New Jersey Science Teacher's STEM Conference, and we'll soon do a 2 day workshop at the Franklin Institute Science Center in Philadelpha. This thing is for real folks, in use by real students and in teacher training, with professional level software to make it work.

Is This Really Open Source?

All the 3D models are open source, along with the Arduino code for both the hexapod and gamepad, as well as the Scratch block extension. All the electronics are items that are either open source (Arduino Nano, Adafruit servo controller) or standard off the shelf items like hobby BEC for power supply and MG90s mini servos.

For specific open source licenses, see our website's Open Source License Info Page.

Where Do I Get the 3D Models, Software Source Code, and Activity Rules?

  • 3D Model Source is posted publicly on OnShape.com, just create a free login then search for Vorpal Combat Hexapod. If you were not aware of it, OnShape is a professional level cloud-based CAD system.
    It's free as long as your project is public, so no cost to you, no install time (runs entirely in your browser). Make a free account in less than a minute and you're up and running with a professional grade system. This site was developed by some of the founders of SolidWorks, so they know what they're doing.

  • Arduino Source Code and Scratch Extension code is posted publicly on GitHub (github.com/vorpalrobotics/vorpalhexapod)

  • Activities suitable for hobbyists, Makers, and schools are posted free on our website's Games and Activities Page.

Battery Info

Gamepad takes a standard 9v transistor battery (either alkaline or rechargeable such as NIMH).

Hexapod takes two 18650 lithium-ion rechargeable batteries. Although many people are not familiar with this kind of battery, they rock. They are commonly available at Amazon and other places because they are used for flashlights. They are cheap: you can get a bundle that includes smart charger and two 18650 batteries for only about $12 to $15.

They are powerful: you get 60 to 80 minutes runtime on the hexapod! They are lightweight, putting less stress on the servo motors. They can be recharged 1000 times. Super economical! You start using these in your projects and you'll never want to use AA or AAA battery packs again, trust me.

(The only reason we don't include these in our kit is that the margins are so low on batteries we would actually lose money by shipping them to people.)

Print Settings

Printer Brand:





Tested at 0.38 mm layer but should work at other settings


15% recommended


Recommended plastic is ABS or PETG. PLA tends to be too brittle. Brims or rafts recommended for the following parts: base, cap, legs, electronics caddy. Heated bed recommended. Minimum bed size is 5.8 inches cube.

Rafts: Some parts need brims or rafts for proper bed retention (I prefer brim; they seem to work fine and are typically easy to remove). The parts that I strongly recommend brims/rafts for are:

  • Legs
  • Base
  • Cap
  • Electronics Caddy

You may find, depending on your printer, that you need brims on:

  • Various nameplates
  • Joust lance


Overview and Background

There are many different activities available for this project in many different areas. You could fill a whole marking period with different aspects or just concentrate on one.

Some examples:

  • You can focus on 3D printing aspects (even for younger grades simply designing a new set of 3D printed "eyes" to magnetically attach is a great intro). For older grades, middle school or high school, have students develop a new game including attachments that must be compatible with the existing robot, game pieces, rules, etc. Brainstorm, design, fabricate (i.e. 3D print and assemble), test, analyze test results, then iterate the design!
  • Introduce concepts such as repeatability by using the RECORD function, then extend this to programmed Scratch projects that stress repeatability.
  • Use Scratch programming to introduce the use of sensors for real world navigation such as obstacle avoidance.
  • Illustrate "Search and Rescue" robots by designing a disaster area using cardboard boxes, have students use the robot to find and rescue "victims".
  • Simulate an exploration robot: send the Vorpal Hexapod to "Mars" and drive (or program) it to take a soil sample, or use a sensor to get a temperature reading.
  • Simulate a military robot used to disarm an improvised explosive device.
  • Teach concepts of walking gaits (tripod, metachronal, ripple, etc.) and discuss advantages and disadvantages of different ways to make a robot walk.

Lesson Plan and Activity

For an extensive list of activities suitable for education, see our Games and Activities page. This is constantly being updated and extended, and we would be glad to hear your ideas for new activities and lessons based on the Vorpal Combat Hexapod.

More from Robotics

view more

File Name



All Apps

3D Print your file with 3D Hubs, the world’s largest online marketplace for 3D printing services.

App Info Launch App

Auto-magically prepare your 3D models for 3D printing. A cloud based 3D models Preparing and Healing solution for 3D Printing, MakePrintable provides features for model repairing, wall thickness...

App Info Launch App

Kiri:Moto is an integrated cloud-based slicer and tool-path generator for 3D Printing, CAM / CNC and Laser cutting. *** 3D printing mode provides model slicing and GCode output using built-in...

App Info Launch App
KiriMoto Thing App

With 3D Slash, you can edit 3d models like a stonecutter. A unique interface: as fun as a building game! The perfect tool for non-designers and children to create in 3D.

App Info Launch App

Print through a distributed network of 3D printing enthusiasts from across the US, at a fraction of the cost of the competitors. We want to change the world for the better through technology, an...

App Info Launch App

Quickly Scale, Mirror or Cut your 3D Models

App Info Launch App

3D Print a wide range of designs with Treatstock. Easy to use tools to get the perfect result. The global 3D printing network that connects you with high-quality and fast working print services nea...

App Info Launch App

A HUGE THANK YOU to the Thingiverse Community! The Kickstarter campaign ended last night and achieved over US$38,000 in pledges, which was 213% of goal!

We are continuing to take orders now by using Indiegogo's "InDemand" service. This is not a new campaign, it's just a way for us to continue taking orders while we build out our online store. Click here for more info: https://igg.me/at/VorpalHexapod

Thanks again to everyone who has supported the project either financially or by offering advice, or just making the project yourself and showing it off to friends and family!

How long does it take to print all the parts and roughly how much filament does it require?


Print time heavily depends on the printer. For my Taz 6 it's about 16 hours for the robot and gamepad, not including the attachments and game pieces. That's not bad considering the number and complexity of the parts. Basically kick it off overnight, or do it in batches of parts a few hours at a time. If you print the BASE, LEGS, and LEG HINGES that's all you need to do about 90% of the robot build. So do those first.

Filament for the robot is around 220 grams and gamepad adds another 100 in round numbers (depends to some extent on plastic type, some plastics are denser than others). Again, game pieces and attachments would add to that a bit.

I've been playing around with OnShape a little and it's incredible. I am by no means a CAD expert, just dabbling with OpenSCAD, Tinkercad and the like to create some simple designs. I think OnShape is the first powerful CAD program that I just might be able to use, at least to modify existing designs. I had no idea such a powerful, relatively easy to use program existed, let alone free to use for hobbyists creating public designs. For instance, I was able to change the number of oval holes in the cap from 24 to 12 to make it possibly easier to print. Could easily play around with the outline shape as well. Thanks so much for making your wonderful design available in this great program, Vorpal!!!

Hey all,

First off, thanks for the project. I'm very excited about it!

I wanted to ask if anyone has any advice on printing the legs. I've tried both PETG and ABS, and I'm getting some drooping on the layers near the top. I've attached a picture.



I would suggest slowing down the print, and making the minimum layer time at least 15 seconds. Also, I'm not sure if you were printing one at a time or if you printed them all at once, but it works a lot better when you print all at once because that gives time for each leg layer to cool and solidify before the next layer. Mine also come out the way you're showing if I only print one at a time.

Going slightly lower on the extrusion temperature (just a few degrees C) may also help because it will be a little less runny at a lower temp.

Hope this helps!
-Steve P.

Hey - thanks for your response. I did print it one at a time. I will adjust!

I appreciate all your work on this!

hey, great work

wich servos are you using?
are there special ones? or just any about XX gramms

The robot was designed for MG90s style servos. Shaft spacing etc is pretty critical, if you substitute you likely would have work to do to make things fit properly.

Hi. Great project. I have the robot built and am at the testing stage. I think I may have the wrong 10K potentiometer though as the robot doesn't seem to take much notice of the position. It then struck me that I had purchased a linear type. Which type of pot is required linear or logarithmic?

The kit uses linear. If you use a log pot then the markings on the Base won't match the action the robot does, but assuming you can get to every position it should work to some extent. Make sure you wire it like this: looking down at the pot with terminal leads at the six o clock position, the leftmost terminal should be ground, center is signal, right is +5V.

All working now. I think I may have popped an analogue pin by having the connection wrong. Turning the pot to zero would short the high and low pins together. Flashed a spare nano and all is good. Keypad and BT modules next. Thanks for the swift reply

i have a 10k linear working (marked B10k)

P.S. Mine was built on a cherry pi

All built and programmed but looks like my ubec cant supply enough power. In demo mode it does about 5 seconds and then curls up in a ball and the green light on the servo board is flickering.

disconnected all the joints and tried again still no joy.

Removed some of the servos and it works ok.


I also tried an FPV BEC at first (don't recall exact model number) and it cut out at about 2.5 amps. I feel like their overcurrent protection or maybe thermal protection is a little quick on the trigger with this brand, and so you're not really getting 3 amps.

If you have a spare FPV, you could put a second one in parallel with the first and see if that works. Each FPV would be responsible for producing only half the current, so as long as they can output 1.5A that would work. That is not a desirable configuration for other reasons, however it will answer the question and get you up and running.

I just updated the page for those creating their own electrical systems on the wiki to show a picture of the BEC we use, although there does not appear to be a model number on it or brand name, it's a generic RC BEC. It's marked UBEC input 5-23V output: 5V, 3A.
Here it is: http://vorpalrobotics.com/wiki/index.php?title=Vorpal_Combat_Hexapod_Battery/Switch_Construction#Hexapod_Battery.2FSwitch_Assembly

The robot typically draws 2A standing still (not in sleep mode) and typically 2.5A when moving around, but it can spike up to 3A momentarily during certain dramatic moves (which do occur in demo mode).

There is another possibility, however. It is possible your FPV BEC can produce 3 amps, however you might have one or two motors that are borderline defective. Like I have said in other posts, about 10 to 20% of cheap MG90s you find on discount sites are defective and have bad gearboxes. Many of them literally freeze up within minutes of putting them under load. But some are more subtle, their gearboxes sort of work, but they grind a bit. You'll feel a subtle clicking noise at certain parts of the stroke. A servo like that can draw two or three times as much current as normal. if you have one or two of those, then your robot might easily spike past 3A which would trigger the BECs overcurrent protection and shut down the robot.

We individually test every servo before we ship it out. It adds expense on my side, but I know customers will appreciate getting parts that are going to work!

If you source your own MG90, please buy a few extra!

I had removed 4 servos at a time and it still drops out, i have ordered a ubec with 3a constant 5a peak.

Still playing with it and its amazing, Thinking some TFT eyes next (oled are expensive) Adafriut have a ready to go example

Out of curiosity, what kind of batteries are you using? If the battery is an 18650 with a protection circuit, I've found that some protection circuits are rather over-protective and will cut out very early. For example, the EBL 3000 mAh that have the white caps around the + terminal work amazingly well, I get 60 to 70 minutes and sometimes even 80. But the EBL 3000 mAh which have the yellow cap have a much more sensitive protection circuit and I only get 25 minutes before drop outs start happening.

Also, if the mAh rating is less than about 2500 you'll have issues because these kinds of batteries really aren't supposed to output more than 1C (or 2.5 A for a 25000 maH battery).

Final point: some cheapo no-name 18650 from china vastly overstate their ratings. I had one that claimed 9000 mAh and claimed it could output 9 amps! I suspected of course this was not true but tried anyway. In tests it powered the robot for about 10 minutes, indicating it was more like 1000 mAh or even less. I recycled those batteries because I feared they were so fraudulently touted that I wasn't sure if they wouldnt burst into flames during charging. I only buy reasonably well branded batteries now. Forget the no-names!

By the way I ordered a whole pile of different brand 18650 batteries and I will be publishing test data on my website in the coming days and weeks.

There 18650 unprotected panasonics from a reputable E-cig store, 2500ma.

I also tried some samsung 25r that i use in my e-cig still the same result,

OK it sounds like the battery is fine. If it has no protection circuit at all, it's not cutting out. I was just trying to cover all the bases to try to get you up and running!

Hi adambrum - which UBEC did you try to use? What's the current rating?

fpv bluesky rated at 3a (cheap)

Ran it off a 5v 5a power supply and runs like a dream

I didn't have good luck with that UBEC either. When I tried to use it on an RC car steering servo that required ~2A and it was constantly dropping out.
For the hexapod I was going to try one of these:


Probably the first one because the larger input and output capacitor will handle current surges better.
My 12 servos haven't shown up from China yet, though, so I can't test it out at the moment.

Are all the legs and hinges the same? The sizes of the each individual leg files are different but I don't see any obvious difference in the models. Also, there is a shelf with a hole in it at 33.7 mm on the legs. You say no supports are needed but I don't see how this would print without some kind of support. Thanks! --Dave

Thanks adambrum and Trudge! Just what I needed to get started.

The legs have different numbers on them but as far as i can see there the same, the shelf will print, doesn't matter too much if you get a bit of drooping the servo does not go all the way to the back and theres enough layers above to hide any marks

Hi Vinoh. The dimensions all appear the same to me when I check them in Cura. The size of the files will be different due to the individual numbers that appear on them (different number of g-code commands to print them).

My order #27420 has not arrived. It now 10/13/17. It has been 11 days. I was told it would be here in 10 days.What is going on?


I have searched my backer pledges on Kickstarter, and I cannot find anyone with your name (rick nesbit) or anything even close to it. There are no order numbers on kickstarter that I can access. There are backer numbers, and I can look up your order using your backer number.

Could you please message me from within Kickstarter so I can look and see what you ordered? Then I can give you a realistic estimate of ship date depending on that.

I'm not sure why you thought it would ship in 10 days, the listing on Kickstarter clearly says that the earliest shipment estimated dates would be in November. Your card won't even be charged until October 17, which is this coming Tuesday. Kickstarter by definition is listing products that are not yet in production, you are in effect pre ordering a new product that isn't yet shipping.

We do expect to get quite a few orders out starting October 20, beating the November estimate, but it all depends on what you ordered as to whether or not you'd be in that first batch. The first things going out will be Early Bird Basic Kits.

Comments deleted.

Are you using any sort of voltage divider for the HC-05 RX pin, it should be 3.3v

The need for a divider on the HC05 RX is something of an urban legend. The manufacturer's own documentation clearly shows the RX connected to a 5V uno digital pin with no divider in their example circuit. Nowhere does the documentation ever mention the need for a divider when interfacing with +5v arduinos or other boards.

There are tutorials floating around on the internet that say you need the divider, those may have been from older modules that were less tolerant. The newer modules were specifically built to work with common arduino boards, most of which do run at +5v. (I have not looked at the actual circuit diagram for the module, but I assume they've got enough impedance on the RX pin that even though it is above 3.3 there isn't enough current to cause any damage).

We've been running some of these modules for years, driving them from +5V nanos and unos, with no divider (taking them from one old project to another new one) and probably hundreds of hours, never ever had one fail. I've built at least 50 of these robots personally, run them for hours and hours doing tests. Not one single HC05 ever failed. (One exception: once I connected Vin and Gnd backwards, but that doesn't count for the current discussion!)

Save yourself a couple of resistors and a couple of minutes with the soldering iron, you don't need a divider.

It really depends on which HC05! Some breakout boards have a voltage divider, others like the zs-040s dont and require 3.3v TTL.

P4man, that's a good point, there are a bunch of different HC05 modules and i can't speak to 100% of them not requiring a divider.

The module we use is marked E475833 and the board layout appears to be completely identical to the ZG-B23090W. Might be different firmware or something.

I will update our wiki to give the module model number, and I will make a note about some BT modules potentially requiring the voltage divider.

For a nice summary of many different BT modules, see this excellent website:
He includes a section on the ZG-B23090W

Now, caveat, he does show the ZG-B23090W using a voltage divider on Rx. He may be doing this just to be safe. i can tell you, I have run over 100 of these modules, some for a very long term period of time, with no divider and not a single module has ever failed me. I did look up the manufacturer's user guide from china about a year ago, and even the manufacturer showed an example circuit to a 5V uno digital pin with no divider, and they say in that manual that the board was specifically designed to work easily with common arduino, rasberry pi, and other microcontrollers.

Alas, I got curious about it and wanted to read the schematic to confirm, but searching this morning for the schematic of either the ZG-B23090W or E475833 module numbers has been unfruitful so far. I am continuing my hunt later today, have stuff to do this morning. If anyone has the schematic let me know..

One more technical note for those who are electronics nerds: the usual method for unidirectional level shifting on Rx used by these type modules is not a voltage divider on Rx, because that would make it not work for a 3.3v input. what is usually done is a diode is put "the wrong way" on the Rx pin, and the MCU pulls this diode down to ground on LOW, while the Rx on the module has an internal pull up resistor so when MCU puts HIGH on Rx the pullup comes into play and the diode blocks the 5v from damaging the bt module. This makes Rx work for either 5v or 3.3v.

Good to know, setting up the units now

by 'Arduino Nano (marked R to indicate it is pre-loaded with robot software) ' you mean a special type of Arduino Nano?
I cannot find anything related to marked R in Arduino Nano context.
Thank you

The instructions on the wiki are geared towards the kit, the Nano's are labelled to identify which one goes in which bit of the robot or controller. If you're building from scratch it doesn't matter as the Nanos hardware wise are identical its only the loaded code that differentiates what they do.

Confirming that Jad308 has it right! If you flash the nanos yourself you could also use a sharpie or little bit of paper and tape to label which one is for the robot.

I have a question when it comes to assembling the cap to the base.
Instruction given in the wiki say "Turn the cap clockwise to lock it in place"

For me it doesn't lock at all. It just slides and there is almost 1mm of play between the cap and base.
I printed the cap and base in PETG with similar settings.
Is it supposed to be just a bit loose or Maybe I'm being too picky? I don't expect it would come off during use but it would slide around as the hexapod moves about.
I think a 1% increase in size of the cap overall would tighten everything up - maybe I'll try print another.

Anybody else come across this? Thanks.

The electronics caddy didn't help me either but I haven't added the screws yet.
@Trudge What was the screw head type that you used (socket cap, pan head, etc)?

I found that simply test fitting the electronics caddy without screws didn't help in removing the play (about 1.5mm for me). I did find though, that once the caddy screws are fitted (I drilled out the holes with a 3.5mm bit and tapped them as M4), the screw heads caused an interference fit with the cap, and it does up nice and tight.

Adambrum has it right!

So with a part like this, I have to walk a line between making it too tight and making it too loose, taking into account that different plastics, different printers which may or may not be dialed in very well, etc., are going to cause natural variation.

It does tighten up a bit with the caddy installed.

If that's not enough for you, as adambrum suggests, warm up the trailing end of the little tabs on the cap with a lighter (then end that would go under the lip last that is), very slightly bend them, hold until they cool, and you'll get a bit more resistance at the very end of the turn.

Mine fits ok, have you fitted the caddy yet , that will tighten it up a little.

If its PETG you could warm the locking lip up with a lighter and bend it over a little.

I have managed to print the cap but its not pretty, need lots of cooling fan and take it slow, going to print again with some columns around it so it has more time to cool.

And make sure you have z hop on

Most slicers have a "minimum layer time" setting. I have that set to 15 seconds, but 20 might be better if you're having this issue. That would do the same thing as the columns without using up plastic.

You might also consider printing at a slightly cooler temperature.

If you still have trouble, the new version that has no holes should print easily.

FWIW, minimum layer time only slows the print - and only up to a point, as you cant print infinitely slowly, you need to move the hotend or it will melt your print . Printing Columns has the big advantage of moving the hot end away from the thing you're printing, and is far more effective at cooling. Of course it has its own potential problems, like stringing, but its generally a good strategy if you have insufficient cooling or are printing very small cross sections.

I have tried to setup the scratchx, but only found that the latest chrome and firefox disable the native plugins so the scratchx didn't work well. Would you please let us know the OS and browser version you are using for scratchx, and where to download this version of browser, and how to disable the auto upgrade feature of the browser? Thanks!

Scratchx hasn't used native plugins on chrome in quite some time, it uses chromium serial io. Some of the information floating around on forums etc regarding scratchx on chrome are out of date. i use chrome on windows and mac and it works quite well. The issues many scratchx developers are having getting arduino serial working on scratchx is not a problem with scratchx, it's a problem with the example program MIT points people to, which does not set up data handler callback properly. (We do it the right way with vorpal).

I am publishing a new version of the scratch extension this weekend (if all goes well) and it should be more robust than what's currently on github. I'm switching over to the "URL" method of loading the extension which has some advantages over the file method. As soon as that's working we'll be cutting over the wiki to include a lot more info on how to load and use scratchx, including a short video introduction.

Again, we are still in a pre-release phase for another week or two, so we thank you for your patience! Everything is coming together really well but a few software items and wiki documentation items are still being tested and polished.

I am eager to see the updated scratchx programming wiki and introduction video, that would make the robot more useful than just a toy with fixed functionalities. Thanks!

UPDATE: I got feedback from one user who had trouble printing the Cap. On his printer, the skeletonized parts, which are pretty thin at some points, would get wobbly and stick to the nozzle, getting all messed up.

I had not heard of that issue before, but if one Maker is having the problem, there probably will be more. I would suggest cleaning up your nozzle (heat it up, wipe it with an old rag, maybe hit it with some very fine grit sandpaper to take off any carbonized debris) and running slow (I print the cap at 40 mm/s, your printer may vary of course).

But, if none of that works for you, I have now uploaded a variation on the cap called Hexapod_V1r8a_Cap_VARIATION_NoSkeletonize.stl.

This variation leaves out all of the skeletonizing holes. this will of course mean a little more plastic gets used and maybe the print is slightly longer. Also, you won't be able to see the bluetooth module light pattern to tell if you're connected (although you can peek through the holes on the gamepad and look at the gamepad's Bluetooth blink pattern which should be the same).

Still, failed prints also consume time and plastic, so if you need it, use the variation.

If possible, please post to me if you could or could not print the original so I know how prevalent this problem is! If it is more than a few percent of people, I may change the main version to be a little less aggressive on the skeletonizing.

Thank you! Feedback from the community will only make this a better, cooler project over time!

I just finished a day long effort to print the cap. First attempt broke off arms and ruined the print. I finally got it to finish on the second try by printing very slow and babysitting it to watch for the nozzle (or even my second nozzle) catching on the very fragile arms. It was quite a mess and I even had to stop the print for adjustments and repairs a couple of times. After I put the whole thing together, I'll probably print the non-skeletonize version. Adding some holes to that version sounds like a good idea and would save time and filament without sacrificing strength. All the other parts printed well. Excellent designs!

Hello all,
I believe I am the user Vorpal is referring to above that had significant trouble printing the cap. In my case, as the print neared the top, just before solidifying all the little "legs" together, the legs would get caught on the hot end as it moved around. This lead to horrible print quality at least. In several cases, the legs caught so bad that they broke off during the print. I tried printing slower as, Vorpal suggested. But I couldn't find a setting on my slicer (Slic3r Prusa edition) that would limit the print time per layer. Maybe it is there and I missed it?

Anyhow, slowing to 40mm/sec did not fix the problem. But I did try the VARIATION version he just uploaded and it printed fine. I am happy with it. So, Vorpal, if you wanted to make yet another version, I was thinking you could make little circles on the cap instead of long continuous slots. That should allow you to see inside while still being more rigid than the original. Just a thought.

I did notice that my new caps do fit rather loose in the base as reported above by JJohnson98. I have only printed one caddy so far and haven't tried the fit with it yet. But I am not too worried about this. I am sure there are a number of simple ways to adjust this.

Thanks for all the help, Vorpal.


Original cap printed fine for me in PLA (Wanhao Duplicator 6 - 0.4mm nozzle with stock cooling fan using Cura 2.7.0). 0.2mm layer height, 8mm brim, 50mm/sec, Ironing on with 1% feed, min layer time 5s . A few sagged strands towards the top above the holes as expected, but just cosmetic, and not seen as it's underneath.

Hi I backed the project as well, and while waiting on the kit, I have started printing the components.
I started with a couple of hinges, in PLA, as that is what I have on my printer (a geeetech prusa I3, with 0.3 filament extruder).
The parts print fine, but they snapped when I tried to fit them together. I have ordered some PETG filament, which should be better, but couldn't the hinges forgo the retainers, and either be glued on, or have a hole in the center so the two halves can be connected by a bolt?

Thanks for your support!

Whether that part will bend enough without breaking all has to do with the plastic. Some PLA will actually work just fine, others won't. It's important to squeeze just as much as you need and no more. Several people using different kinds of plasic, including some PLA have said the part actually worked for them without any problems.

Make sure you're printing with a 1mm wall, if the wall is too thin that could be an issue. Also, you could probably get it to work by heating it up a bit before bending. For example use a lighter or butane torch, run the torch QUICKLY over the surface five or six times, then bend when it's softer. If it starts dripping and melting, you heated it too much ;)

Yes, the original version of that part was glued as you suggest, and a later version used a screw as you suggest. Both those variants had issues. The glue eventually breaks from stress, even top grade epoxy. The screw eventually works loose.

That said, you could take snips or angle cutters, cut off the little ridges at the edges so the parts just fit together without bending, and glue the parts using superglue or expoxy.

If you have the bad luck of starting plastic on fire when you use the torch method (like me) you can just dip the ends in hottish (60C, 140F) water for several seconds which softens the PLA up considerably.
Fit the pieces together and just make sure the piece hasn't been bent too much and is the original shape before the plastic cools.

That hot water trick is a good suggestion! Obviously a lot safer than open flames too.

I'll add that to my instructions, will be doing some updates over the next couple of days.

Thank you both for your suggestion, I will try again tonight...

Is there any particular make of keypads your using, all the keypads i have found are to big for the gamepad.


The 4x4 matrix is marked YL-102 and I found it on ebay here:

The 5 key dpad is made by Keyes and is marked KEYS_AD_KEY and jjohnson's find on ebay looks correct:

The 4x4 matrix module that jjohnson98 mentions appears to be the correct size, however the pins come off straight up. I believe it will work fine if you carefuly bend the pins at an angle with needle nose pliers. At worst you'd need to slightly trim the gamepad cover to get it to fit.

Looks supercool! got in on the early bird basic kit so figured i'd start printing already. I was going to do the cap in glow in the dark filament gor the xtra creepy factor.
But when loading it in my slicer noticed the top is flat? How can I print that without support?

It's possible to print across short distances horizontally as long as there are supporting structures on both sides of the gap. That's called a "bridge". In the case of the cap, the very top is a moderately sized bridge, you may have a couple of drips but they'll be inside so cosmetically not a problem.

Thanks for the quick response, follow up question to this though: is there anything inside the top except for the batterypack? I did a quick mod where I pinched the whole top but little afraid of doing a 10 hr print to find out it'll all be for nothing.

Sticking up above the rim of the base, there's just the battery pack and batteries currently. There's extra room for potential future expansion, but nothing right now, and for aesthetics.

Awesome, it's printing now, I might just have a few variations ready to go, my daughter is super excited :)
I was showing her the videos ad came across Evan Gagnon's super creepy spidermod (ev-v3) any chance those files will be released too?

Hello, when will the wiring diagram be available ? there no input about which potentiometer to use and UBEC is mentioned at some point in the wiki, but not in the part list ... :(

The wiring diagram has been there for a while, it's here:

I will make it more obvious in the instructions how to get to it. (There is a link right at the top of the BOM but I could repeat the link down where the electrical harness is discussed.) You have to realize the instructions are primary optimized for the people building from our kits, and information for people building their own parts are links off that main build page. That said, I agree this could have been easier to find.

I clarified that the pot is a 10K ohm, 6mm shaft rotary pot with nut and dial cap. Looking from the top at the 3 terminals, the leftmost would be ground, the middle signal, the right +5V, so the wire colors left to right would be: black, white, red. (Of course many different colors could be used for signal). I will add a diagram of the pot wiring to the electrical diagrams a little later today.

Hope this helps!

Same question as jjohnson98 below re servo bracket play when clipped together. Printed in PLA @ 0.2mm layer height. I don't have any MG90 servos yet (only HobbyKing HXT900's). Will the MG90 servos force the brackets to open at all - which looks like it would reduce the play somewhat.

Yes you are correct, the act of placing the servos in the hinge spreads out the U shape and locks them in place. There should be essentially no play at all, or just a tiny bit, depending on your printer settings, how well dialed in it is, etc. Once both servos are installed, each piece clamps down pretty hard on the other piece.

I'm rather proud of that design! It is easy to assemble, the layer boundaries are running in the right direction so things don't snap, no supports are needed, and the act of installing the servos makes them lock automagically. There were something like 22 different versions of the leg hinge before this one that had one type of problem or another. I probably used an entire roll of filament just getting that one part done.

I love the design but not fond of the remote control so much...

Any chance of an Android BT control app coming out?


This is in the works. The decision to include a gamepad rather than go with an app from the start was a very complex decision. As you probably know, most robotics products do go the App route.

The decision was not because I couldn't write an app. I was at one time a distinguished software engineer at AT&T Bell Labs working on the Unix project, I've probably written over a million lines of code in my life (not an exaggeration) and my son actually wrote a book on android app programming so I am well capable of doing that.

What it came down to were several factors:


1) For a hexapod designed to be used for gaming, physical buttons are superior to "soft" buttons on a screen, because the tactile feedback of pressing the buttons allows you to learn to move the robot without taking your eyes off of it.

2) The gamepad made it far easier to implement scratch support. I knew my two markets were makers and teachers, and trust me, teachers want to see scratch support.

3) Teachers also don't want to have to buy an android or apple product to use the robot. Having it be "all in one package" was a big advantage for that market. Some schools have ipads or chromebooks or other devices, but most do not, especially in gradeschool.

4) When you're letting a little kid play with the robot, do you really want to hand them your phone? I had a previous robot product I developed that did use an app, and I was always nervous in demo situations giving a 6 year old my phone! All my emails, contacts, etc, were there, and they tend to drop things.

5) Althought bluetooth is fairly robust at this point, you will have significantly more customer service issues with people who are unable for whatever reason to pair the HC05 with their phone or tablet. In addition, in order to support both Android and Iphone/Ipad, I would have to use a much more expensive bluetooth module (apple products no longer support bluetooth classic which is a much cheaper chip).

6) Because of the need to support both android, IOS, and probably also Chromebook, an app requires much more development effort than a gamepad. Testing on many different devices, issues that only occur on certain versions of OS, etc., can be a nightmare when deploying software. I know, I've done it many times in my career!


1) Many people want to use an app instead of a gamepad (like you!)

2) It increases the price of the kit a bit. By far, the kit price is dominated by the servo motors, but an extra nano, SD card, button modules, etc. adds maybe 20%. However, this is partially offset by the need to use a much more expensive bluetooth module to support IOS (does not support BT classic).

3) It increases build time by about 20 minutes.


On balance, I decided the release 1 product should go with a gamepad. It was a close decision.

Of course, the best solution is to offer both! Limited development resources made that difficult for release 1.

But, we are working on it for the near future, probably early next year at least for Android, maybe a bit longer for IOS due to the need to swap BT modules.

Hope this explains our thought processes.

Looks like a fun project! Back the Kickstarter early bird basic kit today and looking forward to making it.

Hello, I had a question on the assembly of the servo brackets:
How much slop should these have after assembly? I feel like the joint should have almost no movement because of the clip action but I get quite a bit of wiggle. Just wondering what I should be expecting. My servo brackets are printed with PETG.
Really great work on this little guy - I can't wait to get mine up and running!


When you put the U shaped piece over the servo, it spreads out the U shape and the two parts lock quite firmly in place.

Now, that said, depending on the exact nature of your printer settings it is possible you would have a tiny bit of play. For example, if you tweaked the flow rate down then the parts might be a little smaller than intended, etc. I have not seen that happen but I've only tried this on a limited number of different kinds of printers and settings.

If there is some play due to that factor, a drop of hot glue would likely solve it.

Thanks for the design! One question, does it require 2 HC-05 or 1 HC-05 with 1 HC-06? I was confused by reading the wiki page.

If you are sourcing your own parts, you can use either 1xHC06 + 1xHC05, or you can use 2xHC05.

We used to use one of each, but recently switched to using 2xHC05 instead. HC05 can function as both master and slave when configured properly, and costs the same as HC06 so it did not make sense to inventory two different parts. I can also get better quantity discounts by using the same part for both. One final advantage: The HC06 has a different blinking light pattern than the HC05 for showing connection status, and by using the same part on both sides of the connection, I only need to explain one blinking pattern in docs, so it's easier for users to understand what they're looking at.

The wiki was cutting over to the new design recently and from your comment I assumed I missed a spot where HC06 is mentioned. I will search the wiki for the string HC06 and fix it, sorry for the confusion!

Hi, thanks for the info. Where is the master HC05 is installed? on the robot or the gamepad? Or it doesn't matter?

Right this second it doesn't matter, however, in the future we plan on having an app, so it would better for the slave to be in the robot and the master in the gamepad if you wanted to use the app.


First, thanks for everyone who has supported the kickstarter campaign. It seems likely that we will be fully funded sometime today! The support from the Thingiverse community has been awe inspiring!

Second, a few updates to the parts. You will notice that some parts are now labelled V1r8a (with the extra "a" tacked on the end). These parts were updated yesterday.

The updates were fairly minor, and if you've already printed the prior version (without the "a") then there is no need to reprint, you're fine.

There was one change that makes things a little easier and eliminates a BOM item, those pesky plastic balls. The Legs no longer require the polypropylene balls (previously used for bearings). The other changes were just making certain parts slightly stronger or making minor enhancements such as a new tiny little piece of plastic to help hold the beeper in place more effectively.


  • BASE The Base object now has better labeling for the dial and a little bracket to stop the beeper from coming out of its hole. Again, neither of these things is a huge deal if you've already printed the Base. The beeper works fine even if it slips out of its hole, and in any case a drop of hot glue will keep it in place if you really care. The base was made every so slightly stronger as it was found that over-tightening the accessory port screws could fracture it along layer boundaries. Just be careful with those screws if you already printed it.

  • LEGS no more PP balls, and front surface was made thicker as some people were reporting layer boundary splits with certain plastics when inserting the servos.

  • ELECTRONICS CADDY Better way to route the wires coming from the bluetooth module, it was found that it was too easy for the wires to get caught in the cap when screwing on the cap, damaging them over time, now there's a little bit of plastic to guide the wires away from the cap boundary.

  • ELECTRONICS CADDY BARS the tips of the bars are now rounded which makes it less likely for them to catch on PCB components, making it very slightly easier to install the PCBs for nano and servo controller in the caddy.

  • GAMEPAD BATTERY DRAWER It was found that after inserting/removing the drawer many times (like 50) the slider portion on the left could fracture along layer boundaries, it was a little too thin. Made both sliders a bit thicker and now seems to hold up indefinitely.

That's the main announcement! The rest is technical stuff if you care to know a little more about our development process.


I think its instructive from an engineering point of view to see the process I went through on the leg bearings, and please realize this is just one teeny tiny problem I worked on in producing this product! Every detail of the robot, the software, the game attachments, the scratch interface, has gone through a similar methodical, careful analysis backed by large amounts of time brainstorming, implementing, testing, and evaluating results, all in the name of making a better product.

The original prototypes of this kit did not use the PP balls as bearings on the legs, they instead did the same thing that the hip servos did, a hemispherical bearing was incorporated right in the 3d model. Those versions worked just fine, but occasionally you would get a print where the legs had trouble lifting the weight of the robot because there was too much friction between the 3d printed hemispheres and the leg hinges. A drop of silicon grease solved the problem, confirming it was a friction effect. Being careful to clean up the little hemispheres (drips during prints, etc.) and sometimes using sandpaper if they were too rough also helped a lot.

Not being happy with that, this past summer I experimented with several different bearings. I tried tiny skate bearings (worked, but too expensive) and several other things, but settled on polypropylene balls. They worked great, however they were harder to assemble, and it was pretty easy for the balls to slip out of your fingers and roll off the table, and it was a bit of a balancing act. For the hips (the servos mounted to the base) they were nearly impossible to assemble, at least with my fat fingers. Because the hips do not have to fight gravity to lift the weight of the robot, they were not nearly as necessary anyway. So I went to a hybrid solution where the hips used incorporated hemispheres, the legs used PP ball bearings.

I probably built 20 robots using the poly balls. I ordered a huge bag of them from a supplier (which will now sit in my "random parts box" for probably the next 20 years). Was all set to go on the PP balls.

A month or so ago I started getting concerned about the PP balls. My main concern was: (1) it makes it somewhat harder to assemble and (2) in a classroom environment, do you really want tiny plastic balls falling to the floor? Someone could slip. Toddlers might swallow them and choke. (We have warnings on the kit about that due to the screws and other parts, but a tiny PP ball might be much more likely to lodge in the windpipe.)

I also started getting feedback that they unnecessarily complicated the build process and made it harder for people who wanted to source their own parts.


I taught AP Physics for 6 years (retired last year) and of course I know that friction has two components: the surfaces that slide have an intrinsic friction coefficient (called greek letter mu), and the normal force applied from one surface to the other proportionally increases the frictional force. (Those of you who are actual engineers know that it is much more complicated than the simple model used in AP Physics, but for today's discussion this model of friction is sufficient).

I thought to myself: the PP balls fixed the problem by addressing the coefficient of friction, they are quite smooth unlike 3d printed components that have a layer effect, and PP has a pretty good mu. But what if, instead, I simply advise people to be careful about cleaning up the hemispheres to get a reasonable mu, but then also decrease the other component, the normal force? You need some level of force so the legs don't slop around on the bearings, but maybe the current model has an overkill of normal force (too tight in other words) which is causing unnecessarily too much friction with the hemispherical bearing.


It turns out that I could decrease the normal force by slightly changing the dimensions of the U shaped leg hinge brackets. Previously I had shied away from doing that as I did not want there to be too much slop in the leg bearings. Did not want a loose fit, that would affect walking performance.

I started experimenting weeks ago, trying various amounts of looseness on the leg hinges (basically just adjusted how deep the hole was to accommodate the servo horn). I was not sure if it would work, so I left the plans and 3d models of record as using the PP balls. That was still considered the main branch of the project until proven otherwise.

I completed the experiment just a couple of days ago. Built several robots with the looser hinges and incorporated hemispheres, without PP balls.

It was a huge success. Not only did every robot function perfectly (usually with no cleanup at all required on the hemispheres at least with my printer), but also it is quite a bit easier to assemble the leg hinges both because of the lack of the annoying PP balls slipping out of your fingers, as well as the looser hinge bracket is just plain easier to get over the little hemispherical bump. I said to myself, "wow why didn't I do this six months ago." But that's always the way it is, right? You tend to forget all the hundreds of attempts that failed and just assume you could have leaped right to the final fix.

There is no appreciable slop. Even without servo horn screws installed, I was able to run these robots for hours and the legs never slipped off, the walking gait seemed unaffected. (I do recommend putting in the servo horn screws, but it's just a good test of the fit and finish to see it work just fine even without the screws).

As soon as I was confident it was a better design (which was just yesterday early morning) I uploaded the new files to thingiverse and changed the build instructions to eliminate the PP balls.

If any of you did acquire PP balls, I apologize, but I did warn that this was considered pre-release, sometimes when your'e on the bleeding edge you get cut!

At this point, though, Version 1 is now considered stable for the robot, gamepad, capture the flag accessories, and joust accessories for the first release product. The fidget spinner and ultrasonic sensor bracket are still getting tweaked, what is posted does work, just making some tiny adjustments to make things look better. There are no other side branches in progress that would affect things.

Hope this was instructive to those of you who are into this sort of thing!

Backed the early bird basic kit! Thanks for putting this out there, can't wait!

I appreciate your support!

Like for Half-Life reference! <3

I'm really excited to build one. So many of the other hexapods and octopods on thingiverse seem to be little research projects with minimal software/kinematics. It looks like this thing has a lot of features baked in, so I've backed you and I'm going to start printing parts next week so we can assemble the bot as soon as it arrives.

Thanks to your team for all the work you've clearly done on this thing and for making it so extremely open. I can't wait to hand my kid a physical manifestation of coding in scratch.

Thank you for your support! I've personally spent a thousand hours on this project and I have several engineering students I hired to help me build it out. So yes, we worked very hard to make this a great project.

We're not done either, this project has LEGS. (Get it? Six of them to be precise). This is something that will continue to grow and evolve, especially with the help of the maker community. That's why we made it open source, we can see cool ideas we never thought of, and keep incorporating the best ones in future releases.

Just backed. If you hit your early bird shipping targets my kids will have fun building these over the Christmas break. Good luck on the Kickstarter.

Barring a natural disaster, all early bird units will ship far before Christmas, in fact well before Thanksgiving is highly likely.

First of all, congratulations on this design. It looks fantastic and I want one. Really, really impressive. I would also like to thank you by backing your kickstarter and ordering the electronics from there. However, doing so doesnt make any sense. Not for me, not for you. It would cost me $99 + $40 shipping. One alternative is buying stuff on banggood.
12xMG90: $27.6.
16 channel i2C servo board: $4
Arduino nano: $2.4
Bluetooth module: $3.5
3A BEC: $2.2
Buzzer: $1
potmeter, battery clip, screws etc basically free
Assuming I find something for the bearings, total sum would be ~$40 with free shipping. I suspect we would both be better off if I did that and backed you with 4 T shirts. But I dont care about the tshirts, so I'll just pledge you a donation. You do deserve it.

If you're doing a kickstarter, it might have been a better idea to make a single board that integrates the servo controller, bec, microcontroller, buzzer, and while you're at it, battery charger and RF. This board would be useful for other similar projects too. It may or may not end up cheaper than buying separate components off the shelve, but it would at least give you an edge over banggood and make it easier to build, smaller, more integrated. I would also have based it on a ESP32, they cost about the same as AVRs, are similarly low power, but have wifi+bluetooth built in and loads more IO and processing power, which could be quite useful if you want to integrate camera's, path finding etc. They can run arduino code (for the most part). Maybe an idea for version 2?

OH, and you should absolutely replace the printed eyes with 2x 1" oled displays and make it look and wink!

edit: I just realized Id probably need another arduino and BT module for the controller, but that hardly changes the issue. Especially for me, since I intend to use the ESP32 wifi and my phone as controller.

Thanks for considering supporting the project!

I do understand what you're saying, but it kind of goes against my grain to make a proprietary board just for the sake of making a proprietary board. Plenty of people do that when commercializing projects, I know that.

I think you're underestimating the value of the kit for most people (although I do hear you on the shipping, I wish it could be less to EU). We're doing quality control on every single servo before we ship them out. You will find that 10 to 20% of those cheap MG90s you're buying have bad gearboxes that freeze up within 20 minutes of using them, so I would suggest buying 14 or 15 instead of 12 just so you're not delayed. We're doing all the soldering, we're pre-flashing the Arduino modules, we're pre-configuring the bluetooth modules to auto-pair on boot. All of these things cut about an hour of build time off, or actually a lot more for people who are not as familiar with those processes. There was another hexapod project a few years ago who shipped unconfigured BT modules and some people online were saying it took them 5 hours to config. Now, you probably can do it in 10 minutes because you're likely fluent in the ancient tongue of AT commands, but a lot of people have never done that and will take a lot of trial and error. As your edit indiciated, you also left out about $10-12 of raw materials for the gamepad: SD card reader, SD card, two different button modules, nano, BT module, 9v clip, jumpers, etc. Again, you sound like you have the skills to rewrite the project to use wifi, and I say GREAT! I would love to see what you do!

That said, we made this open source precisely so people like you who don't mind doing those things can source the parts themselves. We made the project entirely 3d printed too, we didn't injection mold, just so Makers and schools with 3d printers could hack, remix, and modify to their heart's content. It would have been shinier and more appealing to the general public if we had done injection molded parts, but we wanted this to be hackable. We wanted a student to be able to say, "I 3d printed my own modified cap to make it look like my dog charlie". Ha ha!

Anyway, sorry for the long response! I run off at my keyboard. I deeply appreciate your support! Please share with us what you build and I'll highlight you on my website as a great example of the Maker ethic.

I just want to take a moment and thank both of you (P4man and vorpal) for being exactly the kind of makers I love to interact with in my daily life. Helpful, constructive comments with reasonable and insightful replies. I agree with P4man that there are other chips I'd rather toss in there than a nano, but I appreciate the amount of work vorpal's team is putting in to make this kit both accessible and open, with an attribution/SA license that frees P4man to go build a mobile controller or swap out the board and publish improvements.

Following both of you now. Thanks for being awesome humans.

Plasmaton, thanks for the kind words!

Love the robot, but 40 bucks shipping to EU is astronomical...

I hear you and I wish it was more economical. We ship priority international which has about a 1 week delivery time to the EU. There are cheaper options available but they would only bring it down to about 30 and you're looking at potentially several weeks ship time, and in my experience a much higher rate of lost packages. I have shipped the cheaper way in a prior business, and I got so many customer complaints I stopped doing it.

But look at it this way, even kits for most hexapods are normally $250 or more. Even with the shipping it's about half of what even an economy hexapod costs. Some of that savings is of course because you're 3d printing the parts yourself, but even adjusting for that, this is a very low priced hexapod with a ton of cool features that go well beyond what even some expensive ones have.

Kudos for sharing such a "fun" robot! My 9 and 13 year olds are both excited about building this.

We're having a few unexpected difficulties that I thought I'd share so you can improve this.

  • The parts list lacks sufficient detail especially for the electronics. For example, it took quite a bit of research to figure out the design is apparently using the Adafruit 16 channel servo driver.
  • The assembly instructions are lacking in pictures and detail. The most glaring example is the knee to leg "bearings", that are called out in the part list but not mentioned in any assembly step.
  • Speaking of knee bearings, they seem to be superfluous, the body has "printed in" bearings that work fine. Might want to consider printing in the knee bearings too.
  • The legs have a little "shelf" deep inside meant to support the servo mounting brackets. For our servos the shelf is misaligned and just prevents the servo from seating properly. It's a nasty bit of work to pull and sand out the shelf after the part is printed. It's not needed as evidenced by the main body servo slots. So I'd recommend just removing it, deepening the box.
  • We tried to "fix" the legs. OnShape will be amazing someday. But for now we find it obtuse and crash prone, so I'm not sure you want to steer children at it yet.

So far (aside from the servo leg shelf) this has been a blast! I'll add feedback as we get further along.

As an aside, we've built ours with PLA and so far nothing has snapped, even the knees (which require quite a bit of bending) fit together without heartbreak.


Thank you for your detailed feedback! I would love to see some pictures or videos of your Vorpal scampering around when you complete the project!

A few comments:

As mentioned in the thing description, the documentation is currently in pre-release draft format and we are working on more diagrams and even a video series to better demonstrate the build process. We expect to have everything finalized by our Kickstarter release date which now is officially October 20.

I have corrected several of the items you mentioned, such as not listing the specific model of servo controller and the lack of mention of the bearings.

Regarding the need for the PP ball bearings. At first we did have the built-in version of the bearings on the legs as well but the leg servos have to fight gravity while the hip bearings typically do not. We found that if you built the little ball into the leg, there would sometimes be too much friction for them to operate, and this could cause premature servo failure and inability for the robot to stand up sometimes. It would also reduce battery run-time due to the servos working harder. Lubrication was required to solve that problem, but that then adds a factor of messiness to the project, you don't want to get silicone grease on things.

I have considered publishing both versions of the legs for those who don't want to get the PP balls and who are willing to live with having to add a litle lubrication every now and then.

Regarding the shelf inside the leg, I am wondering what servos you are using? Are they MG90s or similar clone? If they are SG90s, that would certainly explain it since those have a little difference in shaft spacing. But I would caution that the SG90s have plastic gears and I'm not really sure they can withstand the forces Vorpal will put on them, especially the knees that have to fight gravity when standing up.

If you are using MG90s, its possible there is some dripping from the shelf in your print (there's a bridge there) which is preventing the servos from completely seating. Again, your suggestion of removing the shelf might also solve that by placing the bridge father away from the servo.

You could of course have used angle cutters to snip off the servo's plastic screw bracket. I've been know to do that when a draft model lacked a bit of room ;)

I will look at the model and see if getting rid of the shelf will cause any issues, you are likely correct that it will not, so thanks for the suggestion.

I have actually never seen onshape crash personally but of course with different hardware and browsers its possible you see things I don't.
The main project in the hexapod onshape folder is complex enough that rendering time can be significant depending on where you make a change (it can be minutes in some cases) and you may have interpreted that as a crash. Using the "roll to here" function in the feature list can substantially reduce rendering time by limiting your changes to just a certain part of the model. Onshape does also allow you to export the project in many different formats, perhaps you can export to a format for another CAD program more to your liking.

Thanks for the feedback on PLA, that is great to hear! Early versions definitely had that problem with PLA but I have made a lot of model improvements to make parts more robust over the past six months so maybe I should not be so down on it. I will try building a Vorpal in PLA and see if I should back off on the warnings.

Thanks for the quick and detailed reply. Three quick answers:

  • yes, we're using the SG90s. I have no doubt they will be short lived, but so are my children's attention spans and the nylon is half as expensive. I'll post a longevity update as they die so you can note the difference in your docs.
  • re the PP balls. they have been difficult for me to source in small quantities. We ended printing 1/4" balls in PLA to get it built quickly. Tomorrow I'm headed to the local sports store to get the closest smooth alternative I could find, which is 1/4" slingshot ammo.
  • they are both very comfortable in Tinkercad; I just need to struggle through getting OnShape to export a single leg to it so they can play with it there.


Regarding tinkercad: that is a really nice CAD system for kids, you can do a lot with it. I believe you can import an STL into tinkercad and edit it and that would be all you need to do to blow away the bit of plastic that's causing trouble for the SG90 servos.

Now about those SG90 servos...

SG90s have a different shaft spacing than MG90s, but beyond that they also have 20% less torque and are 10% slower, and have plastic rather than metal gears. Because they have less torque, they are going to draw higher current to lift the robot's weight, and higher current means more heat. Heat and plastic gears are a bad combination! Gears will soften up then start to strip. Because they are slower, the timing of certain moves like "scamper mode" may not work, because scamper mode really pushes the servos to their limits of speed so a 10% reduction in servo speed might throw the timing off too much, not sure. If the robot struggles to stand up and scamper mode fails to work, that's probably due to the SG90 specs not matching MG90.

I have used SG90 servos in previous projects and I found they are really only suitable for very low stress situations, those plastic gears strip very easily. The Vorpal Hexapod is not a low stress situation, you can see by the videos that the servos are being asked to move rapidly and lift the robot's weight frequently.

However, I will admit I never tried SG90 servos in this project, as I just assumed the plastic gears would quickly melt. I would be curious to know your findings, I appreciate you doing this experiment!

Regarding the lifespan of MG90 servos in Vorpal ...

The life of the MG90 servos is very good in this project. As long as you don't try to do ridiculous things with the robot they hold up very well. For example, Vorpal is being used by an after school STEM program. They currently have 5 robots (are increasing soon to 10) and these are used for hours every day. After several weeks of very tough usage with kids between 4 and 14, only one servo has died (out of 60 servos on all 5 robots). And that was most likely because a child dropped the robot onto a concrete sidewalk and stripped a gear.

One more caution about sourcing your own servos: there are a ton of MG90 clones on the market that are extremely low quality. One time I got a batch and 10% of the servos were bad out of the box. The gears froze up within 5 minutes of use. For this reason, when we get a batch of servos, we actually test every single servo before we put it in a kit.

So, you are getting a lot of quality control and thoughtfulness when you buy a kit from us. You know all the parts were checked, and you know all the parts are exactly correct for the project. We are very happy for people to build the project and source their own parts if desired, that's why we made it open source, but if you use the wrong parts or get a bad batch from some fly-by-night supplier, just remember that's the risk you take when you source your own parts! I know a lot of makers are fine with that and love to experiment, and that's cool as long as you know what you're getting into.

Thanks again for your feedback and let me know the results of your experiment with the SG90 servos! If it does work much better than I expect, we could even perhaps offer lower priced kits that use the plastic gear servos, perhaps with cautions about being more careful about usage.

Not sure if this is feedback or questions. We had a ton of fun soldering the header pins on the Arduino; it was quite a bit harder than the "works out of the box starter kits" we've played with in the past. But 6 hands and a lot of solder-sucking we succeeded. I'm totally on board with recommending your pre-wired kits for all but the die-hards. Programming the chip was mostly painless, but if you could drop references to the required dependencies it would save a bit code spelunking and web surfing (adafruit servo driver and pixy Arduino) -- on the other-hand I learned quite a bit figuring these out.

That said, I'm having trouble with the BOM and assembly.

  • the easy problem: I'm not sure what you mean by "beeper" with three pins. We've got active and passive piezos but they all have 2 pins.

  • more perplexing: As I read them, it seems the instructions want me to plug 7.2V into both the Vcc and V+ of the PWM driver, but I'm pretty sure if do this it will release it's "magic smoke" and it won't work anymore. Here's my data sheet details:

battery pack 7.2V (2 x 3.6V 18650 Li-ion in series)
PWM driver Vcc range 2.3V to 5.5V (The Adafruit 16 Channel Servo Driver/PCA9685)
PWM driver V+ range 4.8V to 6V.0 (MG90S)

(As an aside, I'm wondering why you don't bother with the polarity protected V+ input?)


Yes, the kit is significantly easier to build than self-sourced parts. Everything is soldered, programs already loaded on Nano, Bluetooth modules paired. The build is about 60 minutes for robot and 30 for gamepad if you use the kit, much longer otherwise. Actually I can build the entire thing in 55 minutes but I've built like 50 of them so that doesn't count ;)

Buzzer: I have updated the documentation to be more precise. I should have said "Passive Piezo Buzzer Module". I put a picture of the one we use (manufactured by Keyes) but there are lots of them that would work fine.

Note: if you're chomping at the bit to build, just leave the buzzer out for now. You will lose some beeps that help give you feedback on buttons pressed and record mode, but the robot should still work fine without the buzzer. You can always add it back in later.

Servo Module power question: If you look carefully at the circuit diagram here:

You will see that on the Robot circuit there is a 5V BEC in between the battery and the servo controller. The nano gets battery voltage to its Vin which is then regulated on the nano to +5. The nano cannot provide enough power to the servo controller, however, so the servo controller uses a BEC to provide regulated power at +5v. So we are not feeding +7.2V to the servo controller! Please don't do that as it will probably fry instantly.

A BEC (battery elimination circuit) is commonly used in RC cars and boats to power circuitry, and this one provides 3 amps of regulated +5v power. Because the BECs we use already have a Dupont style connector, it was easier to just plug it in to an unused servo controller port rather than cut the connector off and use the screw terminals, but that would work fine as well.

Thanks for your feedback! I am looking forward to seeing you post some cool pictures of your robot!

Oh! Yes, the battery assembly documentation is very good; I have no idea how I missed reading those before, duh! One small suggestions to help avoid the same silly RTFM in the future, maybe the "electrical connections" section of the assembly instructions could be more explicit about plugging the "regulated +5V BEC output" into the servo driver and the "unregulated/direct leads" into the Nano.

Speaking of very good, the serial monitor logging you put into the firmware is pretty much at the Goldilocks balance of verbosity; it's super helpful for measuring progress as we build this out incrementally. Thanks!

And we've had some exciting progress. I'm unsure what the power drain verses the amplified beeper circuit is, but we wired a passive piezo in series and our robot is happily beeping at us. Even more exciting, we have a fully assembled and working leg! Only one is wired up right now until we get the BEC, but even with one leg it's pretty fun to cycle through the different modes and see the leg wave and wiggle!

That sounds like terrific progress! Thanks for the kudos on the debug output. If you print too much stuff you start to drop bluetooth packets and the gamepad gets laggy, so it has to be a balance.

I am planning a more extensive debug system that includes multiple levels of verbosity selectable via a #define at the top of the code. I'm even considering allowing debug modes to be enabled/disabled via the gamepad. Like, you boot the gamepad while holding down two magic buttons and it goes into debug mode where the buttons let you easily test different aspects of the robot and select different levels of serial port monitoring. Like the current dial selectable "one leg at a time" debug mode but on steroids. Ability to monitor sensors, arbitrarily move one leg at a time to their limits, track and display bluetooth packet statistics, etc. Always more to do in the next release!

I was a bell labs distinguished software engineer many years ago, and I learned at a young age that debugging and tracing scaffolding should be built into a product from the start and not be an afterthought. Any time you spend developing good trace/debug tools will repay itself many times over during a product's life cycle.

OMG, our robot danced today and you should have seen the huge smiles on the children's faces! We have had a blast and half building this, it's just the right balance of hands on problem solving and pre-programmed amazing behaviors. I'm totally in love with the firmware: the dead simple mode-dial, the variety of ready to go debugging and adjustment behaviors, and most of all the "random" mode that has our robot dancing and scampering and FUN long before it is even complete -- we haven't even built the controller or attached the BT modules yet.

I stuffed a picture of our new black and gold friend and its parts list (parts used so far) in the "I made one" section. I'll add a video if I can figure out how. Thanks again for making this experience possible!

Wow, I am blown away by your kind words! This project has been occupying just about every waking hour for me for the past 16 months and it's great to hear that it's working so well for you. Your build looks great too!

Hey don't forget the eyes when you get around to printing them. I have found that people react to the robot entirely differently with the cute eyes attached. Very small children are often afraid of it without the eyes (looks like a spider) but with the eyes they love it.

There are two versions of the same part in the ZIP. What version is the most current to print, the one without a number or the one with a version number?

Sorry about that. I could swear I deleted the older versions after I uploaded the new. i have corrected the project now and eliminated the older files. The ones with the V1r8 were correct in any case.

One more small remark. It might be helpful if the STL's for the legs are provided as single items, rather than one file with all 6 legs. I printed the file, and my printer had an error on one leg, and now I have to print all 6 legs again... very time consuming.

Awesome project that seems to include everything you need to make a robot. Very complete and well documented. I'm gonna build this for my robotics class. Super surprised no one has made one yet. Was probably gonna do all the programming in Arduino C, for routines and movement but I am also gonna check out scratch (you even did that part!). On the kickstarter page it says 'ships November'. Probably can't wait that long as I will need to finish this about that time.

Thank you for posting this project and making all of it open source.

Very cool hexapod.

Wanted to ask about the code. In the description, it says "Arduino Source Code and Scratch Extension code is posted publicly on GitHub. Just search for Vorpal Combat Hexapod.".

However when I try to search for it on Github, there doesn't seem to be any repositories matching "Vorpal Combat Hexapod".

Is the code just not available yet? Is this being made available after the kickstarter campaign is over?

Yes, sorry about that. I have corrected the thing description. It is indeed github.com/vorpalrobotics/vorpalhexapod

This is considered pre-release software, official release is Nov 1. It is quite stable, but be prepared to reflash your nanos later.

Thank you! Please tell any of your maker friends! I need some help getting funded to bring this out to schools and makerspaces and places like that, so spread the word if you're able. Feel free to repost the videos to your facebook or other social media if you do that kind of thing. My youtube channel has some very short 10 second videos that are great for posts.

As you can probably tell, I spent about a thousand hours on this and I want to get it out to the world. I donated 8 to a summer camp for appalachian girls this past summer, and they loved it. Some of them actually said it motivated them to learn about computers. (They programmed the hexapods in Scratch).

Thanks again!

Fantastic little robot! well done!