Early on, we decided that a simple design would be the most realistic. As a result, our robot, Lego My Eggo (aka "Eggo"), was not mechanically complicated. Our intent was to capture as many "eggs" as possible in the 60 second time limit. Several teams employed a blocking strategy in which their robots would score one, or at most two balls, and then proceed to block their opponent's trough. Other's scored 2 balls and then attacked the opposing robot. We hoped that Eggo would be more reliable than these blocking and attacking robots. Nonetheless, we realized that if Eggo were to go up against a blocking or attack robot that performed properly, there was a high probability that we would get a double win, or even a loss. In attempt to avoid a loss to a blocking robot which scored only one ball before blocking up the opponent's trough, Eggo always immediately scored the #1 Ball in the diagram below. Next, it would turn around 180°, grab the #2 Ball and deposit it in the trough. The robot would then return to the top of the board and perform a routine to get the last 4 balls on its side of the board depending upon the block placement. It determined where the block was by using its distance sensors. We made no attempt to actively use the #4 Ball, which belonged to the opponent, or to grab and deposit our ball that was on the other side of the board. Integral to our over all strategy was precision and accuracy in drive routines. Therefore we choose to use PID control and back into walls for alignment rather than line following or wall following.
This is a diagram of the game board taken from the 6.270 webpage and modified.
Gear Ratio and Chassis Design:
After experimenting with several different gear ratios we settled on 81 to
1. We used two motors to drive each wheel. Valuing accuracy over
speed, this seemed like a good decision at the time. We then designed the
smallest chassis that we could around this gear ratio. We attached a
servo-positioned caster wheel to our basic frame in the rear of the robot.
We stuffed our two primary wheels with putty epoxy which can be purchased at
the hardware store and is normally used for plumbing. The putty epoxy
prevented the tires from compressed when the weight of the robot was placed
on them.
Motor Mounting:
The motors used in 6.270 are not readily compatible with Legos. The
motors come with a metal spur gear on their output shafts which does not
mesh with Lego gears. In addition, one must find a way to mount the
body of the motor to Lego so that the output shaft of the motor is
positioned correctly to mesh with standard Lego spacing. In our
original design we "Lego-ized" our motors by epoxying them between
several layers of Lego. The final assembly, (beginning at the bottom) was as
follows:
1 - 2x4 Lego plate
2 - 1x2, (or 2x2), pieces of smooth (nub-less) Lego plate
1 - motor
2 - 1x2 pieces of thin Lego base plate (custom cut from large piece of base plate handed out with 6.270 kit)
1 - 2x4 Lego plate
Epoxy was placed on both the top and the bottom of the motors. This arrangement worked excellently, but the rigidity it provided turned out to be unnecessary. The course notes suggest using double-sided foam tape and this happens to work just as well.
Once the motors could be mounted on standard Lego pieces, it was necessary to transfer power from the output shaft of the motor to the robot's gear train. In our first attempt, we removed the default metal spur gears from the motor output shafts using a vice. Just put the gear in a vice and clamp down. The metal is weak enough that the gear with soon crack and fall off nicely without damaging the motor. Now, to interface the bare output shaft to Lego we drilled out the center of very short Lego axels so they fit snuggly when pressed onto the motor shafts. Just to be safe, we also superglued the modified Lego axels to the output shafts. After all this work, the motors meshed nicely with our gear train when we placed 8-tooth Lego spur gears on the modified Lego axels.
Unfortunately, the story does not end there. Before the preliminary round we discovered that after a lot of use the custom Lego axels were coming loose from the motor output shafts. After attempting to re-superglue the axels several times we gave up. We ended up having to buy all new motors. This time we used a soldering iron to melt away the keys in the center of several 8-tooth Lego gears and press-fit and epoxied these directly on to the metal spur gears which came attached to the motors. (If you choose to use this method, use a hammer to lightly tap the metal spur gears farther onto the motor shafts before mounting the Lego gears.) Be careful that the Lego gears are very straight when placed onto the metal gears. Because we were short on time, we chose not to epoxy the new motors to Lego--we used double-sided foam tape instead.
Ball Grabbing Arms:
We next designed two servo-driven arms. We wanted it to be able to easily
open up its arms wide in order to plow a multitude of balls or close its
arms tightly to minimize its turning radius. Each arm was driven by its own
servo so that they did not have to be opened the same amount.
Battery and Handy Board Cage:
We designed this cage so that the battery pack would rest in the center of
the robot as low as possible and the Handy Board would sit on top of it so
that we could easily view its LCD screen. Unfortunately, this meant that
when all of the wires were plugged into the Handy Board it was tricky to do
a battery change.
Reinforcement:
Since our robot was fairly small (10"x10"x7") we had a lot of
pieces with which to reinforce everything. We never had a problem with Legos
or sensors falling off during testing or competition.
Sensors:
We placed one distance sensor on either side of the caster wheel turn table
so when we were driving straight we could sense the location of the
obstacle. We also placed bump switches on the front and back of the robot to
detect walls and lips and bump switches on the arms and the sides of the
arms to detect if the robot was about to bump into an obstacle. Four CDS
cells were used to detect the robot's orientation and shaft encoders were
used to determine wheel speeds.
The code, written in Interactive C, was quite large. In fact, it filled all available RAM on the Handy Board. Because our robot relied on its ability to execute precise drive sequences and turns, a lot of time was spent on the code to control the motors. We contacted Newton Labs, the producers of Interactive C, to obtain motor control libraries which allowed 100 discrete motor speeds as opposed to seven which are default in IC. With these new libraries and the book Mobile Robots: Inspiration to Implementation by Joseph Jones and Anita Flynn, we wrote a proportional-integral control loop for our motors. In short, the controller looks at the speed at which each motor is running and compares it the speed at which the motor should be running. Based on this difference, the Handy Board directs each motor to run at an adjusted speed. This is the proportional part of the controller. The integral part arises from comparing the speeds of the two wheels to each other. The difference of their speeds is integrated and this integral is also used to adjust the speed of the motors. Our motor control software made Eggo one of the most accurate robots in the contest.
During the mock competition Eggo came in 2nd and scored 27 points in a single round, which was more than any robot scored ever scored (in the mock competition OR the real competition!). Eggo made it through the first two rounds without a loss, scoring as much or higher than any other robot in these rounds. In the end, Eggo proved itself a trustworthy robot! We tied for fourth when we were eliminated in Round 10. (This year's competition was the longest ever. It lasted 12 rounds!) By that time, Eggo was performing very unreliably--doing things it had never done before. We attributed Eggo performance to very low batteries since they hadn't been changed all day. Right before the tenth round (after our first loss in the ninth round) we decided to change the batteries, but we were very pressed for time. To change the batteries we had to unplug several wires from the Handy Board. In our rush, some of these wired were plugged back in incorrectly. In the 10th round, Eggo mis-calibrated because all of its LEDs did not go on. It therefore misjudged its orientation and drove off into a wall where it sat for the rest of the round. It was a sad ending to a robot that had performed so well previously.
Maximize for your gear ratio. 81 to 1 was a little too slow for our robot.
Attach the eight tooth gears to the spur gears with epoxy after removing some of the center material.
Stuff wheels with putty epoxy to reduce the amount the wheels compress when placed under a fully loaded robot. This reduces friction which leads to better performance.
Make sure the battery pack and handy board can be removed easily from the robot.
Ensure that your batteries are fully charged. We noticed significant degradation of Eggo performance when its batteries were low on charge.
Try and write all your code on a laptop because it makes debugging much faster. If you have a laptop, you don't have to run back and forth between the contest board and the Athena machines every time you want to change one number in your code.
Us:
The 2002 *pika* team:
Rikky Muller: Course 6-1 '03 rikky@mit.edu
Kyle Gilpin: '05 kwgilpin@mit.edu
Johanna Mathieu: Course 13 '04 jmathieu@mit.edu
We took a "generalist" approach to this class rather than trying to divide up the parts of the project. It worked very well because it gave us all a better idea about how to engineer a complete system. Go Eggo!
...AND THANKS TO RUSSELL FOR LETTING US USE HIS ROOM AS A WORKSPACE FOR IAP!