And with everything assembled the project is finished! There was a small amount of coding involved, but it was pretty simply and mostly self explanatory. The Arduino sketch can be found here on my GitHub. It’s really just a combination of the Arduino ToneMelody example, Adafruit DS1307 example, and my custom L9110S llibrary that I wrote for OpenADR. And without further ado, the final video!
So rather than make individual posts for painting each of the pieces, I decided to lump everything together. The Xenomorph design has varied a lot between depictions, so really there were no specific requirements for coloring and design. I wanted something similar enough to the original designs to be recognizable, but I wasn’t that concerned about fine details.
Disclaimer: Since I don’t have an artistic bone in my body, my wife was kind enough to do most of the painting for me. She did a far better job than I ever could have and everything turned out wonderfully!
Prior to painting, I coated all the prints and the styrofoam head in liquid latex, which was an interesting experience. The bottle I purchased advertised that it was good for monster make up or making scars on faces, but it was difficult to work with to make a smooth surface. Luckily, the dried latex peeled off really easily, which was convenient in the case of mistakes but also sometimes peeled off too easily. After several tries, however, all the pieces had a nice matte finish and fleshy look to them.
Since Freddie the Facehugger is so large, we were a little concerned about keeping the color scheme constant if we went with the same messy approach used for Charlie. Instead, she mixed a ton of light yellowy greenish gray (again, technical terms!) as well as a darker, browner version and a deeper dark gray/brown for shadows. She coated the whole thing with the lightest shade and then contoured the edges and details with the darker colors. This approach was less detailed than mixing small amounts of each creepy bloody shade for Charlie, but it was the easiest way to keep this consistent from the tail all the way out to the arms. One extra challenge with Freddie was all the joints. We wanted to cover as much of the white PLA as possible while still allowing some flexibility. To solve this problem, we used a very watered down paint that was more translucent but soaked into the joints better and did a good job of covering all the visible white sections.
For Charlie the Chestburster, she painted a base coat of yellowish peachish brown (that is the technical term for it, I believe) with some gray mixed in for texture and then added darker gray to the shadows and details to help define them. For the blood, she mixed a bright red paint with black, brown, and green to get a deeper color and painted this on thick in splotches and also watered it down to stain other areas. This was a lot of just splashing paint around and hoping for the best, but the messy look really turned out well!
For the face itself, I just spray painted the styrofoam head model with two coats of “Skin colored” paint. The model had some stains and marks on it when I got it, but this really covered them up well. Plus, his face will be pretty much hidden anyway (poor guy).
The clock hands were just black and gray paint mixed together. We had to do two coats to get in all of the grooves of the uncoated PLA. The benefit of this is that it lets some of the white plastic show through and gives the “tails” a more textured look.
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.
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.
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.
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.
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.
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.
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.
I was able to fit three metal spines at the wider base of the blade.
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.
With the pieces all glued together, the next step was coating it!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
This bottom view of the part gives a better view of the holes
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.
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.
The two pillars in the very back provide a point to mount the base of the pump.
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.
A picture of the downwards facing shafts.
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.
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.
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.
Above is an overall picture with all of the pieces put together.
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.
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.
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.
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!
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.