Course 6 Girlfriend

Team 30:
Anjali Verghese (Sophomore)
Goutam Reddy (Junior)
Steve Zoepf (Senior)

    
 

Brief Description:

Course 6 girlfriend was our entry into the annual 6.270 design competition at MIT.  Each team builds a robot over the course of the month of Janunary, and at the end of the month, all the robots compete in tournament-battle-style competition.  While the obvious object is to attempt to win the competition, we decided to take a slightly different route.  Since it became obvious rather early in the month that the robots that would win would simply be variations on a theme of pushcarts, we decided to build something different, regardless of outcome during competition.

Main Features:

Our robot's main design theme was a tripod-type driving system, with each wheel powered by two motors at a 25:1 ratio and controlled by a single servo per wheel.  The contest mandates that the robots fit within a 12 inch cube, and our robot was designed to barely fit within these dimensions-- each leg of the tripod is around 7 inches long.

In contrast to last year's competition, each team this year used a HandyBoard to control their robot.  The board could control a maximum of 6 motors (only 4 at variable speed), and approximately 32 digital and analog sensors.  Our robot used 13 sensors (3 CDS-type light-sensitive resistors and one distance sensor per wheel pod, and one CDS cell to detect the start light.

Since our robot design was not really dependent on a strategy, we weren't sure exactly how to approach competition.  Our robot could move balls by sprinning, pushing, etc...We just needed to figure out what to go with.  We eventually decided on pushing balls, since it is relatively easy to control, and fairly straightforward.  Since the robot is perfectly symmetrical, we could push balls with any side of the robot, thus making turns fast and orientation easy.

Most importantly, the robot is incredibly manvueverable-- since each wheel can be driving in any direction at any point in time, the robot can theoretically travel, rotate, or pivot in any direction all at the same time (altough it proved to be extremely difficult to control).  The basic driving abilities that we were able to implement were driving forwards or backwards while steering any one wheel (like a conventional car, but with any of the three wheels in front), spinning in place, pivoting about any one wheel and "bouncing", wherein the robot follows a line by putting one wheel on the line, pivoting about that wheel until the next wheel hits, etc.

Competition:

Since our robot was not designed specifically to fare well in the competition, we had relatively low expectations from the start.  Furthermore, as the day of competition approached, we encountered more and more problems with electronics.  We had at least half a dozen faulty light/distance sensors, and in addition, the night before impounding, our HandyBoard controller crapped out, leaving us with only half the analog sensor ports, partial motor control, and no LCD display so we had no easy way to debug problems.  We finally received a replacement board about one hour before the robots were required to be turned in, and miraculously, we coded a robot in less than an hour that could qualify and meet all contest requirements.

In our first round of competition, our robot's calibration code was incomplete, and it thus navigated poorly and failed to score a point, resulting in our first loss.  In the second day of competition, we failed to properly connect the batteries of our robot, and thus failed to start, resulting in our second and final loss.  We did, however, manage to write some code to demonstrate several of the more interesting driving abilities of the robot and showed the robot again between rounds of final competition.  Here is a link to the code for the competition (written in IC, a simplified version of C specific to the HandyBoard controller).

Words of Wisdom:

To all future contestants (in 6.270 or anything of this ilk):  We learned that it is more important to settle on a design early and take the time to perfect it than it is to labor over different designs.  We rejected at least 8 or 10 ideas before settling on our final strategy, and several ideas we thought to be impossible were successfully implemented by other contestants.  We thus realized that had we committed to one of those ideas, we probably could have brought them to fruition as well as other teams eventually did.  When it came down to it, we had a great design, and although we spent hundreds of hours (including several 30-hour-plus stretches), we ran out of time and couldn't complete our strategy, or even demonstrate our robot to the best of our ability, at the time of the contest.

However, 6.270 is a great course-- not only as a design exercise, but a learning experience about teamwork, resource allocation, time managements, and about generating innovative solutions off-the-cuff.  MIT students: If you are interested in competing, by all means enter (the course is lotteried, but has no pre-requisites, so anyone can enter), but be prepared to commit incredible amounts of time, especially toward the end of the month of January.

web page by Steve Zoepf, MIT c/o 2001, 2/2/01