HAL 9000: Replica Design

For my design of the HAL 9000 enclosure, I mainly used Adafruit’s HAL 9000 replica guide as a baseline.  However, I decided to 3D print most of the pieces since I don’t have access to a laser cutter or any power tools.

This slideshow requires JavaScript.

The only piece that I ended up buying was the button, so I followed that section of the tutorial closely, but mainly used the linked references for the design of the case.

img_0770

Because of the 250x150mm limitation of the print bed, I broke up the case into parts.  The two outside sets of pieces are the vertical walls of HAL, the two pieces with center holes are horizontal walls that will have wiring run through them.  The top piece on the center-left side is the top of HAL.  The piece with a grid of holes is the speaker grill.  Lastly are the two black pieces, which form the main plate with a hole for the red “eye.”  Also notice the black rectangle at the top; this will be the space to put the HAL 9000 label.  I left this to save myself time measuring when applying the label.

img_0779

The next step was gluing all of the pieces together, and HAL starts to take shape!

img_0784

Because the plate is black, even if I don’t cut the label to the exact size, it won’t be noticeable.

img_0788

The last step is popping in the painted button, and HAL 9000 is complete!

One additional step I’d like to use in the future is applying the same coating, sanding, and painting steps I used for the sword on HAL, to make the replica look more metallic and accurate.  This would not only help cover up the seams between parts but would also help me replicate the brushed aluminum look on the original HAL’s black face plate.

 

3D Printed Sword: Design

After OpenADR was not selected as a finalist in the Hackaday Prize Automation Challenge, I decided to take a brief break from working on the vacuum after working in full-fledged competition mode for the previous few months.  I spent a few weeks trying to think up simple projects that would keep me occupied but wouldn’t take up too much of my time.  I also wanted to use this time in between big projects to develop new skills and get outside of my comfort zone a little bit with a project that I wouldn’t normally pursue.  At last, inspired by the wide array of medieval props I saw at the Pittsburgh Renaissance Festival, I decided to 3D print a medieval longsword and attempt to make it as realistic as possible.

Challenges

While 3D printed parts certainly aren’t new territory for me, designing a realistic weapon really pushed me to think through challenges that I had not encountered before. Creating large and unwieldy objects using FDM introduces new constraints in terms of printability and strength.  When creating my own parts from scratch, I have a lot of flexibility and can design pieces while keeping in mind the limitations of 3D printing . For this project though, I had to rethink the design process to make printing possible because I was trying to replicate something that (1) exists in the real world and thus should look a certain way and (2) wasn’t designed to be easily 3D printed.  Strength is also a concern as 3D prints are notoriously weaker than regular, injection-molded plastic parts and can delaminate when too much stress is applied across the Z-axis. I wanted the sword to be as realistic as possible (i.e., long and pointy), so keeping the sword sturdy without too much bending was also a big priority.

In addition to the 3D printing structural challenges, appearance was also a big concern – this too is where I wanted to push myself.  It isn’t easy to pass off a plastic part as metal given the differences in texture and shine.  Furthermore, given the size of the sword, I had to print the blade in segments, and so finding a way to smooth out the joints was a significant problem in addition to the normal visibility of  layer lines. Just designing, printing, and assembling the blade (a.k.a. all the things I already knew how to do!) was the easy part – the bulk of the work was in the finishing stages of making the sword look realistic.

Design

I started this project by researching the general properties of longswords.  I spent a lot of time looking at modern replica swords, movie swords, and historic swords from the middle ages so I could get a good idea of what I wanted my own sword to look like.  Two great references that I found were the Wikipedia page for longsword and the website My Armoury, which has more history, mechanics, and specifications of medieval weaponry than you could ever possibly need.

From those resources, I determined that I wanted a sword, roughly 1.1-1.2m in length, with a blade about 90cm long, 5cm wide, and 5mm thick.  In additional to the dimensions I also wanted accurate blade geometry.  This required me to read up on blade cross sections, profile tapering, and distal tapering.  I also decided to print out the sword in PLA due to its stiffness and ease of printing.

Blade

Mechanics

My primary concern, at first, was the thickness of the blade.  While PLA is stiffer than ABS, it is still pretty bendy when it comes to a meter long part that’s only 5mm thick.  PLA is also brittle so it wouldn’t take much bending to snap the blade.  To alleviate these concerns, I decided that the blade should have steel rods at its core.  I still had plenty of 2mm x 300mm steel rods that I used as axles for OpenADR, and decided to use these.

divisions

The next concern was print geometry.  A meter-long blade obviously wasn’t going to fit on my Printrbot, so I needed to determine how to split it up into multiple pieces.  The two obvious options were splitting it down the middle lengthwise and printing it in multiple left and right half chunks (left image).  Extending this idea, I could have also had the left and right chunks mismatched (middle image) so that it’d be harder for the blade to break along the blue, horizontal lines.  The last option would be printing out vertical chunks of blade (right image) without any bisecting along the long axis.  For all of the options, I planned on using cut sections of 2mm steel rod to hold the parts together.

I ended up going with the last option for several reasons.  My concern with the first two options was warping.  A big benefit of bisecting along the long axis was that it would allow me to print out large chunks on the long, 225mm X axis of my Printrbot.  However, 225mm is a big 3D print and tends to cause warping, even using PLA.  Without the strength advantage of large, sturdy sections there wasn’t much point to the left/right bisection option.  I was also concerned about space for the metal spine and connectors in the first two options.  While a single 2mm rod fits fine in a 5mm blade, the blade thickness quickly decreases due to the distal taper.  It quickly reaches a point where both vertical and horizontal steel rod connectors won’t fit in the blade cross section.  With the last option, all I needed to add was a single vertical rod to hold the segments together.

Aesthetics

2000px-sword_cross_section-svg

With the mechanical design handled, the next step was the aesthetics.  The first thing I tackled was the blade cross section.  It seemed like historically, the most common types of blade cross section were lenticular and diamond, with the former being popular in the early middle ages and the latter becoming more popular in the late middle ages.  Considering this, I opted for the diamond cross section, thinking that its flat features would be easier to sand later on.

bladecrosssections

Despite going with the diamond cross section, I still designed both main options. One of my secondary goals for this project was to make everything available in OpenSCAD so others could design and print their own swords, and so I wanted to design the different options as modules in case someone in the future has more patience for sanding than I do.  I also included the option for fullers.  While I ultimately didn’t include fullers in the blade I made,  mainly due to concerns about thickness and strength, they certainly add aesthetic appeal when included.

blades

The next step was designing the actual blade.  To help simplify the implemention in code, I mostly based the profile taper of my blade designs on mathematical equations, with one custom option as well.  From left to right, the blades shown above were designed as follows:

  • A custom blade that has an array of widths passed in.  To demonstrate this I went with a sawtooth-like design, but it’s currently extendable out to any design as long as it’s symmetrical across the z-axis.  There was no historical precedent for this blade type, but it seemed like a cool option to have.
  • An elongated elliptical blade with the ellipse length and width passed in.  Historically, this kind of blade provided a good compromise between a cutting and thrusting, allowing a wide blade without sacrificing the sharp point.
  • An exponential blade with the width of the blade decreasing exponentially.  Again, this didn’t really have any historical precedent, but it was easy to add and has an interesting aesthetic.  Without a point, this blade would be no good for thrusting but would provide a good cutting edge.
  • A linear blade with the blade tapering to a fine point.  Historically this type of blade was used predominantly for thrusting.

For the aesthetics I was looking for, I went with the elliptical blade because I thought it looked like a traditional middle ages longsword.  With the width of the blade only tapering off at the very point, it also provided a good amount of structural integrity.

Printability

With the entirety of the blade designed, the next step was making it printable.  I quickly refactored the design of the blade so that the 90cm blade is broken up into 18 50mm segments.  The blade segments were then separated and spread out so as to be printable.  I also added ~2mm holes in each segment to allow space for the metal spine.  The width and thickness at the bottom of the blade had enough space for three metal spines, which allowed for an increase in stiffness and strength.

sword

I discovered a problem when adding in the spine, however.  Originally, I kept the distal taper of the blade the same as the profile taper, so the blade was the top half of an ellipse when viewed across both the X and Y axes.  However, while the blade was thick enough to allow for a 2mm hole at the base, this quickly became impossible toward the top of the blade.distaltaper

To alleviate this, I tripled the width of the ellipse (in terms of blade thickness), but capped the maximum value at 5mm.  An exaggerated example of this is shown in the picture above.  The blade is constant 5mm thick for the bottom half, but still tapers off at the top.  Due to how thin the blade is, this modification is barely noticeable.

One thing to note when looking at my OpenSCAD code is that I only made this printability modification for the elliptical blade.  It took some tweaking to get everything configured correctly, and I didn’t want to spend too much time tweaking for blades I had no intention of printing.  I might go back in the future to fix this, but for now the printability and segmentation code will have to be ported to the other blade types to print one of the other blades.

Hilt

With the blade complete, the next step was designing the hilt.  The three parts on a traditional, medieval sword are the crossguard, grip, and pommel.  I was going to design something elaborate and decorative, but decided I’m no artist, and OpenSCAD doesn’t lend itself well to organic and artistic designs.  Instead I opted for more spartan, geometric designs.

Crossguard

guards

The two options in the back were the customizeable options with an elliptical shape in the back and rectangular one in the front.  Two arrays are passed into the modules that determine the width and height of the shape from left to right.  I liked the custom rectangle shape so much that I went with that design for my final crossguard.  The front two options are a flat hilt and curved hilt with pointed edges.

Grip

grip

The grip is just a simple octagonal shape that I made by creating an OpenSCAD cylinder with eight sides.  I designed it to be printed in two pieces because the entire 200mm piece wouldn’t fit on my printer.  I also included a little octagonal segment in the middle, that’s printed separately, in case I wanted a visible separator for the two-handed grip.

Pommel

pommels

The last piece is the pommel.  On a normal sword this acts as both a counterweight for the blade and a means of preventing hands from slipping off the grip.  Since everything is made out of plastic, and because I don’t intend on using this as an actual sword, this piece is purely decorative.

I was originally going to make this part a little extravagant with a gemstone and went as far as designing it, but decided to go with a simpler approach to keep with my minimalist design.  The left design is the gemstone pommel.  The four holes in the base cylinder are meant to have paperclips inserted that can then be bent to hold in the stone.  For gemstones I was intending to use some fake pirate gems I found on Amazon, but a gemstone mock-up was provided in the OpenSCAD design as a visual reference.

The design I ended up using is on the right.  It’s a simple low-poly shape and went well with the rest of the hilt.  It’s an octagonal shape made in the same fashion as the custom blade and crossguards with a customizeable array that determines the radius of the octagon.

With the design work all finished, the next steps are printing, assembling, finishing, and then finally painting the whole thing! So next post – Keith gets crafty!

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: 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:

IMG_0620.JPG

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.

IMG_0623
Standard dog hair
IMG_0401
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

IMG_0513.JPG

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.

IMG_0617.JPG

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

IMG_0519

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.

IMG_0525

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!

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?

Filament Quality

Between the end of my development cycle at work and my vacation last week, I haven’t had as much time as usual to work on OpenADR.  I also hit a big snag as far as 3D printing the parts goes and learned a lesson about 3D printing in the process: invest in good quality filament.

A few weeks ago when I ran out of the black, PLA filament I was using and switched over to white Argos PLA given the lower cost. I started noticing my extruder making worrying noises a little later but did not immediately make the connection to the new, cheaper filament.  The extruder motor had started skipping and made clicking noises as it unsuccessfully tried to feed plastic.

IMG_0532

The print layers were unevenly laid down and even missing in places.  Above is a picture of one of the navigation module’s sidewalls printed using this filament.

Assuming something had gone wrong with the printer, I started searching online and trying to debug the issue with the extruder.  I tightened it, loosened it, changed the hot end temperature, and added a cooling fan to the motor, but I was still unsuccessfully printing even at 10mm/s (the Printrbot Simple Metal is rated for 80mm/s).  Finally, I ordered some new filament and, lo and behold, the problem went away!  I was back to printing out parts at normal speed.

IMG_0531

Above is the sidewall printed with the new filament.  The layer lines are barely visible when printing with roughly the same settings as the white PLA.

So lesson learned, good quality filament is very important!  I tried using cheap filament and paid for it.  I’ve fallen a bit behind where I want to be on OpenADR, but unexpected delays are all part of the design process and I’ll work to catch up before the contest ends on Monday.

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.

module gear(num_teeth)
{
num_slices = 20;
//rotate_angle = ((360 / num_teeth) / 2);
rotate_angle = 0;
union()
{
for (zScale = [1, 1])
{
scale([1, 1, zScale])
linear_extrude(height=5, center=false, convexity=10, twist=rotate_angle, slices=(num_slices / 2))
{
import (file = str("Gear_", num_teeth, ".dxf"), layer = "", origin = 0);
}
}
}
}

view raw
Gear.scad
hosted with ❤ by GitHub

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: Navigation Chassis v0.2

Based on the results of the first motion test, I made several tweaks to the chassis for version 0.2.

IMG_0476

  • As I stated in the motion test, ground clearance was a big issue that caused problems on carpet.  I don’t know the general measurements for carpet thickness, but the medium-pile carpet in my apartment was tall enough that the chassis was lifted up and the wheels couldn’t get a good purchase on the ground.  This prevented the robot from moving at all.  I’m hoping 7.5mm will be enough ground clearance, but I’ll find out once I do another motion test.

IMG_0478.JPG

  • I added a side wall to the robot to increase stiffness.  With the flexibility of PLA, the middle of the robot sagged and as a result the center dragged on the ground.  Adding an extra dimension to the robot in the form of a wall helps with stiffness and prevents most sagging.  My first attempt at this was in the form of an integrated side wall, allowing the entire thing to be printed in one piece.  This, however, turned out to be a bad idea.  With the wall in the way it was extremely difficult to get tools into the chassis to add in the vitamins (e.g. motors, casters, etc.).  DFM is important!  So instead of integrated walls I went for a more modular approach.

IMG_0480.JPG

IMG_0479.JPG

  • The base is much like it was before, flat and simple, but I’ve added holes for attaching the side walls as separate pieces.  The side walls then have right angle bolt hole connected so the wall can be bolted on to the base after everything has been assembled.

IMG_0483.JPG

  • One thing I don’t like about this method is that all of the bolt heads that will be sticking out of the bottom of the chassis.  I’d like to go back at a later time and figure out how to recess the bolts so the bolt heads don’t poke though.
  • With the stiffness added by the side wall I decided to decrease the thickness of the chassis base and wall from 2.5mm to 2mm.  This results in saved plastic and print time.
  • Adding the side wall had the downside of interfering with the sonar sensor.  I’m not too familiar with the beam patterns of the HC-SR04 module, but I didn’t want to risk the wall causing signal loss or false positives, so I moved the distance sensors outward so the tip of the ultrasonic transducers are flush with the side wall.  Unfortunately, due to the minimum detectable distance of the sensor, this means that there will be a 2cm blindspot all around the robot that will have to be dealt with.  I’m unsure of how I’ll deal with this at the moment, but I’ll most likely end up using IR proximity sensors or bumper switches to detect immediate obstacles.
  • Other than the above changes, I mostly just tweaked the sizing and placement of certain items to optimize assembly and part fits.

This is still very much a work in progress and there are still several things I’d like to add before I start working on the actual vacuum module, but I’m happy with the progress so far on the navigation chassis and think it’ll be complete enough to work as a test platform for navigation and mapping.