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:

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:

Gearbox

 

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

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:

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 http://www.instructables.com/id/Arduino-RC-Lawnmower/ and http://www.robert-smith.net/my-projects/how-to-build-a-rc-lawn-mower/.

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

 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: pixlr.com 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.

Only one year until next Halloween

Here we are on November 1st, 2011.  As the sugar rush from last night dies off, it is a good time to begin planning for next year.

Halloween is a big deal around our place.  Carving pumpkins has always been an epic ritual for my wife and me.  We have done everything from adding Christmas lights as hair to dressing up our jack-o-lanterns in a tux and wedding dress (the year we were married).  Below is last year’s entry: my carving of Yoda.

Sadly, this year we did not participate.  That means that next year, we have to go even bigger to make up for this year.  I’m thinking animatronics.

I purchased a voice recording unit from Radio Shack a few weeks ago and wanted to use that in this year’s pumpkin, but I decided to hold off until I could implement it in a grander scale.  While doing some brain storming, I was suddenly struck with a memory of childhood: eating pizza at Chuck-E-Cheese with a half-dozen animatronic animals singing happy birthday to me.  The part of this memory that has always stuck with me is the eyes.  Always watching!  The livelyhood of the characters came from the eyes darting back and forth.  The rest of their movements were merely gravy.  To me, moving eyes is the key to animating objects.

My goal for my jack-o-lantern was to add eyes that would move in a way that is relevant to the situation.  Anyone can move an eyeball around, but making it move in a way that produces the sense of the object “watching” you is what will make this project worthwhile.  I decided to make my pumpkin’s eyes watch the trick-or-treaters approach the door as they walk up the steps.

In this case, I don’t plan on moving the eyes up and down, but rather just left and right.  In order to find the rotational degree of each eye ball in reference to where the kid is on my sidewalk, there are two variables that need to be considered: 1) the angle made up of where the kid is in relation to the plane of the jack-o-lantern face and 2) the distance between the kid and the plane of the face.  Once I have these variables, I can rotate the eyes left to right in order to point both eye balls directly at the kid.

Here is the approach…

1) Determine the angle and distance variables using a servo-mounted ping sensor.  Ping sensors are ultrasonic distance measurement sensors that send out an ultrasonic tone and then measure the time it takes to receive the echo.  The shorter the time, the shorter the distance (since sound moves at a reasonably stable speed).  By mounting the sensor on a servo and the servo in the dead center of the top of the pumpkin, the sensor can be wiped back and forth over a 180 degree range.  The servo will start at 0 degrees (facing the left ear) and take a distance measurement.  Once the distance has been measured, it will move 1 degree to the right and take another measurement.  This will continue to 180 degrees (right ear).  With distances measured on all 180 degrees, the angle with the shortest distance is picked as the one with the nearest target.

2) Eye balls made of ping pong balls (maybe with LEDs inside?) are mounted on independent servos (one for the right eye, one for the left).  These are mounted inside of the pumkin with the eye balls exposed through the jack-o-lantern’s eyeball sockets.  Two measurements are taken: L and R.  L is equal to the center of the left eye ball to the center line of the jack-o-lantern (on which the ping sensor’s servo is mounted).  R is equal to the distance from the center of the right eye ball to the pumpkin’s center line.  These will be used later.

3) The three servos are controlled by an arduino that is mounted inside the pumpkin.  Since we are using electronics, the traditional candle used to light up the pumpking will need to be replaced with LEDs, but that gives us flexibility for other special effects down the road.  Maybe RGB lighting that fades from one color to another?  We’ll see how that turns out.

4)Using the law of cosines in the code, we can determine the angle of each eye based on the angle of the ping servo and the shortest distance measured, being that the angle and the distance are related at that point of the distance sweep array.

Let’s say the D is the distance measured between the kid and the pumpkin by the ping sensor.  R is the distance between the center line of the pumpkin and the center of the right eye.  P is the angle of the servo at the time that D was measured.  We want to find X which is the angle of the servo mounted to the right eye ball.  To know X, we need to determine the distance of the leg of the triangle opposed to angle P.  In a right triangle, this would be done with the standard pythagrean theorem.  Knowing that it is unlikely that P=90 degrees, we need to use the more extensive one.

c^2=a^2+b^2-2ab(cosY)

Or in our case:

h^2=d^2+r^2-2dr(cosP)

With H determined, we can redo this same equation to determine the angle of x.

d^2=h^2+r^2-2rh(cosX)

Using arccosine, x can be determined to provide the angle of the right eye ball.  The same method would be used for the left eye ball.

5) Once the distance is less than a specified value, the voice recording unit is activated to play back the recorded message.  Personally, I’m thinking of something like, “You aren’t coming for my candy, are you?”  Currently, there is a momentary button used to trigger the playback.  I plan to remove the momentary and replace it with a relay that is controlled by the arduino.  A relay might be overkill, but I also like the idea of isolating the circuits.

As I mentioned earlier, this would all be processed by an arduino.  Below is the shield I designed to interact with the servos, ping sensor, and the relay for the sound module.

So what is that thing?

It has been a while since I’ve made a post. Plenty of projects are going on that I could be documenting, but right now I just need to focus on turning the wrenches. I did have a moment worth discussing, however. Last night, my wife asked me a question that has stuck with me since I have yet to come up with a good answer. Of all topics, I thought this would be a great one to write about.

As I was surfing around some of my favorite diy sites, I stumbled across an article on something or another that was based on an Arduino. Having seen this word and heard me refer to it many times in the past, my wife asked, “What is an Arduino used for?”

This seems like a question that should have a very simple answer, but yet I can’t find it. Unlike duct tape, the Arduino is not meant for one single purpose and then used for a million other things, nor is it like a hammer which is really only good at pounding in nails. The Arduino wasn’t made for any given purpose. It wasn’t designed to solve a specific need. In a case like this, how do you describe the purpose of something to someone who doesn’t have a concrete understanding of the field when the object at hand doesn’t solve a specific need?

The best I was able to muster was a high-level description of what a microcontroller was. It is the brain behind the robots that build cars and the thermostat that controls the heat in the house. It is the computer that electronics use when they don’t use the kind of computer that sits on your desk at work.

I’m interested in what others have to say about this. How would you describe what an Arduino or any other microcontroller is to someone who hasn’t studied electronics?

Washing Machine Buzzer

Sometimes you need to do things the hard way.  This is one of those cases.

A few months ago, our washing machine died.  This one was beyond my ability to fix, so we broke down and bought a new one.  The model we chose had a bunch of fancy features, but the one that was missing was the end-of-cycle alarm.  With our last washer, we had grown used to hearing a buzzer when the cycle ended.  Now the washer stops and we go about our day not considering the wet clothes sitting in the washing machine. 

Any do-it-yourselfer with any self respect would have no problems opening up the control panel and adding a buzzer to the exising “Cycle Finished” light.  My wife, however, doesn’t have that kind of faith in me, so I have to do things the hard way.  Here is the plan:

A photoresistor will be placed over the cycle finished light.  The value of this sensor will be fed into an Arduino Pro Mini.  This will read the status of the washing machine.  When the light turns on, the arduino will activate a 9 volt buzzer (one second on, one second off) for ten minutes.

Figure 1:  Circuit diagram

Figure 2: Arduino code

int buzzcount=0;
int ledstatus=0;
int buzzerpin=2;  // connect to npn base 
int sensorpin=0;  // connect to photoresistor (w/ pull-down)

// preferences ///////
int trigger=512;    //
int buzzlimit=300;  //
//////////////////////

void setup() {               
  pinMode(buzzerpin, OUTPUT);  
}

void loop() {
  setStatus();
  if(ledstatus==1){
    if(buzzcount<buzzlimit){
      buzz();
      buzzcount++;
    }
  }
}

void buzz(){
  digitalWrite(2, HIGH);
  delay(1000);
  digitalWrite(2, LOW);
  delay(1000);
}

void setStatus(){
  if(analogRead(sensorpin)>trigger){
    ledstatus=1;
  }else{
    ledstatus=0;
    buzzcount=0;  // reset to 0 when the lid is opened
  }
}