Here are the original concept sketches:

Okay, so I was lying. Our actual original concept sketches, as well as all other materials and thoughts pertaining to the design of 6.270 2000 Robot #41, have been classified by the U.S. military pending analysis. And that's the truth.

The Strategy

Our strategy was to very quickly plow the opponent's row of blocks with our robot, then return to our side of the table. Next, we would "snarf" our blocks, storing the hackers inside the robot while dropping the students. We would then return to our opponent's side of the board and plow his jail to remove any blocks he had placed there to score points. Finally, we would go to our side of the board, plow our own jail to remove any professors or students placed there by the opposing robot, or the opposing robot itself (if attempting a jail break), and then deposit our stored hacker blocks in our jail. This would yield a maximum of 24 points, while defending against many other strategies.

After a couple weeks, this strategy was revised by removing the initial block attack. We revised our strategy because it seemed like many robots weren't going for their row of blocks, but rather just going after the two blocks that were always known to be hackers and then speeding to the other side to mess with the opponent's blocks. This implied that our messing with the opposing robot's blocks would often be irrelevant, and that we would be wasting precious time in which we could be snarfing. Also, the initial strategy was redundant in that we plowed the opponent's jail at the end as well as plowing his blocks at the beginning of the round, and the final plowing was effective against the robots that only moved the two known hacker blocks.

The Fatal Idea

While sitting half-asleep in one of the lectures for the course, Seth had the "bright" idea of using a mouse as an additional sensor (we are allowed to spend up to $20 on additional sensors for our robot) to track the contest table. The advantage of using a mouse is that even if we were knocked by the other robot we would always know our orientation because the mouse ball is independent of the drive train and doesn't have to swivel, unlike shaft encoders or freewheel shaft encoders, respectively. Seth thought two mice were needed, but Chris came up with a clever way of using one axis of the mouse for angular information and the other for distance information that would work for navigation (albeit not if we were bumped), and we decided to go with this. We thus embarked an a very risky, very complicated, and ultimately doomed voyage of discovery into the flaws of the RoboSkiff controller board, culminating in a final push wherein we each got 5 hours of sleep in the last 60 hours of the contest and failed miserably. So let this be a lesson to you: never trust a 6.270 TA. This was one of those ideas that is great in theory but fails in practice. However, the tragedy of our robot was: if the board had worked as promised, our idea would have worked. We had wonderful driving and sorting hardware that worked perfectly, but no way to tell our robot where to go. If you have any questions about how to implement the mouse idea (we did it) or why it failed, email Chris.

The Incarnation of the Strategy in Hardware

Within the first few days after receiving our kit, Chris built an interesting two-conveyor-belt snarfing mechanism that lifted the blocks off the table and worked fairly well. We decided to use this idea of transporting blocks with conveyor belts, and mount the snarfing and sorting system on top of a chassis with one end built as a sturdy plow. Thusly, by driving sometimes forwards and sometimes backwards we could take advantage of having two specialized ends of our robot. We would store the blocks on a conveyor belt, nestled against a door, and then remove the door when we wanted to deposit the blocks on the table.

We then designed a system of "sweepers" that widened the effective mouth of the snarfer. The sweepers were conveyor belts mounted on both sides of the mouth (which was in the center) perpendicular to the table so that if a block ran against a sweeper it was propelled towards the mouth. Once in the mouth, the top conveyor belt rolled over the top of the block and pressed it against the bottom conveyor belt. The two conveyor belts then lifted the block off the table to a horizontal conveyor belt that ran the length of the robot, and had a door at its rear end. The sorting of the blocks was done by a servo with a "fork" attached to it. The servo was mounted above the horizontal conveyor belt so that the blocks passed between the sides of the fork. At the front of the fork was an optical reflectance sensor that could tell the difference between the different kinds of blocks based on their reflectance, and if this sensor detected an undesirable block it would swing and kick the block off the conveyor belt to one side or another, where it would slide down a chute onto the table. If the sensor did not detect an undesirable block, the block would pass unopposed between the sides of the fork and get stored in the storage area.

We mounted the batteries vertically in a linear pack at the very back of the robot to use as a battering ram against the opponent. This also had the effect of putting a lot of weight very close to the axle, increasing traction. The batteries and axles were mounted on a strange construction of Legos that Seth designed that is effectively indestructible by man, which is why the plans for our robot have been confiscated by the Pentagon. We also planned to mount a plow in front of the batteries, but we ran out of space on our robot, so we had to leave it off. (The robots can only be 12"x12"x12" maximum.) The batteries were actually glued to a Lego "clip" which allowed easy swapping of battery packs. However, the storage conveyor belt had to go over the batteries, so we made the entire storage section hinged, and could lift it up to swap battery packs. We mounted the computer on top of the storage area.

The Incarnation of the Strategy in Software

Our plan was to have a tracking program running in its own thread that would just receive pulses from the trackball and keep track of where we were on the board, but after failing to get the direction information from the ball (we knew how to get it, we built a circuit that did it, but the RoboSkiff power supply screwed it up) we decided to use the trackball as (hopefully) a really good set of freewheel shaft encoders. However, after trying this and eventually discovering the reason why nothing worked was that the shaft encoder counters on the board were unreliable, we had about 20 minutes left to make our robot do something before the impounding deadline. So we were left no choice but to have our robot do a "random walk" where it executed simple driving commands in such a way that it wandered around the table, hopefully over some blocks. While this never succeeded in snarfing any blocks or scoring any points, we did actually manage to nudge an opponent off the table, so that made us feel better.

Now that you are familiar with how our robot works, you may want to view our poorly commented code or read our rambling journal. We would like to thank our music sponsors The Beatles, Moxy Fruvous, They Might Be Giants, Monty Python, and Tom Lehrer for making the making of this robot enjoyable. Thank you for your time.