6.270 - IAP 2000
here's the contest site
main page
project log

team 4 - nication
group members: Chris Avrich / Albert Leija / Nick White

Final Design Report by Chris Avrich

I. Overall Summary

The basic idea of our design was to have a fairly speedy robot that could pick up most of the blocks (including those from the opponent's campus), and then come back to our campus where it was relatively safe. Once there, we could sort the blocks (Hacker or non-Hacker, Professors included), and then drop them either in our jail or out on our campus, depending on their type. The basic route we chose was to go down either the left or right side of the table to the opponent's group of ten students, turn, collect those students, then turn again and come back to our campus with the blocks. Note that this route would also collect two valuable Professor blocks along the way.

Our robot's structure was divided into several components.

1) The Sucker: This construction is angled downward at the front of the robot to bring blocks upward into the robot. We used six spinning Lego tires to grip the blocks, and mounted them on shocks so that they could flex a bit as they brought the blocks up. There is one motor attached to each side of the sucker, geared down in a 2:75 ratio.



2) The Whacker: Once blocks are drawn into the Sucker, they pass into a small chamber where they are (a) scanned with a red LED and a phototransistor to determine their type, and (b) pushed in one direction or the other using some Lego plates attached to a servo. We mounted the base plate upside-down underneath the whacker, and the whole section is tilted backward at a slight angle; this enables blocks, when hit, to slide down into storage bins in the rear.



3) The Excretor: There are small gates at the back of each storage bin that can be activated independently to release a certain type of block at a given time. We planned to program the robot to "do a little jig" when the flaps were opened, that is, to shake a bit by driving forward and backward rapidly. This would help the blocks to slide out of the bins more quickly and reliably. One thing to note about storing blocks is that it made our robot fairly large, to accommodate as many blocks as possible (in fact, we barely made the one foot cube limit).



4) The Collector: This is a plow at the front of the robot to direct blocks into the sucker while the robot drives around the board. Rubber bands are used to connect the two arms of the Collector, to provide flexibility in case of a collision with a wall or the opponent. Since our robot was quite large, we needed to have the Collector mounted vertically at the start of a round, and then have it flip down at the start. It was kept in place with a latch attached to the servo, and when the servo was rotated, this latch would release. Rubber bands were mounted so that the Collector, in the latched position, would be under tension; this way, upon release, it would spring down to the correct position.

The Collector in latched (starting) position:


The latch:


The Collector in deployed (down) position:


5) Drive wheels and gear train: This is all underneath the robot, and mounted to the base plate. We have two drive wheels, using differential drive, and there are two motors attached to each wheel at a 1:27 gear ratio.



6) Sensors: We have one touch sensor at each back corner of our robot one on each side near the wheel for wall detection. We also have two touch sensors on each arm of the Collector to detect flexing, both inward and outward. In addition, there are four orientation-sensing photoresistors attached to the IR Beacon's dowel, an LED/phototransistor pair mounted near the Whacker for block scanning, three more LED/phototransistor pairs on the bottom for line following, a photoresistor on the bottom for start light detection, and shaft encoders on the drive motors to help the robot drive straight.

Due to the time constraints of the contest, worsened by the delay in the controller boards this year, we had to scrap some of the features of our original design before impounding time. We scrapped line following, because we found that it was too inaccurate and slow to be viable; we replaced it with a dead-reckoning (for distances) and wall-following (for turns) strategy. The other big problem was with block scanning: try as we might, we just couldn't get it to work reliably enough. As time ran out before impounding, we took out the Whacker entirely and just planned to let blocks flow into our robot indiscriminately as we moved around the table. Then, we would release them all on our campus, and that theoretically could net us 10 points (6 for the two Professors, 1 for the two extra Innocents from the opponent's group of 10, and -1 for the opponent for losing those students).

II. Performance and Results

In the qualifying round, we qualified with a loss. Our robot managed to orient itself properly, start on the signal, and deploy the Collector. It then drove to the right, made a left, drove to the opponent's side of the board, made another left, and drove about two feet before stopping. Unfortunately, it sucked up one Innocent student block and moved one Professor and two Innocent students to the opponent's side of campus in this process, thus scoring points for the opponent. But we had shown the ability to score, so we qualified.

In round 2, we took another loss to eliminate us from the contest. We started and oriented properly, but we began facing left, which was an orientation that we hadn't tested as well as others. We ended up just driving and getting stuck in the corner. Also, we had the persistent problem of not shutting down properly at 60 seconds, but it didn't really matter since we'd lost anyway. In the finals, we had an exhibition match, but by then our rubber bands for deployment of the Collector had become less elastic, and our Collector deployed late, getting stuck on the outside wall of the table and disallowing our robot from further movement. However, we did manage to suck in the one corner Hacker block and beat our opponent 2-0.

I would describe our robot's overall performance as "a valiant attempt." In the qualifying round, we showed that our robot could at least drive reasonably around the table (and at a good speed, too), but problems just plagued us too much, and there was not enough time to debug them all. However, we did manage to achieve some useful functionality. The Sucker worked with a good degree of speed and reliability. The drive motors and drive trains gave us few problems, and were pretty speedy. The Collector deployed quite reliably, but we had to watch out for rubber band degradation. Also, the start light sensors worked, we were able to implement wall-following turns, and other simple parts like the Excretors worked without a hitch.

III. Possible Redesign

If we could retake 6.270 with the same design goals, I think that our strategy would be somewhat different. First of all, we would have a much greater respect for the old adage "Keep it Simple, Stupid." There was just no way we could have anticipated the amount of debugging we needed to do, and a simpler design may have saved us a lot of sleep loss and headaches.

Knowing what we know now about how hard it is to scan blocks for their type, we would not have attempted to do it. Instead, we would have probably worked with the high-scoring Professor blocks, since their starting position is always known. We could have either implemented something with arms to push the Professors on our side (a la "King Louie," the winner), or perhaps a strategy that would collect the Professors and deposit them in the opponent's jail. The key would be to focus in on one particular task, and do it well. This would allow us to debug in a much more focused and effective manner.

With our new design goal of simplicity, we would have been able to better achieve a goal that, in reality, we had to relax a bit due to the weight of our complex robot: Speed. I'd imagine that, with a new, simpler construction, we would be able to build a much smaller, more compact robot that would be able to quickly move in and score points before a slower opponent could execute its strategy. I am in no way opposed to a strategy that would cause our robot to actively come in contact with the opponent - it'd make the competition more fun to watch, and since our design would be smaller, we'd have much more leeway to make our robot very structurally sound.

Finally, I would like to comment about the two Hackers in the corners near the starting zone. I think a revised strategy would do well to incorporate these, since a robot that doesn't scan blocks is much more dependent on them. However, I think that it would be better not to waste crucial time at the beginning bringing them to jail, when instead, our robot could be bringing Professors to our side, pushing Professors in the opponent's jail, or otherwise interfering with the opponent's strategy. Speed is key, but more importantly, messing with the opponent is fun.

IV. Contest Design Flaws

The contest was fairly well constructed, in my opinion. The board was laid out well, especially the fact that the steps prevented getting all four professors in one sweep (unless you used some sort of arms). I liked the many different ways one could score, either by putting Hackers in your jail, bringing Students and Professors on your campus, or dropping Students and Professors in the opponent's jail. The point values seemed fair, and scoring based on the end state of the table was a good method.

The jail break option seemed underutilized in the competition, and I'm not sure whether this was because of individual teams' preferences, or whether it was simply a weak strategy. The same goes for the holes in the blocks - it was good to have the option of using them for block detection, but in my opinion they weren't all that useful for anything. Blocks could easily be thrown out of orientation, and a Professor could be read as a Hacker, for instance.

Finally, of course, having the control boards delayed by a week was the biggest problem this year. It's not a design problem, but it did prevent almost all groups from reaching their full potential, and made the final contest generally less exciting. The strategy of trying to detect blocks, while clearly encouraged in the design problem, simply became unusable due to the lack of debugging time. However, the choice of controller boards actually became an interesting facet of the competition.