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!
I hot glued the clock mechanism into its place on the back of the Facehugger. The Facehugger won’t be too tight against the face so the dial will still be reachable.
With the mechanism in place, I just had to slight the hands onto the shafts protruding from the center hole.
Unfortunately the addition of the mechanism didn’t leave space for Kane’s nose, so it had to go.
And lastly the Facehugger was attached! The legs provide a pretty good grip when bent around the head but for additional security I drove a metal rod partway through the mannequin’s head and hung Facehugger on the protruding bit.
I cut a hole in the duct tape roughly where the Alien juvenile burst from Kane’s chest in the movie.
I used a combination of foam-core board and cardboard to give the bottom of the mannequin shape. I also 3D printed holders for PVC piping to make a structure to hold the Chestburster mechanism.
The final Chestburster mechanism mounted to the base.
Lastly was to cut a hole in the shirt so that the Chestburster was mostly concealed but not restricted in movement.
As mentioned in my post on the Chestburster mechanism, the two motors aren’t mechanically linked, causing a problem where one motor would crawl ahead of the other. To play it safe, I devised a method of avoiding this problem. I reprinted a few of the parts and added 2mm steel rods to act as guides for the motor carriage.
The metal rods are attached to the ends of the whole mechanism.
The rods are threaded through wings on the carriage to keep it straight.
And here’s a pic of the new assembly.
The cuckoo mechanism is done, and it works! Below is a description of each of the printed pieces and a video of the mechanism in action.
The main pieces are the four racks and the motor carriage. The racks provide a linear channel for the pinions to crawl along. The motors are mounted into the carriage with the four pinions on the two motor shafts.
The four racks are mounted together with the backstops facing outwards. This serves to contain the pinions so they’re incapable of derailing.
The carriage with the two motors mounted.
The 3D printed parts and motors assembled.
The entire assembly. I used a wooden dowel that I had on hand to hold the Chestburster and fit into the carriage.
Above is a demo video of the Chestburster actuating. I’m controlling it with an L9110s motor controller to get the required bidirectional motion. Mounted limit switches are visible on top of the assembly glued on the top racks. These currently aren’t wired to anything but would serve as a way for the Arduino to detect that the end of travel has been reached so it knows to stop sending current to the motors. Right now, however, I’m just using delays to run the motor approximately long enough to hit the end stops.
I’m considering keeping the setup like this and not using the limit switches at all. The travel distance is so short, and the time it will be running is so infrequent, that I think the simplicity of not having to use the limit switches would be worth the slight increase in the wear-and-tear on the motors due to stalling out. Another reason I’m considering this is because the limit switches may not match up perfectly with end of travel. Something I didn’t address in my mechanism was the mechanical linkage of the two motors. Because they’re not directly coupled, it’s possible for one motor to operate slower than the other, thereby causing the carriage to misalign and one motor be closer than the limit to the other. Applying current when one motor is at the end of travel limit would cause the faster motor to stall, but would give the slower motor a chance to catch up and resynchronize.
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.
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!
While I’m putting the design for the OpenADR mop module together, I decided to do a quick test of the 3D printed pump I’ll be using to move the water/cleaning solution from the internal reservoir to the floor. The pump I am planning to use is a 3D printed peristaltic pump from Thingiverse.
For my test setup, I used the another of the cheap, yellow motors that I powered the wheels on the main chassis and the brushes on the vacuum module to drive the pump. I threaded some surgical tubing from a full glass of water, through the pump, and into an empty glass. I then ran the motor off of 5V.
Overall the pump ran great, albeit a little slower than I anticipated. The next step is integrating it into the mop!