Spiky Wall of Terror

Team 56, Dan Roth & Terri Yu

The Robot

Our robot consisted of the following parts: 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.