3D Printed Sword: Build

Printing

Material

The filament I decided to use was silver Hatchbox PLA.  After printing the coloring of the plastic turned out more of a shiny gray than a silver.  While I knew I was going to paint the sword anyway, I wanted a grayish base color so that the color of the filament wouldn’t show through.  Plus, if the sword ever gets scratched, the dull gray scratch color will look more realistic.

Settings

My biggest concern for the printed parts used for the sword was the strength, specifically the strength between print layers.  This was most critical on the blade of the sword, due to its length and weight providing a lever arm that could cause the prints to snap.  Additionally, due to the way I decided to print out the blade, speed became an issue.  I oriented the sword segments so that the blade was divided along the X-Y plane.  This meant that the longest axis was in the Z direction.  The Z-axis is also commonly the slowest on a 3D printer, mainly because a leadscrew is usually used.  To compensate for all of these design concerns, I tried to find an optimal balance between weight, strength (particularly layer adhesion), and print time.

After reading numerous studies and suggestions, I decided on a layer height of 0.3mm and width of 0.4mm.  I also ran the hotend a little on  the hotter side at 210C.  Because I planned on sanding and finishing, allowing for a little stringing (a common result of too-high hotend temperature) was well worth the added strength and layer adhesion it provided.  I also kept the infill a little low at 10% so the blade wouldn’t be too heavy.

img_0723

The 18 50mm segments of the blade are shown above.  They turned out pretty good with minimal stringing.  One noticeable feature on the outside of the blade segments are the vertical lines.  These are caused by interaction between the internal hole perimeters and outside perimeters.  There’s isn’t enough space for both sets of perimeters and so some external artifacts are present on the outside.  Luckily these can be easily hidden by the finishing process.

img_0724

The two halves of the pommel didn’t turn out as well as I’d hoped.  Because I printed with the center of the pommel on the bed, there wasn’t enough support for the circular arch that would hold the grip.  This can hopefully be fixed with some sanding and finishing.  Also shown above is the hole that the blade will be glued into.

img_0730

Lastly are the grip and pommel.  The grip was printed in two halves and held together by a metal spine.  Three 2mm holes were extended through the length of the grip so the pommel and blade could both be securely attached.

Assembly

The majority of the build time was spent assembling the blade, because it’s the most complex part.  I used cyanoacrylate glue (super glue) due to it’s good adhesion to PLA.  The brand I used was also labeled as “gap filling.”  I figured this would be useful if the tops and bottoms of the blade segments were slightly warped or didn’t match up properly.

img_0727

I also used a metal spine to prevent stress on the glue joints and provide additional strength to the blade.  Due to the metal pieces only being 300mm long, I trimmed the rods so that, when transitioning from one rod to another, the joint is in the center of a blade segment.

img_0728

I was able to fit three metal spines at the wider base of the blade.

img_0733

img_0729

I cut the metal rods so that a decent portion would protrude from the bottom.  These extra length could then be used to mount the blade to the grip.

img_0734

With the pieces all glued together, the next step was coating it!

Finishing

The process of finishing the blade was divided into three main parts, coating, sanding, and painting, with an additional step of leather wrapping the grip.  These steps weren’t terribly difficult, but nevertheless the finishing took a long time, with each step requiring patience.

Epoxy Coating

This slideshow requires JavaScript.

The first step in finishing the sword involved coating the plastic in epoxy.  The brand I used was XTC-3D.  It works like most epoxy, involving mixing the two parts together to get a rapidly curing mixture.  I then had about five minutes before the epoxy hardened to brush it on to the plastic.  After this was a four hour wait for the epoxy to finish curing.  Once completely hardened, the epoxy left a hard, clear coat over the plastic.  This had the added benefit of adding more strength to the plastic by holding together the print layers and separate parts.  Because I planned on sanding the pieces anyway, I used an excessive amount of epoxy when coating, as is evident by the visible epoxy drips.

Because I had to apply the coating two each side of the blade separately, I had to wait four hours between each half.  I also wanted to apply three coats to the blade.  What resulted from this was the week long process of coating the blade because I only effectively had time for one half of a coat once I had gotten home from work.

Sanding

This slideshow requires JavaScript.

The next step was sanding down the epoxy coating to a smooth, metal-like surface.  This was by far the most tedious process.  I initially bought plain sandpaper and started the process of sanding everything down by hand.  As I soon realized, this was a profoundly terrible idea and would have taken forever.  I shortly gave up and bought a random orbit sander.  The benefit of the “random orbit” was that no directional sanding lines would show up on the finished piece, and so the sword would look uniformly smooth, just like actual steel.

New toy in tow, I forged (pun intended) on with the process of smoothing out the pieces of the sword.  I started out by using 80 grit sandpaper to sand the flat surfaces of the blade entirely flat, and then slowly worked my way through 150, 220, 320, 400, and 600 grit sandpapers.  These left me with an incredibly smooth surface that was ready for painting.

One downside of the sanding that I noticed was that the vibrations caused some of the superglued joints to come undone.  Both the pommel and a piece of the blade had to be reglued.  The blade one actually happened after painting and was difficult to repair.

Painting

This slideshow requires JavaScript.

The last step was painting everything.  This was the simplest step, but was still time consuming due to having to wait for each coat to dry before flipping over the sword to paint the other side.  I spray painted each of the pieces separately with silver spray paint, with several coats for each piece.

Leather Wrapping

This slideshow requires JavaScript.

As a bonus step, I decided to wrap the hilt in leather to add a nice touch to the finished product.  I cut the leather roughly to size stretched it out a bit, then superglued one edge to the grip.  I specifically left the grip unpainted so that the glue would have a stronger hold on the plastic part.  I then tightly wrapped the leather around the octagonal grip, applying glue on each face.

Failings

While I’m fairly happy with how the finished product turned out, there are two things that didn’t turn out as I’d hoped.  Mainly the stiffness of the blade was lacking and joints between blade segments couldn’t handle the stress of the finishing process.

Stiffness

While the PLA is stiff enough to prevent significant bending, the metal rods have a certain flexibility that allow some give at the inter-blade joints.  As a result, the blade is more flexible than I’d like.  I had to handle the sword very carefully for fear of the joint bending causing the blade to crack or break.  If I attempt a repeat of this project, or something like it, I’ll have to consider a fix for this.

One option would be to use a different type of joint.  The current, flat joint that I’m using allows for some space between the segments where the metal rods can bend.  If I had used some type of overlapping joint it’s possible that the flexibility would have been reduced.

Another alternative would be to use a stiffer material for the blade spine.  Something like carbon fiber rods would be much hopefully be much stiffer.  The only concern with this would be the lack of flexibility putting more strain on the glue joints between segments.

Cracking

The biggest issue I had was with the blade segment joints not being strong enough to withstand the finishing process.  Specifically the vibrations from the sander caused the joint adhesion to fail in one particular spot.

img_0792

Near the top of the blade, where the cross section of the blade was small and only one spine held the segments together, the glue joint repeatedly failed.

IMG_0903

At first I reapplied both the glue and the epoxy coating and sanded it down again.  However this caused a second failure, at which point I gave up and just used a lot of super glue and some light sanding.  Fortunately the poor finish isn’t too noticeable at a distance.

IMG_0902

Another part of the blade partially cracked towards the bottom.  Some of the epoxy came out between the blade segments leaving a slight crack.  Because spray paint is so thin, it was unable to hide this defect.

I think the only solution to the strength problem would be to  change the way I’m joining the segments since the superglue doesn’t seem to be strong enough.  Two different methods I could use would be heat or friction welding when using PLA, or solvent welding when using ABS.  These methods would hopefully make the whole blade into one cohesive unit.

Another possible option would be to use a different kind of paint.  I used spray paint which is thin by necessity and has trouble hiding defects.  Using a thicker, brush-on paint would have done a better job hiding the cracks that popped up.

Finished Product

IMG_0914

IMG_0916

Despite the issues I had I’m mostly happy with the finished product.  Unfortunately not all projects can be resounding successes, but I learned some new techniques and have a nice decoration for my office now!

OpenADR: Mop Module v0.1

For the sake of design simplicity and ease of assembly, the mop module is broken up in to two main parts based on the module base design.  The front of the module (the 150mm^2 square) is devoted almost entirely to the water storage tank and the rear is where all of the electronics and mechanics are.

IMG_0636

The picture above is a failed print of the front part of the mop module.  Rather than just tossing this piece, I ended up using it to test out the waterproofing capability of the XTC-3D print sealant.  It ended up working perfectly.

Despite the failed nature of the above print, it still demonstrates the main sections of the front of the mop module.  The main water tank is bounded by two walls, the left in the picture being the back wall of the water tank and the right wall being the front.  The small gap between two walls on the right side of the picture is the location of some holes in the base of the module that will allow for the water to be evenly dripped onto the floor.

IMG_0638

This bottom view of the part gives  a better view of the holes

IMG_0639

Two holes in the back of the water tank provide an input to the pumps.  Because combining electronics and water is a big no no, I added some holes in the bottom of the module so that any leaks around these holes would drip onto the floor rather than flooding the electronics section.

IMG_0640

This is the back of the mop module where all of the magic happens.  The holes in the bottom provide mounting points for the two motors that will drive the pumps.

IMG_0641

The two pillars in the very back provide a point to mount the base of the pump.

IMG_0644

The two, dual-shaft motors have one output shaft extending out of bottom that will be connected to the scrubber and one extending upwards that will be driving the pump.

IMG_0645

A picture of the downwards facing shafts.

IMG_0646

The above picture shows the back of the module with all of the hardware mounted.  Unfortunately, I didn’t give enough space for bolt heads that hold the motor in place.  The pumps can’t pushed down as far as I intended and so they don’t line up with the holes I left in the mounting pillars.  Luckily the mounts are sturdy enough to mostly hold the pumps in place and so I don’t need to mount them for testing purposes.

IMG_0648

These are the two halves the the scrubber that will hold the microfiber cloth that will be used to scrub the floor and soak up excess water.  The two halves are made to be pressed together with the cloth sandwiched in between them.

IMG_0649

This picture shows the cloth and scrubber assembled.  I underestimated the thickness of the cloth, so two won’t currently fit side by side.  I’ll need to either make the cloth smaller or move the scrubbers farther apart.

IMG_0650

Above is an overall picture with all of the pieces put together.

 

OpenADR: Esp32 Initial Test

As I mentioned in a previous post, I’m attempting to test the ESP32 as a cheap replacement for my current Raspberry Pi and Arduino Mega setup.  I’m hoping that doing this will save me some complexity and money in the long run.

Unfortunately, with the ESP32 being a new processor, there’s not a lot of Arduino support implemented yet.  Neither the ultrasonic sensor or the motor driver libraries compile yet due to unimplemented core functions in the chip library.

Luckily a new version of the ESP-IDF (IoT Development Framework) is set to be released November 30,with the Arduino core most likely being updated a few days later.  This release will implement a lot of the features I need and so I’ll be able to continue testing out the board.  In the mean time I plan on adding more sensors to the Navigation Chassis v0.3 in preparation, as well as working on some other projects.

OpenADR: New Controller Options

One of the reasons for my hiatus from OpenADR is due to some uncertainty when it comes to the main processor for the robot.  My current implementation uses a Raspberry Pi for general control and data logging with an Arduino Mega handling the real-time code.  However, these two boards result in a combined price of $80 ($35 for the Raspberry Pi and $45 for the Arduino).  Requiring these parts would make the total cost of the navigation chassis much higher than I’d like.  These parts might also make it more difficult to manufacture OpenADR if I ever decide to turn it into a product.  While I could always create a custom board based on the Arduino Mega, the Raspberry Pi isn’t exactly manufacturing-friendly.

These reasons are why I’m exploring alternative options for the main controller for OpenADR and through my research I’ve discovered two options that I’m pretty excited about.  Both the C.H.I.P. Pro and ESP32 are powerful processors that could potentially be used for OpenADR, with the former being similar to the Raspberry Pi and the latter being closer to an Arduino.  Below is a comparison of specs and a description of how they could be used.

C.H.I.P. Pro

The C.H.I.P. Pro is an embedded Linux module produced by Next Thing Co. and is advertised as a solution for products requiring embedded Linux.  It has onboard WiFi and Bluetooth, and has an ARM Cortex-A8 processor with 256MB or 512MB of RAM running at 1GHz.  An added benefit is the Gadget ecosystem that Next Thing Co. announced.  They haven’t released too many details, but the impression I got is that it’s a Linux package that allows for easy and secure updating of products running on the C.H.I.P. Pro system.  My expertise starts to fuzz when it comes to product software management, and I know very little about security, so having an ecosystem that would make this easier would help me a lot.

One possible downside is that embedded Linux isn’t always good enough for real time applications.  While the board might have enough GPIO to connect to the robot’s peripherals, they might not be able to update outputs and read data fast enough for what I need the robot to do.  For example, any timing delays in the reading of the ultrasonic sensors could lead to incorrect distance data that would inhibit the robot’s ability to understand and map its environment.  This is something I can experiment with when I receive my development kit.

ESP32

The ESP32 is the other side of the embedded systems coin.  It doesn’t run Linux, but instead uses a Tensilica LX9 microprocessor with 520KB of RAM running at 240MHz.  It also has WiFi and Bluetooth built-in.  The plus side of a bare metal system is that there’s less concern about delays and real time control with the robot’s peripherals.  The downside is that this makes it much harder to write software for the robot.  A lower level language would need to be used and without Linux or the features of a more powerful processor, certain features, such as real time data logging, may be harder to manage and implement.

While different processor architectures aren’t always directly comparable, the ESP32 does run a 15x the speed of the Arduino Mega I’ve been using so far.  So while it might not be able to compete with a Raspberry Pi or C.H.I.P. Pro in terms of data processing, it’s way more powerful the Arduino and it will probably still be possible to implement the more complex features.  I currently have SparkFun’s ESP32 Thing development board on my desk and look forward to testing it out with OpenADR!

 

HAL 9000: Wiring

BOM

Wiring

This slideshow requires JavaScript.

With the Raspberry Pi as the centerpiece, I went about connecting everything together.  The first step was wiring up the sound.  I took a stereo audio cable plugged into the Raspberry Pi’s audio port and wired each of the left and right channels into its own amplifier.  The power and ground of both amplifiers was sourced from the Raspberry Pi’s 5V and GND pins on the GPIO header.  I then wired the outputs of one of the amplifiers to the speaker.  The outputs of the other amplifier were wired to the LED in the button.  By doing this, the light inside of HAL’s eye would flash in sync with the audio being played.  Aside from that, all that was left to do was plug in the USB microphone and I was done.  One optional addition I might make in the future is wiring up the inputs of the button.  This would provide the possibility to activate Alexa via means other than the wake word.

HAL 9000: Alexa Install

I originally thought this blog post was going to be a lengthy explanation of how to install the Alexa software (found here) on the Raspberry Pi 3 with all of the caveats, tweaking, and reconfiguration necessary to get the software to install.  Any Linux user who frequently installs software from source knows that the time it takes to get some software to compile and install is exponentially proportional to the complexity of the code and the compile time.  This is not the case here.

It did take roughly an hour to run the automated install script provided in the Alexa repository, but once that had completed everything ran almost perfectly right out of the box.  I’m utterly floored by this, and am incredibly impressed with the Alexa development team on the quality of their software project.  So really, if this is something you’re interested in doing, use their guide to set up everything.  All you really need is a Raspberry Pi 3, a microphone (I used this one), and a speaker (I used one from Adafruit which I’ll discuss in detail in my post on wiring).  The only thing I had to tweak was forcing the audio to be output on the 3.5mm jack using raspi-config and selecting the jack in Advanced Options->Audio.

And without further ado, my working example.

HAL 9000: Overview

A HAL 9000 replica has been on my “to make” list since Adafruit started stocking their massive, red arcade button.  They even created a tutorial for building a HAL replica!  When the Alexa developers added support for a wake word last month, I knew I had to build it.  Rather than simply playing sound effects with the Pi, I wanted to include Amazon’s new Alexa sample that allows to run the Amazon Echo software on the Raspberry Pi 3.  Always a fan I tempting fate, I thought the HAL replica would be the perfect container for a voice assistant that has access to all of my smart home appliances.  What could go wrong?