Lawnbot Transmission

Having decided to use the worm gear motors that I found at the local surplus store, my job of gearing down the drive speed became much easier.  As I mentioned in an earlier post, these motors run at about 180 RPM and they already have a ton of torque.  I need to gear this down to about 20 RPM, and I’ll gladly take more torque, so a gearbox is in order.

The math here is pretty easy; the motor turns at 180 RPM and I want a final output of 20 RPM.  180:20=9:1 gear ratio.  The simplest route would be to use one tiny gear and one huge one, say a 10 tooth and a 90 tooth.  Given that the main body is only 12″ tall, a 90 tooth gear would have to have a pretty small tooth in order to have a small enough diameter.  Since I’m initially making my gears out of MDF (later to be cast in ABS plastic), I need to have a fairly large tooth, so a 90-tooth gear is out of the question.  Instead, I’ll compound the gears, allowing me to use multiple gears with fewer teeth per gear.  What I have decided upon is two pair of 21 and 7 tooth gears.  21:7=3:1.  3:1 + 3:1 = 9:1.  Yay!

A single pair of 21:7 gears looks like this:

gear model

For a full size image, please see the pdf copy here.

The motor turns the smaller gear, which turns the larger gear at one-third the speed.  At this point, the second pair is added.  First large gear that is turning at one-third the motor’s speed is directly connected to the second small gear.  This means the second small gear is also turning at one-third the motor’s RPM.  The second small gear turns the second large gear.  Since the second large gear turns at one-third the speed of the second small gear, which is already turning at one-third the speed of the motor, the second large gear turns at one-third of one-third, or one ninth the speed of the motor, hence 9:1 gear ratio.

Here is what the whole thing looks like assembled:




H Bridge

As I mentioned in earlier posts, an H bridge is a type of circuit that allows a motor to be controlled by a micro controller.  Both the speed and direction of the motor are controlled by output pins on the microcontroller.

In the image below, the motor is in the center of the H bridge.  The H bridge circuit is made up of four NPN transistors.  Two act to provide voltage (Q1 and Q2)  and two act to drain the voltage to ground (Q3 and Q4).  The transistors are controlled by two PWM outputs.  PWM means that the output pin can be turned on and off at such a speed that it appears to have a varying voltage, as opposed to a normal output pin that can only output a single voltage, based on the type of micro controller.

Let’s take a look at what happens here.  Let’s say that D10 has no output and D11 produces a duty cycle of 50%.  In this example, Q1 and Q3 would receive 50% power at the base (the horizontal line coming out of the transistor).  The percentage of power going to the base equates to the amount of power that passes from the collector to the emitter (top pin and bottom pin of the transistor, respectively).  If the battery in this example is a 12 volt battery and the base is getting a 50% duty cycle, roughly 6 volts passes through Q1, into the motor, and out through Q3, completing the circuit.  If the duty cycle of pin 11 goes up from 50% to 100%, Q1 and Q3 will pass all 12 volts through the motor, causing the motor to increase in speed.

Let’s say that pin 11 goes low (no output).  With both pin 10 and 11 low, all four transistors receive no power at the base, meaning that no power can pass from the collector to the emitter.   If no power passes this way, the motor does not get any power and it comes to a stop.  If pin 10 goes to 100% now, Q2 and Q4 receive power at the base, allowing electricity to pass through that line.  Power comes from the battery, through Q2, through the motor, through Q4, and back to the battery.  Since this circuit passes a voltage through the motor in a different direction, the motor spins a different way.

H bridge schematic

H bridge schematic

Lawnbot v.2 Electrical

I’m happy to report that this project is going to be significantly cheaper than I expected.  This is due to the fact that I was originally planning on driving everything off of cheap cordless drills from Harbor Freight.  Yeah, that would have worked, but even the cheap ones are expensive enough.  He hero to all of this: Ax Man, the local surplus store.

On a recent trip to Ax Man, I found a pair of worm-gear motors.  They are 12 volt motors geared down to about 180 RPM.  They were initially designed to be motors inside of motorized car seats in Daewoos.  That doesn’t really matter.  The important part is that they are cheap and they run at a much slower RPM, which means the final gearbox is going to be much less complicated.  Yay, Ax Man!

I’ve begun laying out the electrical work on the new lawnbot.  The following is a schematic of how the whole thing will work:

electrical system diagram

The system centers around a simple sealed lead acid battery (SLA).  The one I’ve picked out is for a garden tractor, available from Menards for about $24.  I will keep the battery charged using a trickle/float charger.  By float-charging the battery, I can leave it plugged in without fear of overcharging.  An automotive switch is connected to the battery and in turn, powers a bus.  Everything else connects to the bus.

An arduino will be used to control the unit.  The arduino is powered by the bus via the arduino’s built-in barrel jack.  When the power switch at the battery is turned on, the arduino will boot.  The arduino will use pins 5, 6, 10, and 11 to control two H-Bridge circuits.  I promise that I’ll have a post on what an H bridge is soon enough.  The reason these pins are used is that these are the output pins of the arduino that can produce PWM.  PWM is a way of turning a circuit on and off fast enough that it actually looks like a varying voltage.  While the arduino can’t output an analog voltage, it can vary the PWM in such a way that other systems will see the output like a 0-5 volt analog range.  This analog-like signal is important to the H-bridges because they control the speed and direction.  The higher the simulated analog voltage coming from the PWM pins, the faster the motor will turn.  Each H-bridge gets two PWM signals: one for forward, one for reverse.

Lastly, a digital output pin on the arduino is used to switch a relay for power output.  In this case, the pin is #2.  The output will be used to power things like the cutting head of the mower attachment.  It may  also be used to power an inverter if an AC device is required.

Lawnbot 2.0

Over the past few years, I’ve seen several renditions of remote control lawn mowers.  I LOVE THIS IDEA.  Yeah, I love the idea enough to use all caps.  Let me tell you why…

In high-school, I worked at a Subway.  This means that every day for months on end, I ate at Subway.  Eating at one place that frequently for that long will make a person quite sick of that food for a long time.  To this day, I still can’t eat there.  I don’t have any problem with Subway as a whole; I think they make a great product.  I’m just still sick of it after twenty years.  Similarly, I used to mow lawns in junior high and high school.  In an average week, I’d mow four yards.  Fast forward two decades and I still hate the idea of lawn mowers.  It just reminds me of wasting perfectly good summer days pushing a heavy object up a hill, smelling like gasoline, and not getting compensated fairly for the work I did.

Seeing articles of people who have circumvented the torment of mowing a lawn by leveraging technology, I couldn’t help but think, “This is the greatest idea ever.  Move aside fire and sliced bread.”  I began to plan my own implementation of a remote control lawn mower in a similar fashion to what I had seen before.  The style of implementation uses an existing lawnmower, but removes the wheels from the cutting deck and adds the cutting deck to a remote control platform.  For examples of this, see and

While there are benefits to this approach, I began to deviate.  I asked myself, “Why does it need to use a gas engine?”  At this point, I decided that maybe I’d make mine electric.  Then I asked, “Why does it need to use a lawnmower blade?”  If a string trimmer can cut grass, perhaps a heavy metal blade is overkill.  I lastly asked, “If it doesn’t have a gas engine or a blade, what does it have in common with a lawnmower deck?”  The answer is, “Nothing.”

During this time, I also thought about what I didn’t like about the existing style.  Mainly, this was that the wheels were too far out from the cutting deck.  Lawn mowers are difficult enough to turn when the wheels are bolted onto the deck itself.  When the deck gets bolted onto a longer frame, that puts the wheels much further out from  the deck, creating a longer wheel base.  Long wheel bases might be great for adding stability to cars, but it sounds terrible in terms of steering a lawnmower.  The extra depth also creates a longer depth of area between where the unit butts up against something and where it can cut.  If you drive it up to a fence, there is a certain distance between where it hits the fence and the blade.  Several inches along this fence will never get cut since the blade can’t reach it.

At this point, I felt liberated from the original platform.  I hate the phrase “paradigm shift”, but that is what happened.  I began to think of what needed to happen on a high level without considering form.  I put the cutting head in a place where it can get up to what I’m trying to cut.  This allowed me to decouple it from the rc robot base.  I eventually came up with a robot base with tank treads that has a mount onto which the cutting head is attached.

Diagram of the lawn bot

Diagram of the lawn bot

 The base unit is simply a plywood box.  It is 18″ wide x 24″ long x 12″ tall.  The wheels and tank treads are the more interesting part of the build.  I’ll cover that in a later post.

The cutting head is made up of three gears.  These gears are patterned off of Matthias Wandel’s gear generator.  The center gear is a 32-tooth gear and the two outer gears are both an 8-tooth gears.  As the center gear turns, the two outer gears turn at four times the speed.  Attached to the bottom of the small gears are hubs for string trimmer line.  The diameter of the string trimmer cutting path of each cutting head is 12″.  Having two side by side gives an overall cutting width of 24″, which is pretty good for a lawn mower.  See the full-size printable patter for these gears here.

Now the real fun begins.  How do we get all this stuff to move?  I need three points of rotation: cutting head, left wheel track, and right wheel track.  Let’s start with the cutting head. 

Since the cutting head is based on the principle of a string trimmer, the goal RPM is roughly that of a regular trimmer.  These run about 3,000 RPM.  Since the spool gears are 1/4th the size of the drive gear, the drive gear should run at 1/4th the final output rotation, which is roughly 750 RPM.  In this case, we need an electric motor that can spin at 750 RPM and handle enough torque to spin the cutting heads (considering they have been geared up for speed).  A basic cordless drill not only operates off of a batter that can be contained within the base unit, it also spins at roughly 800 RPM.  If the drive gear of the cutting head has an output shaft of 3/8″ or less, the drill can chuck directly up onto that.  Instead of having the battery in the drill, the battery is house in the base unit.  A solid state relay sits between the battery and the drill and is actuated by a microcontroller.  The trigger on the drill is held in with a zip tie.  When the microcontroller sends the 5 volt control signal to the solid state relay, the power from the battery is sent to the drill.  The drill turns the drive gear at 800 RPM.  The drive gear turns the outer gears at 3200 RPM, which spin the trimmer string to cut the grass.

And now for the wheels.  The base unit will be a tank-tread style vehicle.  This means there is a wheel that is covered by a tank tread.  The diameter of the wheel plus the tank tread above and below is a total of 8″.  At this diameter, one rotation of the drive wheel will move the unit 25.12″.  My goal speed is about 8″ per second, or 480″ per minute.  480 inches per minute / 25.12″ circumference=19 RPM.  This is pretty slow.  I like the idea of using a cheap rechargeable drill for each side, like I did with the cutting head, but going from 800 RPM to about 20 means a 40:1 gear reduction or a severe cut in voltage.  Assuming the drill motor is linear in its relationship between RPM and voltage and the drill is rated for 12 volts, this would mean 0.3 volts if we only went by voltage.  Since that would be difficult to create efficiently, a combination of voltage drop and gearing is necessary.  I’d much prefer using gears anyways since that will also increase the torque to the wheels.  I haven’t designed the gearbox yet, but watch for a later post.

Since this is a track-type vehicle, the left wheels turn together and the right wheels turn together.  In this case, only one of the two in each pair need to be powered.  For example, the shaft for the front left wheel is connected to a motor and the shaft for the rear right wheel is connected to another motor.  Both could be in the front, both could be in the back, it doesn’t really matter as long as one is driven on each side.  To turn the vehicle, each motor needs to be able to reverse.  As one side goes forward and the other in reverse, the vehicle turns.  An H-bridge will be used to control each motor.  An H-bridge is a type of electronic circuit that controls the speed and direction of a motor based on the output of a micro controller.  Much like the solid state relay in the cutting head, the H-bridge will sit between the battery and the drills that are used as the motors.  This will allow me to control the speed and direction of the rotation on each side of the unit.

Watch for updates.  I will also shed details on the controls in a later post.

3D Scanner

I love Sparkfun.  I’m on their site at least once a day.  I love looking at all of their new products and getting ideas for projects I’d like to try.  I love Sparkfun so much that I even made the pilgrimage from St. Paul, MN to Boulder, CO in September, 2011 just so I could stand in their warehouse and imagine what it would be like to have 24 uninterrupted hours with all of the supplies at hand.

One product that Sparkfun recently started carrying is a motorized slide potentiometer, or slide pot.  This component is similar to the slide pots inside of mixing boards in recording studios.  Not only can a person manually side the pot up and down to create resistance (think of a dimmer switch on a light bulb), but it is also motorized, allowing a micro controller to move the slider to a specific point as well.  The idea is that a preset point or set of points could be stored and a micro controller could override the manual setting with an automated one.

That’s spiffy enough as it is, but let’s look at it from the reverse.  The motor is moving the slider along a linear path.  Basically, that is a linear actuator.  The difference between a normal linear actuator and this is that this product has the built-in pot, which sends an analog signal back to whatever is controlling the motor to say where along the linear path it exists.  Since these are 10k linear pots, we can say that if the micro controller receives 7k of resistance, it is 70% of the way across the slide.  If we want the slider to be at 40%, the micro controller can send the signal to the motor to move it down the slide until it reaches 40% and it stops at that point.

At this point, we can control where an object is along a one axis over the course of the length of the slide pot.  One axis is pretty cool, but let’s take it up a notch and add a second axis.  If a second pot where mounted to the slider of the first pot perpendicularly, this would give us two axis of movement.  The original would move across an x-axis and the second would move across the y-axis.  As the x-axis slider actuates, the y-axis slider is moved across the x-axis.  The slide of the y-axis slider creates the y-axis movement.

Now we have control over a mount whose position can be controlled over two axis.  What is cooler that this?  Lasers.  That’s right, we are adding lasers tot he mix.  Hot damn.

While Sparkfun can be the source of most things awesome, there are some sites that sill need to be reviewed for the awesome things that Sparkfun might not carry.  For example, Parallax has some pretty exciting components as well.  The slice of heaven I found yesterday was the laser range finder.  This sensor shoots a laser at an object and reads the distance to the point where the laser hits it.  Oh, 21st century, how much do I love you.

According to the laser range finder documentation, it works best when the distance it is reading is between 6 and 48 inches, but it can read distances up to 8 feet.  Yep, this will do nicely.  By adding the laser module to the existing x/y articulation platform, perpendicular to the x/y plane, we can now measure the distance from the module to a three-dimensional object (z-axis) among all points on an x/y grid.

The procedure would look like this:  The micro controller would utilize four digital output pins, two for each slide pot.  As one pin goes high for a specific slider and the other goes low, the slider will move in one direction.  If the first goes low and the second goes high, it will move in the opposite direction.  If both are low, it will stop.  The slider pot also receives 5 volts from the micro processor and returns the analog voltage to an analog input for reading.  This is done on both sliders as well.  The laser range finder uses a serial output, which is read by the micro controller.

The micro controller reads the x and y axis from the analog inputs and sets both sliders to 0 as necessary.  The micro controller then reads the serial input from the range finder.  Knowing that it set both x and y to zero and learning the distance of z, all measurements for that x/y/z point are now available and written out to something (micro sd card, usb out, etc).  The micro controller then moves the x-axis slider one unit (the distance of the unit depends on the resolution of the slider motor) and a new x/y/z point is created.  Since y hasn’t moved, it would have the same value, but x would definitely be different, and z may have a different value based on the object being measured.  Once the x axis is maxed out, it is brought back to zero and y is incremented one unit.  When both x and y are maxed, all points have been mapped.  The array of x/y/z coordinates can then be piped into a 3D rendering program or 3D chart application for display on the computer, thus producing a 3d scanner.




Changing the course of the river

When my dad taught me about electronics, he compared electricity to water.  He told me that amperage is like the diameter of a pipe: the greater the diameter, the more water is in the pipe.  Voltage is the pressure that the water is under.  The more pressure, the faster the water moves.  Regardless of how high or how low either value is, the water will always want to flow in one direction.  For years now, I’ve thought of electronics like plumbing because of this description.  Not to say that it hindered my understanding of circuits, but it wasn’t until this past weekend that I realized that not all “plumbing” has to go somewhere.

A few months ago, I was at the local surplus store, picking up some odds and ends for projects that I may want to attempt someday.  There was a pile of seven segment displays (the kind of component that has 7 lights that create numbers, given the correct pattern) for something like a quarter a piece.  I picked up a half dozen, but never got around to playing with them.

On Saturday, I decided it was time to try some of these new components out.  I grabbed the 7-seg displays and thought it would be fun to see what I can do with them. I went into all of this assuming that each LED segment within the display had its own dedicated anode (positive voltage) and shared a cathode (ground).  This would be considered a common-cathode display.  I assumed as much because, like water, electricity flows in one direction: down to the ground.  If the electricity in all of the segments of the display will eventually end up at the ground, it would make sense that the display would funnel all of the power to the same common ground.

I found the part number on the side and did a google search for it in order to find the datasheet.  The datasheet contained the pin description so I could map which pin would light up which segment of the display.  To my dismay, I found that the display worked in the opposite manner than I expected.  It contained a common anode (the power came in on one pin) and then each LED segment had its own dedicated cathode.  Since I have always equated a cathode to the ground and there is only one ground, I wasn’t sure how I was going to switch the individual LED circuits on and off if they all shared a ground.

My first thought was that each cathode could be switched by a dedicated transistor.  What a pain!  That would mean that for every display, there would be a set of seven transistors.  Not only would that take up a ton of space on the pcb board, it would break the bank on transistors.

It then occured to me: I don’t necessarily need to stop the current to turn off the circuit.  I could stop it by reversing the flow.  A river flows in one direction unless something changes downstream.  The direction of the Mississippi river was once changed due to an earthquake.  The force downstream pushed back on the force upstream.  Since the downstream force was greater, the standard flow of the river changed.  Why not do the same thing with electricity?

Electricity flows to the ground because there is the least amount of resistance there.  All I need to do is push back on the individual cathodes, and the flow of electricity won’t pass through.  I know that the supply voltage to the common anode is a little short of 3 volts (3.3 volts with a resistor).  Any voltage greater than that supplied to the other end of the circuit will reverse the voltage through that circuit.  The lights of the seven segment display are made up of LEDs, the power can’t move backwards (the diode will block the voltage from going the wrong way), it doesn’t move backwards.  The end result is that it can’t move backwards and it can’t move forwards.  The electricity just stops.  Since there is no flow of electricity, the circuit turns off.

This makes it easy.  I can supply 5 volts out of the I/O pins, which I can turn on and off through the software.  For example, the cathode side of one of the LEDs is connected to pin 2 of my Arduino and the anode side is given 2.8 volts.  If I turn pin two on, five volts are pushed towards the cathode and blocked by the LED.  The 2.8 volts from the other side can’t overcome the 5 volts, so the circuit has no flow and the light is off.  If I then turn pin two off, the cathode side of the LED has less than 2.8 volts, allowing the voltage from the anode side to flow through, lighting the LED.

Yay, it worked!  I attached each cathode to its own pin on my Arduino.  I wrote a sketch (Arduino program) that turns on and off each I/O pin in such a way that it creates the correct combinations to create numbers on the seven segment display.

Where do we go from here?  Well, there are several ways to expand this.  First, several seven segment displays could be connected in parallel.  This would cause the same digit to appear on multiple displays.  From there, using a transistor for each common anode (per display), the displays can be turned on one by one, a number is displayed, and then the display is turned off and the system moves onto the next display.  If this happens fast enough, it will appear to the human eye that all displays are on all of the time, but showing different numbers.  Given 14 I/O pins on my Arduino, I can get up to seven 7-segment displays in a row.

Another option is this: instead of having a dedicated I/O pin for each segment, it would be possible to controll the cathodes with a shift register.  This means that the Arduino would only need three I/O pins to controll up to eight outputs on the shift register.  Seven of the eight control the seven segment display.  The eighth pin can control the transistor mentioned above to turn on power to the common anode of the display.  Since shift registers can be daisy-chained nearly indefinately, it is possible to have a huge string of displays all being controlled by three pins on the micro controller.

Oh, cloud. What can’t you do?

A week or so ago, I was at my friend’s place and was playing with his IPad. I don’t have any type of tablet myself, but once I win the lottery, watch out. I am intrigued by the functional ability of such small form-factor devices (IPads, IPhones, IPod Touches, Android tablets, etc). I guess I’im looking at these things through the eyes of someone who once had a 286 with dual floppy drives. I don’t mean the nifty 3.5″ either. I’m talking the 5.25 drives.  Remember using a paper punch to make your single-sided disk double sided?  Yeah, those disks.  That thing took up my entire desk.

I realize that I need to change my approach on functionality of mobile computing.  Yes, the processor in my iphone is a monster compared to even desktops that are a few years old, but how it is used is different.  Can it do image manipulation such as photoshop?  Sure, but that would put strain on everything else such as memory and data storage.  How do we unload such bulk from computing while keeping functionality?  Instead of hording the latest and greatest technological architectures, let’s steal from the best technology of the 1960s: thin client.

Going back to my childhood, I remember being amazed that every checkout lane in the grocery store was able to know the price of a loaf of bread.  I was amazed that whenever the price of that loaf of bread changed, someone would have to go around to each register and update the price in each individual register.  Obviously, it doesn’t work that way.  None of the registers have the ability to store the price of any given product.  Instead, they are all connected to a centralized computer that does all of the pricing.  Fast forward to present day: is a website that allows web-enabled devices to execute the functions of photoshop.  Now any system with a web browser can edit photos without having photoshop A) installed and B) using system resources.  The processing and storage exists on some server “out there” somewhere.  The final result is sent back to the user and the device at hand (most literally) doesn’t even know what is happening.

Call it cloud computing, thin client computing, or voodoo for that matter, this gives us immense flexibility.  All a device needs to be able to do at this point is connect to a resource that is designed to accomplish a task and then send the result back.  Any new task that is designed can get its own existance out in the cloud.  Once the user knows where to look for it, the mobile device has everything it needs to add the given functionality to its Batman-style utility belt.

So I got to thinking the other day; can I program my Arduino through the cloud?  If I can use photoshop on my IPhone using a cloud app, why couldn’t I do a little bit of programming?  After doing a little research, I found that there are apps out there that allow users to develop applications through web-enabled devices.  The one I have been playing with for the past day is Compilr.  This web site allows user to develop applications in C#, VB.Net, Java, PHP, Ruby, C++ JavaScript, and Python.  Not a bad list!  The web application contains an IDE (programming environment) that looks a whole lot like the professional ones.  It allows you to write code, build and compile, and download the application once complete.  The cool thing about a site like this is that it could be used via an IPad or Android tablet if the developer wants to bring his or her mobile device to the beach, etc.  Yeah, laptops used to be the tool of choice for this, but at some point, nobody wanted to carry one of those along with them anymore.  Apparently, laptops are too bulky.  Go figure.

Conceptually, this is exactly what I’m looking for.  I could write code, store it on the cloud, and then pull it down when I’m ready to deploy it to the Arduino.  The problem with Compilr, however, is that it doesn’t have an environment for Wiring, which is the language used by Arduinos.  I could use the C++ environment, which would be close enough for my purposes, but I want something that is native.  Furthermore, since there is no native support for Wiring, the application can’t be built on the cloud like it can with the supported languages.  Ideally, a user should be able to plug an Arduino into the tablet in some way or another and then click a Build button on the top of the IDE screen and have it automatically tranfer to the Arduino automatically.  I might be asking too much, but it is worth bringing up.

So here is another project I’d like to attempt.  I want to write an ASP.Net web application that acts like the Arduino IDE, including the color coding for recognized terms.  I also want to add in automatic indentation and click-to-add code (insertion of where/for loops and other skeleton code).  It will also include a funtion to upload a zip file that includes new libraries.

Initially, I think that the user will need to copy and paste the final code into the Arduino IDE for compilation and uploading to the Arduino board, but later attempts will try to skip this requirement.