Loading

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!

17 Share

Thing Apps Enabled

Order This Printed View All Apps

Summary

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 have our own store. We have more than just the Hexapod electronics, we have all kinds of things useful for small robotics and other projects:
Vorpal Robotics Store with Hexapod 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
Thing 2615267: Vorpal Hexapod Stand

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:

LulzBot

Printer:

Mini

Resolution:

Tested at 0.38 mm layer but should work at other settings

Infill:

15% recommended


Notes:

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

Standards

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

Downloads

Size

All Apps

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

Has anyone considered building in blinking eyes on tiny oled displays in the top cover?

This has been mentioned in these comments a few times. I have some little i2c oleds on order right now to do some investigation.

I am in the process of building one of these with my daughter and I have to say that these 3D files are very well designed with just the right amount of flexibility to work on any 3d printer and still fit together. Very nicely done. I plan to port the arduino code over to a raspberry pi w zero for the added flexibility of wifi and ble built in.

Thanks for the kind words! Would love to see a pi version!

Hi, I bought your kickstarter kit and just finished my build tonight. The hexapod is working perfectly in the test and demo modes, but I haven't been able to control it remotely. I haven't spent anytime trouble shooting it yet, but I suspect I may have the bluetooth modules mixed up. One had a red dot on it...is that the master or the slave?

Thanks for designing such a cool project!

I scrolled down a bit and found a link to the google forum where I was able to learn that the red dot is meant to identify the master. Mine are in backwards, but it appears that might not be my problem since that forum post says it doesn't matter unless you plan on using the app in the future.

Yes the two modules form a transparent serial connection regardless of which is master or slave. But only the slave can connect to an android app so if you want to use an app the slave has to be in the robot not the gamepad.

The Trouble Shooting page on the wiki has information about the most common issues that stop this from working, and there is also a thread on the forum specifically about debugging gamepad to robot connection issues.

Hallo everyone,
I 've built the hexapod with spare components and I have an issue with the gamepad.
I've tried the debug ino and what I found is the following, no matter which button I press the same endless stream of "strange" characters appears.Do you have any clue about this behaviour?

Thanks

You should be seeing things like:

W1s

with no buttons pressed. Pressing DPAD buttons should give you things like:

W1f
W1b

depending on which DPAD button is pressed.

If that's not what you're seeing, please give me an example of what you see. If its total garbage characters, you might have the wrong baud rate set on your serial monitor, it should be 9600.

thanks for your quick response, you were right baud rate was set wrong.
I've made the Dpad by myself with a bunch of resistors and buttons and I think the problem is there, every buttons seem to return the right character except the left one of the dpad furthermore the dpad is continuosly sending #S=F3s command.when i press another button appear few lines with the related command and then #S=F3s starts again-
TX led of the nano don't stop blinking

ANNOUNCEMENT: The Vorpal Robotics Store is now open!

http://store.vorpalrobotics.com

Spare parts, hexapod kits, and over time we'll be releasing new add-ons and even entire new kits. Many of the parts are great for any small robotics or other Arduino projects.

We're running a Grand Opening sale right now, 40% store credit rewards on every purchase (not including shipping and taxes). For complete details see the Store Credit Rewards FAQ posted on the store site.

Good time! Please tell me. Where can I buy a DPAD button module. What article? Not missing a beat.

The vorpal store is slated to open this weekend with a big cyber Monday promo, stay tuned!

Hello friends.
My Idea is to use mobile instead of RC (sometimes)
Here is an alpha version with basic functions: "VorpalHexapod V0.1A Remote Control" at http://ai2.appinventor.mit.edu/
Feel free to use, modify, or anything else....
My code is Public Domain...

Been working on my own atm with some parts I had laying around, do you happen to know where to get the D-pad module? or is that just something that can be made?

Have you gotten yours yet. I bought some from that same listing on Oct 27th. Still hasn't arrived. Tracking just says it departed China. Ordered all the other electronics from other sellers on the same date and they all arrived a week ago. Think mine may be lost.

Yeah it took a few weeks, that's the downside of ordering from China. I've had things come in after a week up to a month or two. Had a few things lost before as well.

ANNOUNCEMENT: Vorpal Robotics Forum is now open to the public!

The group is here: https://groups.google.com/forum/#!forum/vorpal-robotics-forum

WHY DO WE NEED THIS?
I have been getting questions about the hexapod from thingiverse, facebook, personal email, kickstarter messaging system, indiegogo messaging system, and more! This means my answers only go to a limited number of people, often just one. In addition, thingiverse comments are great, but there is no way to create categories of different kinds of topic so with 149 comments arranged only in date order, it's getting a bit hard to find information!

I decided it would be more efficient to have a forum specifically for Vorpal Robotics projects. I chose google groups (after some research). Primarly because, a large percentage of people already have a google account of some kind (gmail, youtube) so it's likely most of you won't have to create "yet another login id" to use the group.

I will continue to monitor and answer questions here and in other places, but would prefer if most questions and comments transition over to the Vorpal Forum.

Thanks!

This is a great idea. I thought it was annoying to have to jump between Kickstarter comments and Thingiverse so I wouldn't miss anything. I bet you were having quite the media barrage!

I'm having a problem getting servos to center reliably.

Just sitting still with the knob on Stop, 6 hip servos connected, over time the servos slowly move to one side until they can no longer move any more. same thing in Test mode, the center position keeps shifting to one side until there is no more room to move. The servos are not jittering, they just slowly shift the center point to one side.

Some channels are less effected than others. I added a 2200uf cap to the servo driver and switched the servo driver logic Vcc to run off of the Nanos 5v rail. These changes helped to stabilize the positioning but the problem still persists, I just slowed the process down with these changes.

I've run all the servos on one of my RC receivers without issue so I'm pretty sure they are OK.

I'm suspecting a bad servo driver or BEC but I will need to hook my scope up to do further debugging.

Just wondering if anyone else has run into/solved this problem already.

Helloz~hotaman

I think you can use a new servo http://www.kynix.com/Product/Cate/133.html or BEC to try again.

Hey Hotaman,
The behavior you describe sounds like what I was experiencing with a BEC that just couldn't handle the servo load. I scrounged electronics myself so I was not working of the standard kit. I would run the DEMO and between 2 and 8 seconds in some of the servos would start to 'fail' - slowly move to one side and in a few seconds all the servos slowly wnet from center to max travel. The hexapod looked like it was curling up and dying like a big bug sprayed with poison.
I replaced my BEC with this one:
https://www.amazon.com/Servo-Helicopter-Airplane-Receiver-Supply/dp/B00VI0L94C/ref=sr_1_1?ie=UTF8&qid=1509603209&sr=8-1&keywords=servo+5v+3A
which is what I think you get in the kit and the problem was gone.

Thanks for the response JJohnson98. Yes that sounds very similar to my failure but I found that not all servos failed over time. I'm using a Racestar 3A BEC and it is working as expected. See comment below for more failure info.

FYI: My bench supply shows a max of ~0.6 amps running test mode on the bench (no load, bot on stand)

Hotaman,

I have built at least 50 of these robots personally and have never seen that. It sure sounds like a bad servo controller, although I personally have not come across that so it must be an unusual defect. I can't think of why a bad BEC would cause it, although anything is possible. You can easily see if the bec is holding +5V or if that's drifting up or down.

If I'm understanding you, just the hips shift? Or do the knees and hips both shift? It almost sounds like the clock on the servo controller is drifting so the pulse gets longer (or shorter, you didn't say whether they're shifting CW or CCW).

Did you buy a kit from Vorpal Robotics, or did you source your own parts? If you bought it from us, we'll send you a new servo controller, just message me in kickstarter.

Thanks Vorpal, I sourced my own parts for the first 5 due to budget constraints. I work in K-12 serving 48 districts directly and the entire state indirectly so I know my demos will generate hundreds of orders for you!

I had the exact same first thought, but after scoping the PWM signals running power from my bench supply, the problem turns out to be the servos. The PWM outputs are rock solid at ~1.58ms @ center. Further investigation showed it is related to hinge friction. I didn't realize that the ball and socket are just for positioning, there is ~1mm of clearance between the ball and socket. Cleaning up the 'faces' especially around the embossed numbers eliminates the problem on the bench. The servos are still not behaving well, they actually shift their center point so there are firmware issues in the Tower Pro servos I received. We will see how they perform off the bench soon. If they fail in actual operation then my servo failure rate will be in line with what you are seeing and I'll need more servos!

Thanks for setting up the group, I'll put future comments there, just wanted to close this one out here.

Thank you for promoting the project!

So, when you say, "The Tower Pro Servos I received" I hope you realize that most servos marked "tower pro" are fakes that never came near a tower pro factory.

Yes we are consistently seeing 10 to 15% failure rates among the low cost MG90S servos. That's why we test them all and reject the bad ones before anything goes in a kit.

All you need is one servo which has bad gears, and it can suck down so much power it causes all the rest to fail to work, or worse yet causes the BEC to go into overcurrent protect mode, or brown out the nano and BT module.

Vinoh: yes, no problem; BT modules can be paired with more than one other module.

Vorpal: I saw your earlier post about a simplified protocol. That would indeed take the hassle out of all the ascii conversions.
But it was fun to get it working though !
Printing the distance sensor holder at the moment, expecting a Pixy tomorrow .. So much to do, so little time. ;-)

hazes2, I've been looking up pairing instructions for the HC-05 and it's pretty confusing. I loaded RoboRemo on my Android phone and would like to connect to the robot. However I really don't want to mess up the existing pairing with the Gamepad. Would you mind summarizing the steps to do this or perhaps point me with a link to the correct method. Thanks. --Dave
PS I'm having trouble getting the Google group to accept my posts so I guess we should continue the discussion here for now.

Please note: Pixy code is currently not "turned on" in the robot code, although the protocol plumbing is in place. I expect to turn this on in early december after I have more time to test things out.

Comments deleted.

Vinoh: go to the BT menu on your phone, have it scan, select the HC-05 module, pair it (pin 0000 or 1234, the normal defaults). Assuming the module that came with the kit (I think you ordered the kit) still has the default code. @Vorpal: Pls correct me if I'm wrong here.

Open RoboRemo > menu > connect > BT (RFCOMM) > HC-05. And start adding buttons. Which, as written, requires some knowledge of the protocol. Nicely documented in the wiki.
Note: the button has to be defined as 'local', with the text 'sendhex' as I wrote below.
Also to keep the Vorpal moving the codes have to be repeated as you keep the buttons pressed. Also configured in the button menu.

Vorpal: Yes I saw that the code for the Pixy is still in development. But great that the foundation is already there. I love tinkering with it.
Very nice structured code btw; easy to understand and work with.

Ah, I didn't realize it was always in pairing mode. Cool! Works great! Unless I see a reason to use it immediately, I'll probably wait until Vorpal creates the simplified protocol to go further. Also, if I understand it correctly, it's easy to import and export configurations with RoboRemo so we could share them pretty easily.

While waiting for the second bluetooth module (for the DPAD) I stumbled on a nice generic app to control Arduino's, ESP's etc.: RoboRemo
Configure a button with for instance command "Walk mode 1 forward (W1f)" with the "set press action" : 'sendhex 563103573166F10A'
Yes, hex codes are needed, so for instance http://www.asciitohex.com is handy here.
56= hex for the literal 'V', 31 for 1, 03 for the nr of payload bytes, 57 for 'W', etc.

Thanks a lot to Vorpal for the protocol wiki and this great fun project in general. A contribution is on its way !
I also paid for the full version of RoboRemo, otherwise it is limited to 5 buttons/sliders etc. But money well spend on that app I think as well.

Wow, nice. I think I saw that app a year or two ago but forgot about it.

I am planning on upgrading the robot software so it will accept a much simplified protocol in case others want to use similar apps.

The simple protocol will simply be: @W1f
Meaning:
@ What follows is a simple 3 letter spec indicating which button was pressed with no checksum
W The "W" row of buttons
1 The "1" column
f The DPAD forward button

The only error checking will be that the first of the three chars has to be one of WDF, the second has to be one of: 1234 and the final has to be one of: fblrsw (forward, backward, left, right, stop, weapon, where "stop" means nothing on dpad was pressed and "weapon" is the button on top).

If any of the characters does not match one of its expected values, the entire packet is discarded. This should catch a huge percentage of data errors but requires no checksum.

Of course, record mode and scratch mode will not function, but you'll be able to drive to your heart's content.

On this future protocol upgrade - will both the current mode and the ASCII only mode be supported at the same time?
I think it would be a useful feature. When I had to do some debugging of the Bluetooth/Serial connection and it would have been really handy to just send some commands over a standard terminal to test things.

Very intriguing! I'm looking for an iOS app that would do something similar but could use a leftover android device for this. Do you know if you can pair the bluetooth module with more than one device, connected to one device at a time of course.

Perhaps you would want to start a discussion about this on the Steve's forum in Vorpal Hexapod Makes, Mods, and Hacks. https://groups.google.com/forum/#!categories/vorpal-robotics-forum/vorpal-hexapod-makes-mods-and-hacks

Comments deleted.

Busy over the weekend building the first of two Hexapods. I was just wondering if there was a complete labeled drawing showing all wire connections. All connection, from here to there. This sure would be handy to check and recheck before initial power up. This is a great very well thought out design and kit. I would just hate to fry the bacon. Instruction pages are great, but lack the overall picture. Many newbies lack the knowledge of connector names and "the red wire" does not help when there are 3 or 4. Bobbyt

Yeah that is something that's on my "To Do" list and we should have that posted soon.

The main things that can fry the electronics are:

  1. Hexapod: Make sure the raw battery power (red and black individual dupont connectors coming off the switch assembly) are going to VIN and GND on the Nano. You will fry the nano if you connect the red to +5V instead of VIN.

  2. Hexpod: Make sure the double dupont connector coming off the BEC goes into the Servo controller in the correct orientation. You can use any unused servo port (anything above 11). But make sure the black and red sides are oriented to match the coloring on the servo controller port.

  3. Gamepad: Make sure the red and black dupont connectors coming off the switch assembly go into the nano VIN and GND. Again do NOT put that red wire in +5V, put it in VIN. that's raw battery voltage not regulated.

  4. Make sure bluetooth module +5V pins are connected to regulated 5v power.On both the robot and gamepad, we're taking power from the +5V pin on the Nano, and using the unused GND on the nano to provide ground to the BT modules.

  5. Make sure the SD card reader on the gamepad is taking power from the correct pins on the ICSP header on the nano. There is a diagram in the instructions showing which ICSP pin is ground and which is +5V.

If those things are correct, other wiring problems are highly unlikely to fry anything, other kinds of mistakes will just result in things not working properly, not smoke coming out of electronics.

Hope this helps!

In the ROBOT BOM in the building instructions there is a 'stand' listed but I don't see a model for one in the files.
http://www.vorpalrobotics.com/wiki/index.php?title=Vorpal_Combat_Hexapod_Building_Instructions
The 'stand' is also mentioned during the assembly instructions to place the hexapod on to check out all the servos.

I mean the can of beans I'm using now works fine - just wonder if there was something cooler I could print.
Maybe I missed it? Thanks.

OK, the Stand is posted! See: https://www.thingiverse.com/thing:2615267

Enjoy,

Steve P.

Vorpal Hexapod Stand
by vorpal

Yes! My hexapod is enjoying his sweet new stand. Thanks!

That was an oversight, I will try to get that posted today. Thanks for pointing that out!

Anyone found a compatible on/off switch part number or url?

Hello,

You have three options:

(1) find a 9x13mm switch
(2) Use any switch you like, but just keep the switch inside the robot, sticking up such that removing the CAP piece allows access to turn the robot on or off.
(3) Make your own custom adapter for another sized switch which is not 9x13 but would still generally fit in a hole the size on the robot.

The adapter system can be used to make any switch reasonably close in size work. You simply design your own adapter, which is typically just a small rectangle of plastic with holes that match the two screw holes on the robot, and a central hole that fits whatever switch you want to use. I specifically designed it this way so people building using their own parts would have some flexibility on the switch.

This could be used for any switch that is equal or smaller than the 10x14mm hole for the current 9x13 switch. For example, you could use a panel mount toggle switch with a 1/4 inch round mounting shaft, or a rectangular switch smaller than 9x13.

If you do design an adapter for another reasonably common switch size, and you make it open source and post it to thingiverse, we would be happy to point to it from our wiki so people in the future have more options on the switch size.

Hope this helps!

I had a tough time finding this switch. I believe looking at the datasheet the KCD11 switch will fit:
https://www.jameco.com/Jameco/Products/ProdDS/2208198.pdf
Google "KCD11" and you'll see a bunch of places to buy - ebay, Aliexpress, Amazon.

I ended up using this switch myself:
https://www.digikey.com/product-detail/en/zf-electronics/PRK22J5DBBNN/CH865-ND/1083858
since I was ordering a bunch of other stuff from Digikey and didn't want to wait for the China shipment. That switch fits a bit loose but it stays in place and worked for me.

Am i suppose to print the base even though on it it says "Demo TST STOP"

Those are labels for the dial. Turning the dial to STOP causes the robot to stand still, TST puts it in a test mode for checking servo motors, Demo puts it in an automatic demo mode so you can try it before building the gamepad or just let it run in a display case or something. The other setting, RC, makes it respond to radio control from the gamepad.

So yes, go ahead and print the base!

This looks great and im looking to make this myself so i am sourcing my own parts. The one thing hanging me up are the servos. You mention that the cheap ones have a chance for coming with poor QA and end up seizing. Is there a brand you are aware of that has better quality than others? Id like to support you directly by getting your kit but self sourced parts come in at half or less of the cost of your electronics kit. The extra cost is not exactly justified for your hand picked servos unless you guys are getting ALOT of duds per order and thus need to build in that cost.

We have had batches of 100 where 20% of the servos were dead or died within 2 to 5 minutes of testing (with NO load on the shaft and at 5 volts which is 1 volt under the servo spec!) The average is currently running at 11.5% defective (we've processed over 2000 servos already from multiple different vendors, we chose vendors with lower fail rates of course but all have relatively high failure rates).

We can sell you just the servos for $4 each with $7 USA shipping, if you want. Our store is opening pretty soon, but for now you can just send us the amount using paypal to pend@vorpalrobotics.com if you want to take advantage of that. To answer your specific question, I don't know of any vendor who will sell you tested servos or higher quality servos at a price lower than $4 each in small quantities (where small is defined as less than 1000 units).

I would also like to respectfully point out that self-sourced parts sometimes will take weeks to arrive, and we have a lot of value add in our kit beyond just the tested servos. We have a pre-soldered electrical system ready to go, the Bluetooth modules are preconfigured to auto-pair on boot, the nanos are already flashed. There is the convenience of just ordering one package without having to do a lot of research.

Basically, you add at least 1 hour of build time by sourcing your own parts (and that's if you know what you're doing--for example configuring the BT modules is something a lot of people have never done before and it is quite arcane and not a little tricky), and you probably save another hour by not having to track down a whole bunch of parts from one or more vendors. With the kit, you know everything is exactly the right part and you can concentrate on building the project.

That said, we made this project open source and we used common materials with no proprietary boards of our own specifically so people who want to can source their own parts if they're willing to deal with the extra stuff they'll need to do.

I mean't no offense with my post. I totally understand the added value of a premade and tested kit. Thanks for the offer to sell just the servos. I will keep it in mind and I may end up doing that at a later date if that is ok. I ended up getting all the other electronics of aliexpress already. With spares of course in case of dud. Mostly just worried about the nano clones but folk on the arduino reddit seems to think they're fine. Restt of the spares will likely end up for a second because someone I show this to is probably going to want one. Since I won't have time to build this for a while I don't mind the wait for parts. Plus half my fun comes from tinkering so I'm totally up for soldering and programming myself. Think I found a pretty straightforward pairing tutorial too (https://alselectro.wordpress.com/2014/10/21/bluetooth-hc05-how-to-pair-two-modules/). I know my way around electronics and arduino so this should be ok to do myself.

No offense taken! Just clarifying my point of view for those who will read this thread in the future!

You sound like you're a lot like me, boxes of parts, sensors, servos in the basement and a bunch of projects going on at a time.

Yep! But I wont have a basement until late December when I close on my house. For now its the pretty much unused dining room of my apartment with a 3d printer that has been going non stoo since i got it last spring.

Need an application to control in mobile phone.

Yes an app is in the works, projected release around January.

Hi,
Could you give me an example of the bluetooth data being sent,

Im guessing (wrongly) something like "V1L8w2f" but i know thats not right but cant figure it out.

Thanks

I have read that but i cant figure out what it all means

What missing from the command V1L8W2F which should be walk mode 2 forwards

OK, you're putting the literal letter L for the length byte. That's supposed to be the actual length as an unsigned number from 0 to 255 (a single byte integer) not the literal letter L.

To send a walk 2 forward command you need:
byte 0: The literal character 'V'
byte 1: The literal character '1'
byte 2: The numeric value 3, which is the length of the payload (The payload is W2F, 3 letters long). As an ascii character, this is Control-C, AKA "end of text" character.
byte 3: The literal characters 'W', '2', and 'F'
byte 4: The checksum of 'W' + '2' + 'F' + the length byte which is 3. Checksum is modulo 256.

In this case, the checksum is the ascii codes of W, 2, and F added together with the length of 3 (i.e. in decimal: 87+50+70+3 = 210 which is already in modulo 256)
So in 8 bit ascii, the checksum, decimal value 210, would be a capital E with a grave accent I believe. You can look up tables of ascii codes on the internet.

Sorry for the complexity, but for technical reasons about one out of every 250 bluetooth packets gets corrupted, so it was necessary to wrap an error detection protocol around the simplistic data.

Whenever the robot gives a little short chirp in bluetooth mode it means the robot rejected a bad packet. You'll hear this every five to ten seconds depending on how noisy your 2.4 ghz environment is.

Hope this helps!

So that would be "V1ĈW2FÊ"

Ive being trying to send a command from an generic android robot app without much success

Comments deleted.

Yeah, the project wasn't designed with that in mind. You would have to be able to send control characters (i.e. 8 bit numbers, not necessarily typical printed characters) for that to work.

We are working on an android app, projected to be ready by January. This would allow people who don't care about scratch to build a somewhat cheaper version of the project that does not include the gamepad.

But I'll tell you: the gamepad is MUCH easier to use for real activities than an app. Having physical buttons lets you learn to control the robot without taking your eyes off it, you can do it by feel after a little practice. From a practical point of view, do you really want to hand your phone to a 5 year old relative who wants to drive the robot? LOL I have done that with prior products I developed and it was SCARY. They drop stuff a lot and they randomly hit buttons, I was always afraid they'd start deleting my emails by accident and stuff.

But yeah, an app would certainly round out the product and we're on it.

I just realized we could potentially add a new protocol format which is completely printable characters and doesn't use checksum error detection to help out people who want to use generic robot apps.

I am too busy right this second fulfilling kickstarter orders to concentrate on it. But it would be something like this:

@W1F

The @ character would mean: The following 3 characters are simple gamepad commands with no checksum or other protocol included.
If the following 3 characters do not have a valid gamepad sequence interpretation, then the packet would be discarded without being executed. That would be the only form of error detection.

Give me a week to get caught up on stuff, I don't think it's very hard to get that working.

No rush, i was just playing around seeing what i could do

On the wiki, it says the final version of the 3d parts will be available October 20th. Does the files currently on thingiverse are the final version?

Yes what is posted now is considered final for release 1.

I'm super excited. Just finished printing the last parts and I'm ready to assemble. I'm eagerly awaiting my shipping notice. Got the survey filled out the day it was released - any way of knowing which shipping date we're in?

Steve will let you know via the Kickstarter message centre when your kit ships along with the tracking details. This is as per the most recent project update. My kids are asking daily now when the parts will arrive. :)

Hi, I am sourcing all the parts for this and was wondering about the hc05 bluetooth modules. Is it the same module in both the remote and the robot? Also when I search for them some say master slave, or serial pass through. What exactly do I need for that? Thanks

All HC05 can be either master or slave. You need to configure one as master and one as slave. All HC05, when properly configured, provide a transparent wireless serial connection. There are numerous tutorials on the internet on how to configure HC05 modules.

Hope this helps!

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?

Hello,

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.

Thanks!

Hello,

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.

Hi,

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:
https://www.amazon.com/eBoot-LM2596-Converter-3-0-40V-1-5-35V/dp/B01GJ0SC2C/ref=pd_sim_23_1?_encoding=UTF8&psc=1&refRID=V6ZHYJFDQ8RJQJ416FQM

https://www.amazon.com/Qunqi-MP1584EN-Step-Down-Adjustable-Converter/dp/B014Y3OT6Y/ref=sr_1_4?ie=UTF8&qid=1508016285&sr=8-4&keywords=5v+buck+converter

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?

Hello,

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:
http://www.martyncurrey.com/bluetooth-modules/
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

Hello,
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"
http://www.vorpalrobotics.com/wiki/index.php?title=Vorpal_Combat_Hexapod_Building_Instructions

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.

Joe

I'm also having trouble printing the cap. I resliced the file and it failed in the same place. The 2 right most ribs start to bow outward and then aren't connected to the top. I was playing safe and using supports. I'm trying one more time with no supports to see if they are the source of the problem.

Update: printed perfectly without supports.

There is a non-skeletonized version posted for people who have trouble printing it.

I am planning to make the skeletonizing less extreme in the main line version, but right now I've frozen the design while I'm delivering my Kicksarter orders.

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?

Hi,
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.

Thanks

The 4x4 matrix is marked YL-102 and I found it on ebay here:
http://www.ebay.com/itm/Arduino-4x4-Matrix-16-Keypad-Keyboard-Module-/322452729648?hash=item4b13ae2f30:g:opEAAOSwB-1YyL6Q

The 5 key dpad is made by Keyes and is marked KEYS_AD_KEY and jjohnson's find on ebay looks correct:
http://www.ebay.com/itm/Analog-Button-AD-Keyboard-Electronic-Blocks-Simulate-Five-Key-Module-for-Arduino/152690338984?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

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:
http://vorpalrobotics.com/wiki/index.php?title=Vorpal_Combat_Hexapod_Battery/Switch_Construction

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?

Hello,

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:

ADVANTAGES OF STAND ALONE GAMEPAD:

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!

DISADVANTAGES OF STAND ALONE GAMEPAD:

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.

DECISION

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!

Hello,

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.

IMPORTANT UPDATE!

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.

COMPLETE LIST OF UPDATES for V1r8a

  • 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.

THE (EXTREMELY DETAILED) STORY WITH THOSE POLYPROPYLENE (PP) BALLS

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.

FROM HEMISPHERES TO PP BALLS ...
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.

FRICTION REVISITED

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.

BACK TO HEMISPHERES!

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!

STABLE NOW
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.

Hello,

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.

Hi,

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?)

Hello,

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:
http://vorpalrobotics.com/wiki/index.php?title=Vorpal_Combat_Hexapod_Battery/Switch_Construction

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.

Thanks!
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!

Top