3D Printed Sword: Design

After OpenADR was not selected as a finalist in the Hackaday Prize Automation Challenge, I decided to take a brief break from working on the vacuum after working in full-fledged competition mode for the previous few months.  I spent a few weeks trying to think up simple projects that would keep me occupied but wouldn’t take up too much of my time.  I also wanted to use this time in between big projects to develop new skills and get outside of my comfort zone a little bit with a project that I wouldn’t normally pursue.  At last, inspired by the wide array of medieval props I saw at the Pittsburgh Renaissance Festival, I decided to 3D print a medieval longsword and attempt to make it as realistic as possible.

Challenges

While 3D printed parts certainly aren’t new territory for me, designing a realistic weapon really pushed me to think through challenges that I had not encountered before. Creating large and unwieldy objects using FDM introduces new constraints in terms of printability and strength.  When creating my own parts from scratch, I have a lot of flexibility and can design pieces while keeping in mind the limitations of 3D printing . For this project though, I had to rethink the design process to make printing possible because I was trying to replicate something that (1) exists in the real world and thus should look a certain way and (2) wasn’t designed to be easily 3D printed.  Strength is also a concern as 3D prints are notoriously weaker than regular, injection-molded plastic parts and can delaminate when too much stress is applied across the Z-axis. I wanted the sword to be as realistic as possible (i.e., long and pointy), so keeping the sword sturdy without too much bending was also a big priority.

In addition to the 3D printing structural challenges, appearance was also a big concern – this too is where I wanted to push myself.  It isn’t easy to pass off a plastic part as metal given the differences in texture and shine.  Furthermore, given the size of the sword, I had to print the blade in segments, and so finding a way to smooth out the joints was a significant problem in addition to the normal visibility of  layer lines. Just designing, printing, and assembling the blade (a.k.a. all the things I already knew how to do!) was the easy part – the bulk of the work was in the finishing stages of making the sword look realistic.

Design

I started this project by researching the general properties of longswords.  I spent a lot of time looking at modern replica swords, movie swords, and historic swords from the middle ages so I could get a good idea of what I wanted my own sword to look like.  Two great references that I found were the Wikipedia page for longsword and the website My Armoury, which has more history, mechanics, and specifications of medieval weaponry than you could ever possibly need.

From those resources, I determined that I wanted a sword, roughly 1.1-1.2m in length, with a blade about 90cm long, 5cm wide, and 5mm thick.  In additional to the dimensions I also wanted accurate blade geometry.  This required me to read up on blade cross sections, profile tapering, and distal tapering.  I also decided to print out the sword in PLA due to its stiffness and ease of printing.

Blade

Mechanics

My primary concern, at first, was the thickness of the blade.  While PLA is stiffer than ABS, it is still pretty bendy when it comes to a meter long part that’s only 5mm thick.  PLA is also brittle so it wouldn’t take much bending to snap the blade.  To alleviate these concerns, I decided that the blade should have steel rods at its core.  I still had plenty of 2mm x 300mm steel rods that I used as axles for OpenADR, and decided to use these.

divisions

The next concern was print geometry.  A meter-long blade obviously wasn’t going to fit on my Printrbot, so I needed to determine how to split it up into multiple pieces.  The two obvious options were splitting it down the middle lengthwise and printing it in multiple left and right half chunks (left image).  Extending this idea, I could have also had the left and right chunks mismatched (middle image) so that it’d be harder for the blade to break along the blue, horizontal lines.  The last option would be printing out vertical chunks of blade (right image) without any bisecting along the long axis.  For all of the options, I planned on using cut sections of 2mm steel rod to hold the parts together.

I ended up going with the last option for several reasons.  My concern with the first two options was warping.  A big benefit of bisecting along the long axis was that it would allow me to print out large chunks on the long, 225mm X axis of my Printrbot.  However, 225mm is a big 3D print and tends to cause warping, even using PLA.  Without the strength advantage of large, sturdy sections there wasn’t much point to the left/right bisection option.  I was also concerned about space for the metal spine and connectors in the first two options.  While a single 2mm rod fits fine in a 5mm blade, the blade thickness quickly decreases due to the distal taper.  It quickly reaches a point where both vertical and horizontal steel rod connectors won’t fit in the blade cross section.  With the last option, all I needed to add was a single vertical rod to hold the segments together.

Aesthetics

2000px-sword_cross_section-svg

With the mechanical design handled, the next step was the aesthetics.  The first thing I tackled was the blade cross section.  It seemed like historically, the most common types of blade cross section were lenticular and diamond, with the former being popular in the early middle ages and the latter becoming more popular in the late middle ages.  Considering this, I opted for the diamond cross section, thinking that its flat features would be easier to sand later on.

bladecrosssections

Despite going with the diamond cross section, I still designed both main options. One of my secondary goals for this project was to make everything available in OpenSCAD so others could design and print their own swords, and so I wanted to design the different options as modules in case someone in the future has more patience for sanding than I do.  I also included the option for fullers.  While I ultimately didn’t include fullers in the blade I made,  mainly due to concerns about thickness and strength, they certainly add aesthetic appeal when included.

blades

The next step was designing the actual blade.  To help simplify the implemention in code, I mostly based the profile taper of my blade designs on mathematical equations, with one custom option as well.  From left to right, the blades shown above were designed as follows:

  • A custom blade that has an array of widths passed in.  To demonstrate this I went with a sawtooth-like design, but it’s currently extendable out to any design as long as it’s symmetrical across the z-axis.  There was no historical precedent for this blade type, but it seemed like a cool option to have.
  • An elongated elliptical blade with the ellipse length and width passed in.  Historically, this kind of blade provided a good compromise between a cutting and thrusting, allowing a wide blade without sacrificing the sharp point.
  • An exponential blade with the width of the blade decreasing exponentially.  Again, this didn’t really have any historical precedent, but it was easy to add and has an interesting aesthetic.  Without a point, this blade would be no good for thrusting but would provide a good cutting edge.
  • A linear blade with the blade tapering to a fine point.  Historically this type of blade was used predominantly for thrusting.

For the aesthetics I was looking for, I went with the elliptical blade because I thought it looked like a traditional middle ages longsword.  With the width of the blade only tapering off at the very point, it also provided a good amount of structural integrity.

Printability

With the entirety of the blade designed, the next step was making it printable.  I quickly refactored the design of the blade so that the 90cm blade is broken up into 18 50mm segments.  The blade segments were then separated and spread out so as to be printable.  I also added ~2mm holes in each segment to allow space for the metal spine.  The width and thickness at the bottom of the blade had enough space for three metal spines, which allowed for an increase in stiffness and strength.

sword

I discovered a problem when adding in the spine, however.  Originally, I kept the distal taper of the blade the same as the profile taper, so the blade was the top half of an ellipse when viewed across both the X and Y axes.  However, while the blade was thick enough to allow for a 2mm hole at the base, this quickly became impossible toward the top of the blade.distaltaper

To alleviate this, I tripled the width of the ellipse (in terms of blade thickness), but capped the maximum value at 5mm.  An exaggerated example of this is shown in the picture above.  The blade is constant 5mm thick for the bottom half, but still tapers off at the top.  Due to how thin the blade is, this modification is barely noticeable.

One thing to note when looking at my OpenSCAD code is that I only made this printability modification for the elliptical blade.  It took some tweaking to get everything configured correctly, and I didn’t want to spend too much time tweaking for blades I had no intention of printing.  I might go back in the future to fix this, but for now the printability and segmentation code will have to be ported to the other blade types to print one of the other blades.

Hilt

With the blade complete, the next step was designing the hilt.  The three parts on a traditional, medieval sword are the crossguard, grip, and pommel.  I was going to design something elaborate and decorative, but decided I’m no artist, and OpenSCAD doesn’t lend itself well to organic and artistic designs.  Instead I opted for more spartan, geometric designs.

Crossguard

guards

The two options in the back were the customizeable options with an elliptical shape in the back and rectangular one in the front.  Two arrays are passed into the modules that determine the width and height of the shape from left to right.  I liked the custom rectangle shape so much that I went with that design for my final crossguard.  The front two options are a flat hilt and curved hilt with pointed edges.

Grip

grip

The grip is just a simple octagonal shape that I made by creating an OpenSCAD cylinder with eight sides.  I designed it to be printed in two pieces because the entire 200mm piece wouldn’t fit on my printer.  I also included a little octagonal segment in the middle, that’s printed separately, in case I wanted a visible separator for the two-handed grip.

Pommel

pommels

The last piece is the pommel.  On a normal sword this acts as both a counterweight for the blade and a means of preventing hands from slipping off the grip.  Since everything is made out of plastic, and because I don’t intend on using this as an actual sword, this piece is purely decorative.

I was originally going to make this part a little extravagant with a gemstone and went as far as designing it, but decided to go with a simpler approach to keep with my minimalist design.  The left design is the gemstone pommel.  The four holes in the base cylinder are meant to have paperclips inserted that can then be bent to hold in the stone.  For gemstones I was intending to use some fake pirate gems I found on Amazon, but a gemstone mock-up was provided in the OpenSCAD design as a visual reference.

The design I ended up using is on the right.  It’s a simple low-poly shape and went well with the rest of the hilt.  It’s an octagonal shape made in the same fashion as the custom blade and crossguards with a customizeable array that determines the radius of the octagon.

With the design work all finished, the next steps are printing, assembling, finishing, and then finally painting the whole thing! So next post – Keith gets crafty!

Exploring Neural Networks

A few months ago my brother, a medical student, asked me some questions regarding neural networks, how they worked, and the tools available for non-programmers.  Being interested in machine learning but not having explored the field very much, I shopped around to see what simple tools, if any, were available to provide an intro to Artificial Neural Networks (ANNs).  While it seems like this nascent branch of Artificial Intelligence is fairly sparse when it comes to high level tools, I did find one interesting game that was helpful in learning about ANNs.

Bug Brain is a pretty interesting neural network simulator with a built in tutorial that walks you through the process of creating a neural network to control simulated insects.  It explains the process of network inputs, outputs, nodes, and connections by starting with bare bones networks and gradually increasing the complexity.  Despite its 90s-esque graphics, it’s a fun and educational game that is really helpful in explaining the complex concept of ANNs.  The only thing missing, that I can tell, from Bug Brain is ANN training.  As I learned after a few Bug Brain lessons, programming neural networks is hard!  The idea of using thresholds and propagating signals along complex pathways is abstract and gets exceedingly difficult as the neural network gets bigger.

Luckily machine learning scientists have put a lot of thought into how to configure neural networks to train themselves.  By developing special algorithms and feeding input data and correct outputs into this algorithm, a neural networks thresholds and connections weights can be tweaked by the algorithm, effectively causing the ANN to “learn” how it’s supposed to distinguish the data.

An interesting spin on this learning concept is MarI/O, linked above.  Instead of merely tweaking an existing ANN to optimize the thresholds and weights as most algorithms do, MarI/O is based a paper that describes a way to automatically build both the network structure, the connections, and the weights from scratch.  Giving the algorithm a fitness function (in the MarI/O example this is how far Mario gets in the level), the algorithm randomly adds connections and nodes, and changes the weights for the current neural network.  It does this multiple times, generating several randomly tweaked ANNs.  It then runs each of the new neural networks, decides which one is the fittest, and uses that as the baseline for the next series of random mutations.

As cool as it is to see Mario “learn” how to navigate on his own, I think a really interesting project would be taking a simple robot with very basic ins and outs, and adapting this same algorithm to get the robot to achieve a goal.