Spiky Wall of Terror
Team 56, Dan Roth & Terri Yu
The Robot
Our robot consisted of the following parts:
-
Stationary, heavy base (about 12"x12")
-
Hinged unfolding arm (about 3')
-
Lever to trigger arm
We named our robot "Spiky Wall of Terror" because it has axles attached
to the arm to increase the effective height of the wall. For fun, we even
mounted LEGO heads onto the axles, like skewered heads.
Strategy
The first week, we brainstormed different ideas. We tried building a drive
mechanism for a fast, maneuverable robot and a LEGO catapult to throw balls
over the opponent robot. After much discussion and experimentation, we
decided to implement the simplest idea: a stationary robot having a giant
arm with a twofold purpose – sweeping platform balls to score and blocking
the opponent. The arm would fold up into smaller segments and there would
be a triggering mechanism to deploy the arm across the table. This design
would require less programming and would be more consistent than a moving
robot. We were betting on the fact that the mobile robots would have trouble
finding and picking up the balls.
Construction
We started by building a prototype arm, which was quite massive, yet
it was meant to be free standing, with support only on the base side.
We had planned to counter weight it with a battery pack, maybe two.
Our original base designs used two turn tables and two servos in order
to get full 360 degrees of motion. After working together for a week,
we mutually realized that it was easier and more efficient for us to work
on different aspects of the design. Dan, the more mechanically apt, developed
the robot structure while Terri played with the electronics and programming.
At the end of two and a half weeks, we ran into major difficulty.
The arm proved too difficult to move, even with the power of two servos,
and it sagged a great deal. Also, there were not enough LEGOs in
the kit to build a strong arm long enough to reach across the table and
block the opponent. Secondly, the servos in the base did not have the strength
to rotate a three foot long arm. With the contest imminently approaching,
we scrambled to find a solution. To compensate for the lack of mechanical
power, we placed a motorized wheel at the end of the arm. Although we still
had to scrap much of our robot and rebuild it, this innovation saved our
design. We also changed the design of the base. By using only
one turn table and three servos, we could feed the cabling up through the
center of the base, and thus avoid entanglements. The other difficulty
was how to deploy our large, bulky arm. Because the robot was constrained
to a 12"x12"x12" cubic volume at the start of each contest round, the arm
had to be folded up. At three o'clock in the morning, we hit upon the idea
of using a special hinge, which would keep some of the segments of the
arm parallel while it was being unfurled onto the playing field. In the
final designs, the servos were used to orient the arm, and the wheel at
the end of the arm powered its movement for the rest of the match. To deploy
the arm, we built a gear box onto the base side of the arm which powered
a lever. The lever pushed the arm out which then extended itself
due to its own momentum. From here on out, there were small problems, but
they were easily conquered by applying good old engineering principles:
build, test, and debug.
Code
Our code was simple. First, orient with IR, deploy the arm, and begin sweeping
the balls off the platform. To orient, the IR beacon samples the four detectors
(north, south, east, west) over 0.1 seconds and averages the values. The
detector with the lowest average is assumed to be the detector facing the
opponent robot's IR beacon. Then the folded arm is swiveled to the correct
orientation by the three servos in the base. The triggering lever is lowered
and pushes the arm out. Immediately, the arm sweeps the first ball off
the platform by running the motor on the arm. It sweeps from a hardcoded
lower potentiometer value to a higher potentiometer value, specified for
the robot's orientation (N,S,W,E). If the arm gets stuck on something,
it will "thrash" by randomly moving clockwise or counterclockwise for 0.1
seconds and try sweeping the platform again. After sweeping, the arm returns
to its original position and "holds position". If it is disturbed, there
is feedback, so the arm will force itself back to the original position.
Twenty seconds into the round, the arm resets itself back to the lower
sweeping position (if it was moved since the first sweep). It waits for
five seconds and sweeps to the upper position. If it gets stuck before
reaching the upper potentiometer value, the arm will back up and ram the
obstacle three times. After sweeping, the arm goes back to the lower sweeping
position and holds position. The same procedure as for the second sweep
occurs for the third sweep.
These files contain the code we downloaded into the robot:
Between Round 2 and 3 of the contest, we changed our orientation code (for
reasons discussed in the competition section), so we slightly modified
our robot behavior code and created a new file called
robot_stuff2.c
Competition
During actual competition, our robot, "The Spiky Wall of Terror", reached
Round 4 out of 9, finishing in the upper half. Unfortunately, because we
did not debug our robot sufficiently, "Spiky" once failed to orient its
arm correctly. We speculated that this was because the opponent robot's
IR beacon did not transmit fast enough for us to register a signal. To
correct this problem, the organizers allowed us to change our code so that
our robot waits for a signal before collecting IR signal data and orienting.
In another instance, during deployment, the robot arm became stuck in another
stationary robot's wall. This situation could have been avoided if we had
planned our design more carefully and consider cases where the arm did
not fully extend. When the robot did work properly, it was very consistent
and swept the balls off the platform in a clean, consistent fashion. Overall,
the robot met our expectations although it was disappointing to lose a
match because we could not IR orient.
Lessons
From our participation in 6.270, we learned many engineering lessons. First
of all, a good design and testing is essential. If we had begun testing
our robot earlier, we would have discovered its problems sooner. We spent
too much time working on the mechanics of our robot, rebuilding it three
or four times. Having a well-though out design and extensive testing can
save a great deal of time. Moreover, we learned how to work as a team.
For some tasks, we split up for efficiency's sake. In the last few days,
we debugged the robot's controller board code together. Not only did we
catch each other's errors, but by arguing about how to best implement a
robot behavior, we came up with better programming solutions. Finally,
we learned how to endure three weeks of grueling 10+ hour working days.
We encouraged each other and took long breaks over the weekend. Overall,
the 6.270 competition was the ultimate engineering project and an incredibly
valuable learning experience.
Return to the 6.270 webpage.