Team 17: SMRTBot
M. Maitland Lederer
Justin Mazzola Paluska

SMRTBot and Rapid Prototyping

As we built our robot, we kept in mind the immortal words of Homer J. Simpson,

I am so smart!
I am so smart!
I am so smart!
I am so smart!
S-M-R-T!
We sang such a rousing tune because some of the obvious mistakes that we made along with way with our robot. There were moments when we would look at our code and think, "Duh, that was an obvious bug", then look at our solution and make a better one.

However, we chose to build our robot using the Rapid Prototyping method of development, so we expected to have some solutions that were really stupid, just as long as we found a final good solution near the end. Each day we would rip apart our robot and leave it in a better state than in which it started. As such, each part of our robot--except for the code--went through several revisions until we were finally happy with a part.

SMRTBot's Structure

One of our goals when building SMRTBot was to make sure that it was a modular design. This desire stemmed from both of our experiences in 6.170, where modularity and reusablility are the keys to a well-designed program. In the end, we achieved our goal and could disassemble and re-assemble our robot in several minutes.

SpaceFrame 2.0

The SpaceFrame forms the boxes in which all of the other Lego parts fit together. Originally, instead of a space frame, we had a solid Lego box. Quickly we realized that such a Lego-dense frame was a waste of Lego in addition to being a pain to work with and modify. It was time to return to the drawing board.

We laid out what our goals were for our frame:

We were able to accomplish some our goals with our first attempt at building a SpaceFrame: we even (unintentionally) dropped the robot from our box from a height of about five feet and only lost a few pieces of Lego. However, as the robot grew, it became apparent that the first SpaceFrame would not hold the front arm very well, nor hold the caster.

Keeping with our rapid prototyping model, one day, after SpaceFrame 1.0 proved itself a worthy concept, we tore the entire robot apart and rebuilt the entire frame. What we ended up with was a droppable frame (we tested at two and a half feet before getting skittish) that held our arm and rear caster.

Drive and Power

We built two mirrored steering and drive units for our robot. From the start of the project, the turntables caught our eyes as interesting Lego pieces, and we decided to use them to make a servo drive system where we could rotate powered wheels at will. The first powered turntables first had two stalks that would provide power and steering, but that was too flaky of a design. The second iteration placed the drive motor under the turntable along with a 45:1 gear box. This design was very strong, resilient, and reliable so we stuck with it. The final part of our drive system was adding a shaft-encoded sensor in the back end of our robot. This provided balance and also allowed us to calibrate turns by how far the rear wheel moved.

The system we chose was slightly complicated. However, it allowed us to do interesting maneuvers, such as "Moonwalking"--sliding-- in a direction instead of spinning and moving forward in a direction. Furthermore, we just thought that the turntable-based drive and power wheels were just interesting!

The Plow Arm

We built an arm that would theoretically plow our balls off of the trough edge and the other team's balls off the opposite edge. To this end, we decided that a set of wheels running in an opposite direction to those driving the robot placed out in front of the bot would work. Initially, these wheels were supposed to be placed at the end of a lever arm that would raise and lower to trap balls as the bot was moving, but after a while we decided that this was more complicated than it was worth. Furthermore, it was very weak, structurally. So we decided in the end that a stationary arm that rested just above the playing field would be best. This arm was built into the frame of the robot and, thus, much more structurally sound. Also, it did not require a servo, conserving our funds for other things.

Strategy

There were two main strategies in the 2002 6.270 Competition: push balls around or block the scoring holes. We chose a variation on the first, because it seemed wholly uninteresting to have a robot that just plowed a ball and sent off a blocking car. Instead, SMRTBot would try to offensively attack the opposing teams balls and move them out of the way of that team. This way, robots that were programmed to know where the balls were would be confused.

More specifically, our strategy was to:

  1. Orient toward the trough and push the ball in for a safety point
  2. Line follow to slightly past the center of the board.
  3. Turn away from the trough and plow north, knocking three of the opponents balls off the table. We would place the Annoying Blue Thing to our in the lower edge spot and program it so we always knew where it was.
  4. Line follow back to our side of the board.
  5. Plow toward the trough and push our balls into the trough. If we encounter the Annoying Blue Thing from our opponents, wall follow around it and then plow toward the trough.
The strategy, although implemented in code as an FSM, proved to be very difficult to get to work and debug. In fact, in competition our robot never made it past stage 1 in the strategy.

Contest Results

We accomplished our goal of making it to the televised round. Overall, we played three matches, two where we lost miserably, and one where we won. We were happy that in the match we won that our robot successfully moonwalked.

What we would do differently

We got all we wanted out of our robot. We enjoyed the class and our IAP and learned a great deal about engineering given limited tools and materials. There were several things that would have been wiser and led to a more successful robot. We offer these tips for future 6.270 contestants: