results of the LEGO Robot Design Competition
Fred Martin
Several of you have asked for more information/results of the 1992 MIT
LEGO Robot Design Competition. I hope this letter will satisfy your
curiosity.
Following is a brief history of the contest and course and a
discussion of this year's results. At the end of this letter is
information on how to obtain the course's 250-page ``6.270 Robot
Builder's Guide'' and a videotaped copy of the February 3rd contest,
produced by MIT Student Cable TV.
I'm expecting stories on thie year's event in next week's Science
Magazine, the Boston Globe's Science section on Monday, February 10,
and in Byte Magazine at some point.
Cheers,
Fred Martin
MIT Media Lab
(cut here)
---------------------------------------------------------------------
The MIT LEGO Robot Design Competition
(C) 1992 Fred Martin
The MIT Robot Design Competition started as a programming competition
in 1987. Mike Parker, an EECS (Electrical Engineering and Computer
Science) undergrad at MIT, had just taken the Mech. E. course
``2.70,'' in which students build machines out of scrap metal and
plastic and enter them in a confrontational match at the end of the
term. (You may have seen the annual 2.70 contest on PBS television.)
Mike enjoyed the 2.70 class and contest so much that he was jealous:
why should there be a class like this for Mech. E. students, but not
for EECS students? So Mike organized the first ``6.270'' contest
(``6'' is the course number for the EECS department), using the public
domain C-Robots code as a robot simulator. The contest was held using
a projection television monitor as a computer pitted one student's
code against another.
The next year, 6.270 was again a simulated robot battle, this time
using a tank battle game shell (Xtank) developed at MIT by undergrad
Terry Donahue.
During this time, Mike had been working at my laboratory at the Media
Lab (I'm a grad student there), and seen a project called
``LEGO/Logo,'' which is a robotics design environment made especially
for elementary school aged kids. Using LEGO/Logo, kids can build
machines from LEGO bricks, beams, gears, and motors, and then connect
them to a computer interface, add some sensors, and write simple
control programs using the Logo programming language.
Mike thought, ``Wow, this LEGO/Logo is great stuff for kids; let's use
this for the next 6.270 contest!'' Mike recruited me and Randy
Sargent, an MIT student, to develop technology for the upcoming (1989)
6.270 contest, to be held during MIT's special one-month long winter
break (called ``Independent Activities Period'' (IAP)). This was the
ideal time for running the class.
We had neither time nor money, but we came up with a simple serial
line interface using a UART chip. One byte of data sent from a
computer turned up to four motors on and off; one byte of data being
sent back to the computer indicated the state of eight digital
sensors. It was simple, and it worked.
About twenty teams of students were enrolled that year. The class
organization was done at the last minute, so parts arrived late and
the LEGO kit contained only three wheels (students ended up gluing
rubber bands onto a large gear to make a fourth wheel). But the
students had a great time and the class was a success. The contest
itself was a ``King of the Mountain'' battle in which robots had to
climb to the top of a dome-shaped paper-mache mountain. The robot
nearest the top at the end of a 60 second round was declared the
winner.
The following year, P.K. Oberoi, an EECS undergrad and a student in
the prior class helped to organize the event. Randy and I again
worked on the technology, and designed a board around the Motorola
6811 processor. We used the 68HC811E2, a version of the chip with
2 Kbytes of internal EEPROM, 8 analog inputs, and a bunch of digital
I/O. We added a serial line converter chip, two motor control ICs
(allowing control of four motors), and connector banks for sensors
and motors.
That year's contest was ``Robo-Puck'' robotic hockey. Three robots at
a time were to compete in a circular rink, vying for control of a
hockey puck equipped with an infrared transmitter.
The contest was evolving into a course. We led classes to introduce
the students into various aspects of robotic technology: sensors,
motors, mechanics, batteries, and programming. The students had a
fairly nice kit of LEGO that year, as we had recruited more funding
from Microsoft, who had sponsored the contest the previous year, and
the EECS deparment itself. Students were immensely creative with
their mechanical designs, and many generated sophisticated strategies
for solving the contest.
Programming that year was done in 6811 assembly language. Needless to
say, developing a working program was painful. The problem of code
development was compounded by the fact that when something didn't
work, it was very difficult to know what had failed: was it a
software coding bug, or was it a hardware failure, or was a sensor
simply not performing as expected? Students had a lot of difficulty
implementing their ideas, though a few did find the experience of
writing machine code to be enlightening.
Eighty students took the course that year (we organized them into
thirty teams). he contest itself was a smash. Discover Magazine (May
1990) wrote a feature story aimed at the general audience that
conveyed the excitement, creativity, and satisfaction experienced by
the students who participated that year.
By the end of that year, I was interested in the course not only from
a technical perspective, but from a special pedagogical perspective.
Students at MIT were choosing to pull all-nighters building robots
rather than taking ski trips. In doing so, they were learning about
engineering design and robotic technologies from first-hand,
experiential involvement in a project-based course. The course seemed
to fill a gap in the students' education, providing them with a
complement to the theoretical orientation of many MIT classes.
The developing course pedagogy also had a close fit the educational
ideas of Seymour Papert, the head of the Epistemology and Learning
Research group at the Media Lab, with whom I was working. In years of
research with children, Papert developed an educational philosophy
called ``constructionism.'' According to constructionism, learning and
the acquisition of knowledge are active processes engaged in by the
learner; e.g., knowledge is constructed by the learner. According to
a constructionist, this process can be greatly facilitated when the
learner is building something real in the world, in addition to
building knowledge inside his or her own head---just as were the 6.270
students.
The 1990 class was a big success, but it was hampered by the
controller board that had to be programmed in assembly language and
only had a small amount of memory. Afterward, Randy and I began work
on a robotic technology that would be more powerful and more useful to
6.270 students, allowing them to get even deeper into robot design and
other technological issues.
By the time of the 1991 class, we had developed robot-building kit
with the high degree the power and flexibility we had wanted.
We wrote an C compiler with an interactive front end. The compiler
gives the user a command line from which he or she can type C
statements and expressions which are dynamically compiled, downloaded,
and evaluated. The run-time module also allows multi-tasking of up to
a dozen C processes.
The new embedded controller board had numerous features, including 32K
of battery-backed RAM, an expansion board for circuit prototyping, and
a 16-character LCD screen that could be used to print debugging
messages. Students were able to use MIT Athena workstations (the
campus Unix machine network) to develop programs for their robots.
We had also put a lot of thinking into how to organize the class to
maximize the students' learning potential. We scheduled the class
activities so that students would have all the pieces of a robot---the
controller board, motors, sensors, and programming---functioning as
early as possible into the course. Even though they would not have an
integrated robot until later in the course, they would have all the
pieces ready at hand. At this point, students would be able to take
charge of their project, and enjoy themselves as they saw their robot
become more and more functional.
The 1991 contest had 150 students organized into 50 teams. About 45
teams had a robot ready for ``Robo-Pong,'' the contest that year.
Robots had to get ping-pong balls from their side of a table to the
other robot's side. The table was doubly-sloped, so that balls would
roll from one side to the other once they crossed the mid-way point
of the table.
1992 saw little change in the technology. The board set was revised,
fixing some bugs and introducing others. But the contest was made
much more challenging.
The contest specification for ``Robo-Cup'' robotic soccer pitted two
robots into a one-on-one competition. The contest is played on a
rectangular playing field (about seven feet by four feet in size),
with corners lopped off slightly (giving the overall field an
octagonal shape).
There are soccer-style goals at the far ends of the playing field.
Each robot must attempt to score balls into its respective goal. The
goals are one foot wide and eight inches high, and are horizontally
divided into an upper area and a lower area. Balls scored into the
upper area are worth three points; balls scored into the lower area
are worth two.
There are two ball dispensers that drop balls at a height of 15 inches
off of the play surface. Robots receive balls by pressing a touch
bumper near the ball drop for the each ball dispenser. A robot may
obtain a ball from either dispenser, but the dispensers will only
yield one ball per five seconds.
Markings on the surface of the table provide a curved path for the
robots to follow from each ball dispenser to a corresponding goal.
The goals emit polarized light, at a +45 degree or -45 degree angle
of polarization, so sensors can be used to find the direction toward
a goal.
The ``Robo-Cup'' contest was much harder to solve than last year's
``Robo-Pong.'' In Robo-Pong, all a robot had to do to win against a
non-functioning opponent was to drive uphill: it was nearly assured of
pushing a ball over to the opponent's side of the table and thereby
winning the contest.
This year, a robot had to successfully (1) find its ball dispenser;
(2) dispense and catch a ball; (3) deliver that ball to its goal
(typically, either by shooting or by carrying and dumping).
Only ten out of forty robots were able to complete the task at the
first round of the contest. Contest rules dictated that robots must
be able to beat a ``placebo''---a null opponent---to qualify for the
second night of the contest. Students had about twenty-four hours of
work after the first round to get their robots to work to qualify for
the Monday night final contest.
Thirty robots qualified for the final round. The caliber of the
robots was higher than in past years because the contest factored out
random wins---a robot that qualified was generally capable of
performing the task will some degree of reliability.
However, nearly all of the robots were coded with ``open-loop''
strategies---strategies that would not let them recover from
unexpected circumstances. These strategies consisted of running a
sequence of actions or tight feedback loops with little or no
possibility for re-calibrating if any action failed.
In interviews conducted near the end of the course (but before the
final few days of serious coding and debugging), several teams had
expressed intent to attack the opponent at the start of the round, but
did not have time to implement these strategies as their had to first
become functional enough to score goals.
Only one team did managed to implement an attack strategy. It was a
ball shooter that attempted to block the opponent's goal after
shooting (and, presumably, scoring, a few goals). Unfortunately, the
robot did not succeed in fully blocking the goal, and lost when an
opponent scored a full load of balls around the robot.
This year's contest was the most exciting to date. Nearly all of the
robots entered were capable of winning a round, and many of the
rounds were cliff-hangers that pitched a ``conservative'' design
(i.e, a robot that shuttled single balls from the dispenser to the
goals) against a ``cavalier'' design (i.e., a robot that collected
several balls before carrying them to the goal). There were also
quite a few shooters, which generally were less reliable than the
ball carriers, but sometime performed flawlessly.
The final rounds had eliminated the less reliable designs, leaving
seven ball carriers and one shooter. In narrowing down to the final
four, the shooter lost, and quite competitive carriers were
eliminated by others that were just a bit faster and equally reliable.
In the final four elimination, one robot lost once while three others
drew. A round robin was held for the final three. One robot
slipped, and dumped its balls into the 2-point goal rather than the
three. The next round was won by one goal, leaving a first place
winner and a tie for second and third place.
The winners were:
FIRST PLACE.
``Dizzy Devil'' by Marcus Kramer, Sumer Johal, and Chris Ward (all
freshmen).
This design was an incredibly fast single-ball carrier. It could
make a round trip from the dispenser to the goal in less than five
seconds, with perfect reliability.
SECOND PLACE
``Earl'' by Stephen Chamberlin, Lenny Granowetter, and Matthew Olsen
(all sophomores).
This design made two trips to the goal, carrying three balls the
first run and five the next. It had a simple walled bed with a gate
to release the balls into the goal.
SECOND PLACE
``The Vibrator'' by Jeff Marshall (frosh), Moe Hendawi, Erhhung Yuan,
and Malay Kundu (sophomores).
This ball collector dispensed eight balls and then made a run for the
goal, following along the wall. Its moniker refers to the method the
designers used to make sure all the balls rolled out of the ball bin:
a motor with an off-center mount was turned on the vibrate the whole
machine and expedite the effect of gravity, drawing the balls out of
the bin.
FOURTH PLACE
``Tetazoo III'' by David Harris and Srikar Srinath (sophomores).
This collector also made two runs to the goal. It had a ball ejecting
gate that would only free one ball at a time. The designers caused
the machine's drive motors to run forward and backward, shaking a
ball into the gate, before releasing each ball.
The winners each received an additional kit of LEGO Technics parts,
donated by LEGO Systems Inc, a contest sponsor.
----------------------------------------------------------------------
For more information about the 6.270 contest:
(1) OBTAINING A COPY OF THE 6.270 ROBOT BUILDER'S GUIDE.
The Robot Builder's Guide is the course ``bible,'' explaining all of
the technology used in the course, theory of robot control and
programming, designing with LEGO Technics parts, where to find
robotics parts, etc, etc.
The manual was written by me, and I hold its copyright. Individuals
may obtain the manual without charge electronically, or (soon) a
printed version at the reproduction cost. The manual may not be
reproduced without permission of the author, *except* by non-profit
organizations for educational use only. No parts may be included in
other publications without written consent of the author.
To obtain the manual electronically, you will need:
(1) access to a PostScript printer;
(2) FTP or e-mail capability;
(3) Unix de-compress utility.
The manual is available via anonymous FTP to "kame.media.mit.edu".
Go to the "pub/fredm" directory and get the README file. The manual
is broken up into separate PostScript files for each of the chapters;
these files are stored in compressed form (using Unix compress).
(By the way: if you do download from our FTP server, please drop me
a note. I'd be interested to hear any comments from people looking
at the manual. Thanks.)
If you don't have FTP access, I can mail you the manual in uuencoded
form (ugh, it's about 2 Mbyte before uuencoding). Send me e-mail at
"fr...@media.mit.edu".
If you are totally lost with the techno-jargon at this point, I
should probably provide you with a hard copy. My research group
will be distributing copies via its memo publication series.
I will send another message to this group when hard-copies are
officially available. Please hold off on the hard-copy requests
until then. If you don't hear from me in a month, pester me and it
will help.
(2) STATUS OF THE 6.270 TECHNOLOGY.
We have produced some rather cool stuff, including a single-board
computer optimized for control of a small mobile robot, and a
multi-tasking C compiler with an interactive front end that runs on
just about any computer (including Macs, PCs, and Unix machines).
Presently I am in the midst of conversations with both the MIT
Electrical Engineering and Computer Science department and the MIT
Media Laboratory that hopefully will lead to rights to disseminate the
technology. MIT will have the final say, as they own part of the
rights to the technology!
One possibility is to put the stuff into the public domain; interested
parties would then be free to print up their own boards and use the
software. Another possibility is that the technology would be
licensed to a start-up company that would package and try to sell
stuffed board sets and the compiler.
I'd be interested to hear people's opinions on how they think this
kind of technology is best distributed. My biggest concern about
making the stuff public domain would be customer support issues if
there isn't a profit incentive involved. For example, how many people
would actually bother to use the stuff if no one promised to be
responsible to help them get their boards debugged?
(3) VIDEOTAPE COPIES OF THE 1992 6.270 CONTEST
Alan Blount, student director of MIT Student Cable TV, is distributing
copies of the contest on VHS videotape. The cost is $15 postpaid
within the United States. Contact Alan directly
(blo...@media.mit.edu) for pricing outside the U.S. Make your check
payable to Alan Blount and send it to:
Alan Blount
E15-344
20 Ames St.
Cambridge, MA 02139
That's it for now! Please feel free to contact me if you have any
questions, suggestions, problems, etc.
- Fred Martin
--
Fred Martin | fr...@media-lab.media.mit.edu | (617) 253-7143
MIT Media Lab | Epistemology and Learning Group | Cambridge, MA 02139