8:21 PMfailurebos 5
May 27th, 2006
The objectives of the FailureBot project originated simply as "build a line-following robot". However, it somehow evolved into a 3-year robotics experiment. My first attempt to build a robot was such a complete failure that I jokingly called it "FailureBot". The name seemed quite appropriate even as the project evolved as every one of the many, many failures yielded a critical lesson in the robot-building process.
For me, hobby robotics is about creativity. I didn't want to throw a couple sensors on a robot kit, I wanted to build it from the ground up. Looking through catalogs, reading datasheets, and building the robot within the constraints of my limited resources was the ultimate experience. Much of this robot is built from raw materials and hardware available at local hardware stores-- and done so on a very limited budget. Throughout the process, I kept a couple of concepts in mind:
A line-following robot, or "line follower" is a pretty common type of robot for hobbyists. Robotics competitions usually have a line-following event. The line is usually a black line about 3/4" wide, such as black electrical tape, on a white surface. Advanced courses may add new challenges such as inclines, tighter turns, intersections, thinner lines, or changing line colors. The robots typically sense the line by measuring light reflected off the ground, where a black line reflects little/no light and the white floor reflects a lot of light back.There are TONS of websites relating to line-following robots as it's a very common beginner project. The Robot Room has some great information on a couple of line following robots.
FailureBot 5 is actually a fairly good robot base which could easily be adapted to maze solving, obstacle avoiding, or other applications of a small, 2-wheeled robots. However, at this point in time, it only follows a line. The robot consists of 2 plastic round decks, differential drive using 2 DC gearhead motors, a sensor board with 5 photo-transistor/LED sensors, an L293D H-Bridge motor controller board, and an Atmel ATMega8 processor board.
A sensor board with 5 sensors shines light downward at the ground. If the line is underneath the sensor, then the little/no light will be reflected back to a paired phototransistor. If the line is not underneath the sensor, more of the light will be reflected back. A microcontroller measures the output of each of the phototransistors through it's analog-to-digital converter (ADC). Based on the position of the line underneath the robot, the microcontroller adjusts the speed/direction of the DC motors to steer the robot.
Building the robot was the hardest part for me. I am by no means a mechanical engineer and had a lot to learn. FailureBot 5 is a round, 2-deck, 2-wheeled differential-drive robot.
A differential-drive robot works like a tank. The two wheels provide both the drive and the steering. By stopping one motor and not the other, the robot pivots on the stopped motor to turn. By turning one motor forward and the other motor backward, the robot turns in place. The wheels are offset forward slightly and a caster is placed in the back of the robot for support.
The base and second deck are 0.118" thick x 6" diameter Acrylic Circles purchase from Tap Plastics for $1.95 ea. They were cut to allow the wheels to be mounted within the diameter of the acrylic circles. The cutting as well as drilling holes for mounting motors and electronics was all done with a Dremel rotary tool. A piece of paper with drill/cut marks was taped over the acrylic circle as a guide for cutting. A piece of aluminum foil was also taped to the under-side of the second deck and connected to ground to serve as a sheild between the motors and the processor board.
The decks are connected to each other using 4" 6-32 screws with 6-32 hex standoffs spacing the 2 decks apart. I have no idea where I got the hex standoffs, but I'm sure they're pretty common.
In earlier attempts I had problems with motors not having enough torque to properly move the heavy robot bases I was building. I decided to buy gearhead motors with a very high torque and use larger wheels to make up for the loss in RPMs. There are 2 Lynx Motion Planetary Gear Motors (12vdc 189:1 31rpm) ($11.40/ea) which drive the two wheels. Each wheel is made out of two 4" round discs bolted together with 2 washers spacing them out. The discs are from Home Depot ($1.49/ea) which are used to cover electrical boxes. A 4" O-ring (also from Home Depot) sits in the gap between the two discs to serve as tires. These relatively large wheels allow the slower motors to suffice for moving the robot quickly. They are also nice and thin giving the robot the ability to easily turn by pivoting on one wheel. The wheels were then attached to the motors using a pair of the 6mm Universal Wheel Hubs from Lynxmotion ($8.00).
The motors are then mounted to the base using a homemade motor mount. Although Lynxmotion also sells motor mounts, I had already felt I had spent enough money on the motors. Home Depot (or Lowes, etc) has a section with weather stripping including long pieces of aluminum in various shapes and thicknesses. I picked up a right angle strip (4" wide piece of aluminum folded at 90 degrees) and cut it up using--once again--the Dremel rotary tool.
The motors are mounted slightly forward from the center-line of the robot and a caster from Home Depot ($2.95) was mounted in the back/center of the robot.
The sensor board was one of the only things that worked since the very first FailureBot. There are 5 line sensors. Each line sensor consists of a single red LED and a photo-transistor. The electronics of the sensor board will be discussed later. However, the construction here does make a difference. The phototransistors will be sensitive to the ambient light in the environment and thus I want to keep that down to a minumum. I want the light from the LEDs bouncing off the ground back to the phototransistor to be the primary light hitting the phototransistor.
I used a piece of acrylic plastic (Home Depot and Lowes sell acrylic rectangles for a few bucks) which I spray painted black in numerous thin coats to ensure that it was opaque. Then, holes are drilled for the LEDs and photo transistors such that the LEDs protrude out and the phototransistors are set in a bit (see my sketch below). I wasn't too concerned with one sensor being skewed or protruding more/less as I knew I could have each LED independently calibrated via software (discussed later).
Finally, two 3" 6-32 screws with locknuts and wingnuts are used to attach the sensor board to the robot. This way, I can adjust the distance of the sensors to the ground manually by moving the locknut up/down.
The motor controller is a simple H-Bridge using the L293D ($2.70 from Digikey). 5 lines from the microcontroller are used to control the 2 motors. ENABLE runs directly to the EN pins of the L293D to disable the motors. M1DIR is the direction control for the left motor and M2DIR is the direction control for the right motor. M1PULSE is the PWM signal to run the left motor at it's desired speed (at the time of writing, the software isn't using PWM but running the motors at full speed) and M2PULSE is the same for the right motor. This is a very common DC motor control concept and thus I'm not going to go into further detail. A Google search will return numerous pages on the topic.
When testing the motors, I found that they pulled 50mA with just the wheel spinning freely and 590mA stalled. The L293D can handle 600mA per channel. Just to be on the safe side, I put a heatsink on the L293D though It was never necessary in any of the earlier versions running on a breadboard.
The most important thing I learned with this part was this: BEWARE OF THE NOISE FROM MOTORS! The motors can add tremendous noise to the supply even when using a separate battery for the motors than from the rest of the electronics (common ground). The solution was the capacitors on the motors. Three 0.1uF capacitors were used on each motor. One was connected between the motor terminals, and also one from each terminal to the motor's casing. I also added the aluminum sheild to the under-side of the upper deck as mentioned above, and twisted the wire leads to the battery. Michael Simpson's "Reduce Motor Noise" discusses these techniques in more detail.
(Click to Enlarge)
For each sensor, I used a SSL-LX5093SRC/E RED LED with a clear lens in a T1 3/4 package ($0.54/ea from Digikey) paired with an OP505B phototransistor ($0.59 from Digikey). Since phototransistors are designed for the infared frequency spectrum, I was looking for an LED with a relatively high peak wavelength and a phototransistor with a relatively low peak wavelength, or at least a broad bandwidth, so that their active bandwidths overlap. I had read that you don't want to use infared LEDs for line detectors as infared light does have the same reflective properties as visible light. In rhetrospect, I was being a little overly concerned here. I believe just about any red LED and phototransistor would have sufficed considering the ability to calibrate the sensors via software.
I did not want to deal with difficult hardware for the sensors. I knew the tools I have at my disposal will not allow perfection in terms of mounting these LEDs and getting each of the 5 sensors to behave the same. Each of the phototransistors outputs are tied together resulting in a single output line fed back into the ADC of the microcontroller. However, only one LED is turned on at a time via software. Each sensor is individually calibrated so that ambient light and variations in how each sensor is mounted are accounted for.
This robot has used a PIC16F84, PIC16F627A, PIC16F877A, and now finally, and Atmel AVR ATMega8. Whenever I'm learning to use a microcontroller, I make a little board for a common part (in this case the "mega8"). This allows me to experiement with the part without having to breadboard up the power supply and clock source each and every time. FailureBot 5 uses such a board. I take the board off and use it in other projects. So, this board is relatively generic. It simply contains the ATmega8 microprocessor with an 8.000MHz crystal oscillator, a low-dropout MAX667 +5V voltage regulator, and .100" pin headers for each of the I/O pins (My board also has the AREF pin at the header but is wired back to VCC for a +5V reference voltage).
(Click to Enlarge)
The software for the robot is written in C for the Atmel AVR microcontrollers using avr-libc and the GNU gcc compiler (open-source). The software is still relatively primitive, however, it works quite well. The robot is able to handle 90 degree turns, inconsistant floor color (tiles) and intersections at a very decent speed. At this point in time, my gear motors have such a high reduction ratio that I do not need to use PWM to change the speed, however, the robot was originally designed to allow for PWM.
When turned on, the robot spins in circles on the line for a couple seconds while it calibrates the sensors. Once this calibration is complete, the robot begins it's line detection algorithm in a loop, however, the motors are disabled. By pushing a button, the motors are enabled and the robot follows the line. Pushing this button again disables the motors again. So, the robot is always performing the line following, however, it only moves when the motor enable button is activated.
During the calibration, the robot turns in place in circles above the line in an attempt to "learn" the lighting conditions of the environment. 2 values are setup for each sensor. A low value indicating the lowest value read from that sensor and one for the highest value for that sensor. At the end of the calibration, the middle of these two values is the "trip point" for the sensor. Anything above this trip point is considered high and anything below is considered low. Each LED is calibrated many times over, one at a time, as follows:
Turn on LED.
Then, a trip point is setup as low value + ((high value - low value) / 2).
There are 6 directions defined for the robot.
The robot decides which direction to go based on the 5 sensors. Each sensor is read one at a time and the bit value is stored in a variable. The bits are left shifted into the variable starting with the left sensor. Therefore, the leftmost sensor is the most significant bit in the variable. Based on the final result of all 5 sensors being left-shifted into the variable, the robot decides how to steer.
|Total comments: 8|