6.270                              CHICKEN

Team 27

Lego MY Eggo


Strategy:

    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.

Design:

 

 

 

 

 

Software:

    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.   

Results:

    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.  

Advice:

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!