6.270 IAP 2007

team 4

team name: 3 blind mice


tiff, wendi, helen



our robot

results of the competition

seeding/qualification round

the work leading up to the competition

our team

our robot: paul




our robot was named after our mutual friend, paul, who from time to time gave us moral support and helped us with our project.

moving the robot across the board

we used two motors to run each wheel, which were placed on either side of the robot. two casters were placed at the left and right front corners of the robot to maintain balance. shaft encoders were used to provide feedback for making the robot go straight forward, backward, and turn multiples of 90 degrees. furthermore, the shaft encoder counts provided us a way to measure how far the robot should travel across the board.

moving balls into scoring areas

servos were used to control the gates that allowed the balls in and out of the robot. there were two sets of gates: an inner gate and outer gate. the inner gate, a one-way gate, was used to trap the two balls along the width of the board. the outer gate was then used to trap the four balls along the length of the board and release them in one of the corners of the board.
the inner servo also served to deploy the claws of our robot at the start of the competition round.

our strategy



The game works as follows: the robots start out in corners R and B, and squares X, Y, Z are territories that the robots fight over. A team secures a territory by putting more of their balls in compared to the opponent, and the team with more territory wins the game. Therefore, only two territories are needed to win a game. How should we make sure we win two territories? Well, our robot Paul had two ball gates. The inner gate trapped the balls and never let them out, while the outer gate trapped the balls but it could be opened for release as well. When the game starts, Paul orientates himself, and goes for the 2 balls first. He "eats" them, and then backs to the starting corner, turns 90 degrees, and then goes for the 4 balls, puts them into the territory ahead, backs up a little, turns and drives straight into the middle square with the 2 balls he ate at the beginning of the game. Then he sits in the middle square until the end of the game.

the outer ball gate was eliminated (see the issue with the ball gates ) after seeding/qualification.

back to top of page


results of the competition


we were in the top 22 out of 46 teams. we won our first two rounds but lost our last two rounds. in all 4 rounds, our robot did not once complete our strategy, but we were fortunate enough that our strategy encompassed backup plans in case our robot malfunctioned. in the first two rounds, while trying to enclose the two balls with out gate, we also pushed one of our balls into the corner scoring area. for the first loss, our left motor got stuck in the middle of trying to place our 4 balls into the scoring area. for the second loss, while trying to orient itself, the robot hit the wall in an area of the robot that was not accounted for by our bump sensor, so for the entire round, the robot just stayed in the starting corner -- stuck.

all in all, the electronic and software components of the robot were solid. however, the mechanical aspects of the robot were unpredictable and caused many of our unexpected problems during the competition.

back to top of page


seeding/qualification round


unfortunately, we were eliminated in the first round in the seeding/qualification round. our claws failed to deploy, and although our robot moved across the board the way we wanted it to, we were unable to trap the balls within our robot and release them in the appropriate scoring areas.

see our performance here.

back to top of page


the work leading up to the competition


the issue with printf

when our shaft encoders failed to provide appropriate feedback for the robot to go straight, we tried to see if the motors were drawing different amounts of current, which would affect the efficiency of our feedback mechanism. when we found that the current was approximately the same for all four motors, we then tried to use the printf command in C to display the current that was being passed through the motors on the LCD display. for some reason, one of the motors would always display that there was no current passing through. to resolve this problem, we took apart the gearbox and took out the motors from the motor box, plugging it into multimeters to measure current. we were puzzled, confounded, or rather, just downright confused. resorting to the TA, we then found that there was a bug in printf, which would print out incorrect values. as it turns out, it was a typo in the code that generated the problem, but we did not find out because we assumed it was a hardware problem since the current displayed was always 0.


the issue with the laptop

3 days before the seeding/qualification rounds, helen, one of our software engineers, accidentally spilled water on her laptop. fortunately, after one day of air-drying the computer, she was able to turn on and use her laptop the next day. unfortunately, the next day, her computer refused to turn on. fortunately, we had backed up all of our code on tiff's flash drive before her computer started to malfunction. this meant, however, that our productivity for coding dropped, since only tiff's computer was being cooperative and was able to download code onto the controller for testing.

see our productivity drop exponentially here.


the issue with the batteries

a week before the competition, our robot suddenly stopped going straight. we checked the shaft encoders, took apart the motors, and examined the gear box -- all to no avail. we spent numerous hours trying to fix the bug, until one of our team members came up with the brilliant idea of checking the batteries, since we had reprogrammed the controller in an effort to figure out what was wrong with our robot. after using the multimeter, we found that instead of the fully charged 8.5 volts, the battery was only at a dismally low 6.5 volts. after charging the battery for a few hours, we regained functionality of the robot.


the issue with the castor

hours before the qualifying/seeding round, our robot refused to go straight. having experienced this problem before, we automatically assumed that the batteries were low. however, the battery level was at a whopping 8.1 volts. nearly panicking, we double and triple checked the gears, shaft encoders, motors, and lego pieces. when our friend paul came to visit us in lab, he pointed out that our left front castor was unable to turn the full 360 degrees that we needed it to in order for the robot to go straight.


the issue with the ball gates

because the green and red balls used in the competition were of slightly different sizes, after the seeding/qualification rounds, we realized that we had to change the design of the ball gates so that the gates encaptured both types of balls equally well. we found that sometimes the green balls, which were smaller, would slide under our robot and interfere with the gears and shaft encoders. to resolve this, we had to move the inner ball gate outwards and get rid of the outer ball gate entirely.


back to top of page

our team


wendi li
wendili [at] mit.edu
mit, class of '08
course 6-1, EE
robot design, soldering

helen liang
heliang [at] mit.edu
mit, class of '08
course 6-1, EE
robot design, soldering, software design

tiffany chen
chent [at] mit.edu
mit, class of '08
course 6-2, EECS
software design, soldering
back to top of page

last updated 02/02/07