Alien Clock: Working Cuckoo Mechanism

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.

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.


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.


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.


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!


OpenADR: Pump Test

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!

OpenADR: Mop Design Decisions

In my last post, I described the beginnings of the first module for OpenADR, the vacuum.  With the Automation round of the Hackaday Prize contest ending this weekend, though, I decided to start working on a second module, a mop, before perfecting the vacuum module.  The market for robotic vacuum cleaners is looking pretty crowded these days, and most of the design kinks have been worked out by the major manufacturers.  Robotic mops, on the other hand, are far less common with the only major ones being the Scooba  and Braava series by iRobot.  Both of these robots seem to have little market penetration at this point, so the jury’s still out on what consumers want in a robotic mop.

I’ve been thinking through the design of this module for a while now. The design for the vacuum module was simple enough; all it required was a roller to disturb dirt and a fan to suck it in. Comparatively, the mop module will be much more complex.  I don’t plan on having any strict design goals yet for the mop like I did with the vacuum given that the market is still so new.  Instead, I’ll be laying out some basic design ideas for my first implementation.

The basic design I envision is as follows: water/cleaning solution gets pumped from a tank onto the floor, where it mixes with dirt and grime.  This dirty liquid is then scrubbed and mopped up with an absorbent cloth.  I know that probably sounds fairly cryptic now, but I’ll describe my plans for each stage of this process below.

Water Reservoir

Both the Scooba 450 and Braava Jet have tanks (750mL and 150mL, respectively) that they use to store cleaning solution or water for wetting the floor.  The simplest way to add a tank to the mop module would be to just integrate a tank into the module’s 3D printed design that I described in an earlier post.  This is a little risky, however, as 3D printed parts can be difficult to make water tight (as evidenced by my struggles with sustainable sculptures).  Placing the robot’s electronics and batteries near a reservoir of water has to potential to be disastrous.  A much safer bet would be to use a pre-made container or even a cut plastic bottle.

Being an optimist, however, I’d rather take the risk on the 3D printed tank to take advantage of the customizability and integration that it would provide.  In the case of the sculptures, I wanted to keep the walls thin and transparent.  I won’t have such strict constraints in this case and can use a much more effective sealant to waterproof the tank.  And just to be on the safe side, I can include small holes in the bottom of the chassis (i.e., around the tank) near any possible leaks so the water drips out of the robot before it can reach any of the electronics.


Dispensing of Water


The next design decision is determining how to actually get the water from the tank to the floor.  While I looked for an easily sourceable water pump, I couldn’t find a cheap one that was small enough to fit well in the chassis.  Luckily there are some absolutely amazing, customizeable, 3D printed pumps on Thingiverse that I can use instead!

Disturbing Dirt

The biggest complaint when it comes to robot mops seem to be a lack of effectiveness when it comes to scrubbing dirt, especially with dirt trapped in the grout between tiles.  The Braava uses a vibrating cloth pad to perform its scrubbing while the Scooba seems to use one of the brushed rollers from a Roomba.  Both of these options seem to be lacking based on users’ reviews; the best option would be to use scrubbing brushes designed especially for use with water (rather than the Roomba’s, which are designed to disturb carpet fibers during vacuuming). As with the vacuum module, however, I had a hard time finding bristles or brushes to integrate into my design.  Unfortunately using a roller made of flexible filament (i.e., my solution for the vacuum module) isn’t an option in this case, since it’s not capable of the same kind of scrubbing efficacy as a regular mop.

For my first version, I’m just going to use a microfiber cleaning cloth.  This has the benefit of being washable and reusable, unlike the cleaning pads on the Braava, and yet I can still achieve some scrubbing functionality by mounting the cleaning cloth to a rotary motor.

Water Recovery

A mop that leaves dirty water on the floor isn’t a very effective mop, so some sort of water and dirt recovery is required.  The Scooba uses a vacuum and squeegee to suck the water off of the floor back into a wastewater tank.  The Braava’s cleaning pad, on the other hand, serves double duty and acts as both a scrubber and sponge to soak up the dirty water.  Both of these options seem perfectly valid, but the Braava’s method seems like an easier implementation for a first revision.  It’s also the method that conventional mops use.  The microfiber cloth I decided to use for scrubbing can also serve to absorb the water and dirt from the floor.

It’s important to note, however, that using the absorption method for water recovery limits the robot’s water capacity and the amount of floor it can clean.  The mop could have a 10L water reservoir, but if the cloth can only absorb 100mL of there will still be 9.9L of water left on the floor.  The Braava only has a 150mL tank and 150sqft. of range because its cleaning pad can only hold 150mL of water.  I’ll have to do some testing on the microfiber cloths I use to determine the maximum capacity of the mop module.

Next Steps

Designing and printing out the mop module!


OpenADR: Vacuum Test #1

Now that the vacuum module is mostly assembled, it’s time for the first test! I basically just wanted to make sure that there was enough suction power generated by the fan to pull in dirt and debris. Here’s how the module looks so far:


As I mentioned in my previous post, I didn’t design a lid yet for the vacuum module because I wanted to use a clear coating on the top for now.  Having the interior of the dust bin visible will make it easier to test and view what is going on inside.  For now, I’ve sealed the top of the dust bin by taping on a cut up Ziploc bag.

The blower fan is rated for 12V, so I have it wired directly to my 12V bench supply using alligator clips.

Standard dog hair
Standard dog







The test itself was performed on standard dog hair (since I have so much of it lying around). I had to feed the hair directly into the dust bin input because the vacuum module isn’t yet attached to the main robot chassis and so there’s no direct airflow channel that passes through the roller assembly and into the dust bin.  I’m considering integrating the roller assembly directly into the vacuum’s body so the whole module is self-contained and the complete path of dust through the vacuum can be tested without having to attach it to the main chassis.

So the first test proved moderately successful!  The hair did get slightly stuck, but that can mostly be attributed to the flexible Ziploc bag material being sucked downward, thereby decreasing the height of the opening where the hair entered the dust bin.  For the next revision I’m probably going to curve the input air channel so hair and dust isn’t making so any 90° turns.  Next up, testing the whole thing as part of the main chassis!

OpenADR: Vacuum Module v0.1

Now that the navigation functionality of the main chassis is mostly up and running, I’ve transitioned to designing modules that will fit into the chassis and give OpenADR all the functions it needs (see my last post).  The first module I’ve designed and built is the vacuum, since it’s currently the most popular implementation of domestic robotics in the market.  Because this is my first iteration of the vacuum (and because my wife is getting annoyed at the amount of dust and dog hair I’ve left accumulating on the floor “for testing purposes”), I kept the design very simplistic: just the roller, the body (which doubles as the dust bin), and the fan.

Roller Assembly


The brush assembly is the most complicated aspect of the vacuum.  In lieu of finding an easily sourceable roller on eBay, I opted to design the entire assembly from scratch.  I used the same type of plain yellow motors that power the wheels on the main chassis to drive the roller.


The rollers themselves consist of two parts, the brush and the center core.  The brush is a flexible sleeve, printed with the same TPU filament used for the navigation chassis’s tires, that has spiraling ridges on the outside to disturb the carpet and knock dust and dirt particles loose.  The center core is a solid cylinder with a hole on one end for the motor shaft and a protruding smaller cylinder on the other that is used as an axle.   One roller is mounted on either side of the module and are driven by the motor in the center.


To print the vacuum module, I had to modify the module base design that I described in my last post. I shortened the front, where the brush assembly will go, so that the dust will be sucked up between the back wall of the main chassis and the front of the vacuum module’s dust bin and be deposited in the dust bin.

Fan Mounting


For the fan, I’ll be using Sparkfun’s squirrel blower. I plan to eventually build a 3D model of the fan so that it fits snugly in the module, but in the meantime, the blower mount is just a hole in the back of the module where the blower outlet will be inserted and hot-glued into place. In the final version, I will include a slot for a carbon filter in this mount, but given that I’m just working with a hole for the blower outlet in this first version, I cut up an extra carbon filter from my Desk Fume Extractor and taped that to where the air enters the blower to make sure dust doesn’t get inside the fan.


The blower itself is positioned at the top of the dust bin with the inlet (where the air flows in) pointed downwards.  Once the blower gets clogged, the vacuum will no longer suck (or will it now suck?), so I positioned the inlet as high as possible on the module to maximize the space for debris in the dust bin before it gets clogged.

Dust Bin

The rest of the module is just empty space that serves as the vacuum’s dust bin.  I minimized the number of components inside this dust bin area to reduce the risk of dust and debris causing problems.  With the roller assembly placed outside the bin on the front of the module, the only component that will be inside of the dust bin is the blower.

With a rough estimate of the dimensions of the dust bin, the vacuum module has the potential to hold up to a 1.7L! This is assuming that the entire dust bin is full, which might not be possible, but is still substantially more than the 0.6L of the Roomba 980 and 0.7L of the Neato Botvac.

Future Improvements

There are a few things I’d like to improve in the next version of the vacuum module since this is really just alpha testing still. The first priority is designing a fan mount that fits the blower and provides the proper support.  Going hand in hand with this, the filter needs an easily accessible slot to slide in before the fan input (as opposed to the duct tape I am using now).

I also want to design and test several different types of rollers in order to compare efficiency.  The roller I’m using now turned out much stiffer than I’d like so, at the very least, I need to redesign them to be more flexible.  Alternatively, I could go with something more like the Roomba’s Aeroforce rollers, which decrease the cross-sectional area of the air passage and thereby increase the air velocity.  These rollers offer better suction and less opportunity for hair to get wrapped around the rollers but are a little less effective for thicker carpets.

Further, I need to make sure that the dust bin is in fact air-tight so that dust isn’t getting into the main chassis or back onto the floor.  I included bolt mounts on the floor of the dust bin to connect the separate pieces together, but I don’t have mounts on the walls of the dust bin, and so I am using tape around the top of the bin to hold the pieces together for now.  Since any holes in the dust bin provide opportunity for its contents to leak onto the floor, making sure I have a good seal here is critical.  In the future I’d like to redesign these seams so that they are sealed more securely, possibly by using overlapping side walls.

Lastly, the vacuum module needs a lid.  For the current version I intentionally left out the lid so that see everything while I’m testing. I plan to add a transparent covering to this version for that purpose (and so dust doesn’t go flying everywhere!). In the final version, the lid will need to provide a good seal and be easily removable so that the dust bin can be emptied.

But before we do all that, let’s test this vacuum!