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.

IMG_0634

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: On Modularity, Part 2

While I’ve been working primarily on the vacuum component of OpenADR, my eventual goal is for this to be just one of several, interchangeable modules that the robot can operate with.  By making the whole thing modular, I can experiment with a range of functions without having to recreate the base hardware that handles movement and navigation (i.e., the hard stuff!).  Today I wanted to share a bit more about how I’m building in this functionality, even though I’m only working on one module for now.

IMG_0482

The OpenADR modules will plug into the opening that I have left in the main chassis.  The modules will slide into the missing part of the chassis (shown in the picture above) to make the robot a circle when fully assembled.  The slot where the module will be inserted is a 15o x 150 mm square in the center and a quarter of the 300 mm diameter circle of the whole robot.  The picture below might give you a better sense of what I’m describing.

ModuleBase.png

While each of the modules will be different, the underlying design will be the same.  This way, regardless of which module you need to use (e.g., vacuuming, mopping, dusting), everything should fit nicely in the same main chassis with minimal modifications needed.

To aid in the design of the separate modules, I’ve created a baseline OpenSCAD model that fits into the main chassis.  The model is broken up into four pieces in order to make printing the parts easier, and I’ve included bolt mounts to attach them together.  The model also includes tracks that allow the module to slide into place against the ridges that I have added to the adjacent walls of the main chassis.  I’ll build off of this model to create each module to be sure that everything is easily interchangeable and fits smoothly (especially with my new filament!).

The great thing about OpenADR being modular is that I can always add new modules based on what would be useful to those using it.  So this is where I need your help.  What functionality would you like to see?  Are there cleaning supplies or techniques you use regularly on your floors that could be automated?

OpenADR: Navigation Chassis v0.3

With the previous version of the chassis in a working state, I only made two changes for version 0.3.  The first change was a major one.  As I mentioned previously, I was still a little unhappy with the ground clearance on the last version of the chassis.  It ran well on hardwood and tile floors, but tended to get caught on the metal transition strips.  It also still had some trouble on the medium-pile carpet in my apartment.

Increasing ground clearance required some significant changes to the chassis design due to the way I was connecting the motor.  In my last revision of the chassis (0.1 to 0.2), all I had to do to increase the ground clearance was lower the motor mount so it was closer to the chassis base.  However, since I already moved down the motor almost as far as it could go in the last revision, I didn’t have any more room to do the same here!  Alternatively I could have just increased the diameter of the wheel, but I was concerned about the motors not having enough torque to move the robot.

The only option left was to no longer directly drive the wheels from the motors and instead use gears.  Using gears makes it possible to offset the motor from the base of the chassis but still maintain a strong connection to the wheels.  Another benefit is that it’s possible to increase the torque traveling to the wheels by sacrificing speed.

To design the gears, I used a gear generator site to generate a 16-tooth and 8-tooth gear DXF file.  Using OpenSCAD’s import function, I imported the DXF files and then projected them linearly to create the 3D gear object.

IMG_0491.JPG

For the small gear, I subtracted the motor shaft out of the 3D object so it could mounted to the motor.

IMG_0490.JPG

I merged the large gear with the wheel object so that the wheel could be easily driven.  I’m now using a 2mm steel axle to mount the wheel and gear combo.

IMG_0486.JPG

IMG_0484.JPG

By slightly repositioning the motor, I was able to move the gears into place so the wheel was properly driven.  By mounting the 8-tooth gear to the motor and the 16-tooth gear to the wheel, the wheel now sees a 2x increase in torque at the cost of running at 0.5x the speed.  Additionally, with the wheel no longer directly mounted to the motor, I was able move the wheel axle lower.  This allowed the wheel diameter to be decreased from 50mm to 40mm while still increasing the overall ground clearance from 7.5mm to 15mm.

I did the above calculations for the force and speed on version 0.2 of the chassis as well as the new force and speed based on the motor specs I pulled from Sparkfun’s version of this motor.
IMG_0479

Another part of the chassis that had to change in order to increase ground clearance was the caster.  As shown above, version 0.2 had a hole in the chassis to make room for a semi-spherical caster wheel directly mounted to the chassis floor.  Doubling the ground clearance, however, would have necessitated the caster, and by extension the hole, increase to a much larger size.

IMG_0492.JPG

To avoid this, I made the caster entirely separate from the chassis.  With two mounts, a 2mm steel axle, and a ellipsoid wheel, the caster no longer needs large holes in the chassis and frees up some internal space.  I’m a little concerned that these new casters won’t be able to handle the transitions between carpet and hardwood well, due to their smaller size, but I can always revert to using a hole in the chassis and make them much larger.

The second change I made to the chassis was a minor one.  In my mind, the eventual modules that will go with the navigation chassis will be plug and play, meaning no need for screwing or unscrewing them just to swap modules.  To accomplish this I knew I needed some sort of mounting method inherent in the 3D design of the chassis.

IMG_0502.JPG

I anticipate some sort of USB or 0.1″ header connector for the method of keeping the modules in place and electrically connected, but for helping to guide the module into I added guide rails to the left and right side of the inside wall of the chassis.  These rails will make it easy to properly align the modules and will also keep the module vertically stable.

OpenADR: Battery Charger PCB

 

Schematic

ChargerSchem

Above is the final circuit for the four cell LiFePO4 charger.  I tweaked a few parts of the original design for safety, testing, and power considerations.  A diode has been added after the main voltage output to allow for the capability to parallel multiple battery packs.  Another thing is that I’m using generic PNP and power resistors so that the maximum charging current of the design can be adjusted as necessary.  Since the charging current of a battery is loosely based on its capacity (see C Rating), allowing for a wide range of currents makes it theoretically possible to use any battery size.  I also plan on using a charge current of ~100mA for my first go at this.  Doing so allows the batteries to charge slower and give me more resolution when testing the charging circuitry.

BOM

The components I’m using from this design are as follows:

Board

ChargerBoard

One last thing to note is that I purposefully chose to use through hole parts for the sake of debugging.  The excess space and exposed connectors make it easier to use alligator clips to measure the voltages and signals, making sure that everything is operating as it’s supposed to.

Next Steps

Soldering, assembly and testing!

OpenADR: Battery Charger Circuit

Since I decided to use a 4S LiFePO4 battery in my previous post, I’ve been looking online for charger design resources and examples.  From what I gathered from several sources, I’ve come up with what I think is a circuit that will work for charging the LiFePO4 batteries.  Before I go into the details of the circuit, however, let me briefly cover the basics of LiFePO4 charging.

LiFePO4 Charging Basics

Most of what I learned about LiFePO4 charging comes from this article which goes into great detail about the charging specifics, but which I’ll summarize here for the sake of brevity.  LiFePO4 uses what’s called CC/CV, or constant-current/constant-voltage, charging.  This means that a constant amount of current is supplied to the battery when charging begins, with the charger increasing or decreasing the supplied voltage to maintain the constant current.  Once the battery reaches a certain voltage, 3.65V in the case of LiFePO4 batteries, the constant-current phase stops and the charger supplies a constant voltage to the battery.  As the battery gets closer to fully charged, it draws less current until it’s full.

Constant-Current Circuit

LM317

The constant-current circuit was easy enough.  The popular LM317 regulator has a constant-current configuration, shown by Figure 19 in this PDF.  Based on the equation in the attached PDF diagram, a 1.25 Ohm power resistor would result in 1A of constant current.

Constant-Voltage Circuit

The constant-voltage circuit was a little more complicated to design.  The difficulty with supplying a voltage to four batteries simultaneously is that the voltage needs to be evenly distributed to each of the batteries.  This is called cell balancing.  Without it, one battery may charge faster than the others, resulting in a larger voltage drop across that particular cell.  As the battery pack becomes more charged, the individual cells will become more unbalanced, resulting in wasted energy and decreased performance.  Once I took this into account, I realized I needed to both keep a consistent voltage across the battery terminals, and redirect current away from the battery when it had completed charging so that the other batteries could finish charging as well.

With this in mind I looked into using Zener diodes.  These operate like regular diodes by only allowing current to travel in one direction, up to a certain point.  Unlike regular diodes, however, they allow current to travel in reverse when a threshold voltage is exceeded.  They’re commonly used in power supplies to prevent voltage spikes.  When there’s a spike in voltage that exceeds the threshold, the Zener starts conducting and acts as a short circuit, preventing the voltage spike from affecting the rest of the circuit.  The problem with Zeners, as outlined in this post, is that they have a “soft knee” with a slow transition to conductance around the threshold voltage.  This results in inaccuracies in the threshold voltage required for the Zener to conduct, making it too inconsistent to use as a voltage limiter.

Luckily that posts outlines an alternative.  The TL431 acts like a Zener diode, but has a much sharper curve and a programmable voltage threshold.  By using a voltage divider with a potentiometer, it’s possible to tune the TL431 circuit to conduct at exactly the desired voltage.

CellCircuit

Above is the circuit I implemented.  Because the TL431 has a maximum current rating of 100 mA, I opted to use a PNP transistor as an amplifier.  When the threshold voltage of 3.65V is exceeded the TL431 conducts, turning on the PNP transistor and providing a short circuit to route current around the battery cell.  The complete charger is made up of four of these circuits in series with the high side connected to the constant-current circuit discussed above.

Improvements

Once I’ve verified that this circuit works and properly charges a battery, there are a few things I’d like to eventually go back and add to this circuit.  The first is an undervoltage detection circuit.  Lithium rechargeable batteries become useless if they’re ever fully discharged.  This full discharge can be prevented by cutting off the power from the batteries before they reach the absolute minimum cell voltage.  This is ~2V in the case of LiFePO4 cells.  A circuit similar to the one for maximum voltage detection could be used to check for the minimum voltage and disconnect the cells, preventing permanent damage to the battery pack.

I’d also like to add an output for the total battery pack voltage so a microcontroller can measure and detect the state of charge for the pack.  This would involve using a voltage divider to provide a divided down voltage within the measurement range of standard microcontrollers.

Next Steps

I drew up the circuit schematic described above in LTSpice, a free circuit simulation tool.  Despite LiFePO4 batteries being safer than LiPos, I’m still erring on the side of caution and will check my work every step of the way.  Simulation seems like the next best option to actually testing a physical circuit.  My next update will outline my simulation parameters and the results I saw.

OpenADR: Long Term Plans

ProductHierarchyWith the beginning of the Automation round beginning today, I decided to sketch out some of the long term plans I have for OpenADR.  All my updates so far have referenced it as a robot vacuum, with a navigation module and vacuum module that have to be connected together.

The way I see it, though, the navigation module will be the core focus of the platform with the modules being relatively dumb plug-ins that conform to a standard interface.  This makes it easy for anyone to design a simple module.  It’s also better from a cost perspective, as most of the cost will go towards the complex navigation module and the simple plug-ins can be cheap.  The navigation module will also do all of the power conversion and will supply several power rails to be used by the connected modules.

The modules that I’d like to design for the Hackaday Prize, if I have time, are the vacuum, mop, and wipe.  The vacuum module would provide the same functionality as a Roomba or Neato, the mop would be somewhere between a Scooba and Braava Jet, and the wipe would just be a reusable microfiber pad that would pick up dust and spills.

At some point I’d also like to expand OpenADR to have outdoor, domestic robots as well.  It would involve designing a new, bigger, more robust, and higher power navigation unit to handle the tougher requirements of yard work.  From what I can tell the current robotic mowers are sorely lacking, so that would be the primary focus, but I’d eventually like to expand to leaf collection and snow blowing/shoveling modules due to the lack of current offerings in both of those spaces.

Due to limited time and resources the indoor robotics for OpenADR will be my focus for the foreseeable future, but I’m thinking ahead and have a lot of plans in mind!