D. P.

D.P. Logo

Team 42

During the month of January 2001, we participated in MIT's annual "Autonomous Robot Design Competition" (called "6.270" around here).

On January 8th, we were presented kits of lego, motors, sensors, and a "Handyboard" controller, as well as the rules of the contest. On February 1st, we competed (in between there were some lectures, some workshops, and a lot of independent work and learning.

D. P. (originally designated team 42 and intermediately designated . . . something else) was comprised of Josh Peters (6-2 '03), Ed Keehr (6-1 '01), and Jasper Lin (18T, 6-3 '03).

Strategy

All three of us spent the first few days determining a basic strategy, and even into the third week tweaking the strategy we decided on. We actually considered almost every strategy we saw at the competition. For some of them (like the catapult, for example) we determined that they could not be very realistically achieved. For most, however, we saw inherent drawbacks that made them easy to beat. We decided to stay simple and go with a "go into their territory and steal their balls" strategy. The strategy seemed realistic, potentially very good, and simple. Another benefit of an active strategy was that we could learn a lot more . . . it involves more robotics than something that spins in place.

We decided to not rely on the environment or add too much complexity by trying to discern the environment at all times (in others words we wanted to keep it fairly open loop). We wanted a fast, strong robot (though these two are not often both acheived). We also wanted something that would please the crowd in case we either lost quickly or made it to the last few rounds (it didn't happen much in the contest, but in practice matches D. P. physically beat the crap out of some other robots . . . nothing brings cheering quite like violence and flying lego).

Specifically, our strategy was to orient then follow the right wall to the first ball. We next used our arm to "throw" the ball across to our side (thank you Jasper . . . this was a great insight). Next we turned, oriented, then went after the second ball. At this point, we used the IR detectors and a distance sensor to see if the other other robot was blocking our exit path. If so, we went back across the board and brought the ball back to our side. If not, we simply turned and brought it back the short way. The rest of the round was simply following an L-shaped pattern gathering balls from their side and bringing them back until we ran into the other robot or the round ended. We steered into the wall slightly to follow it for fast traversal of the board and overpowered our turns a bit to smack into walls. We also backed into walls (using bump sensors for detection) to orient ourselves at times. For practical purposes, we had a large amount of "time-out and try-again" as well as some "something's wrong find out where the hell you are and fix yourself" code in there. One key element of our strategy was that we always drove across the board facing backward to prevent a solid, fast wall to anything that might try to block us (our time-out code conveniently doubled as ramming code should something try to stop us though . . . this worked very well in practice matches).

Building

We started almost immediately working on the kit, building an open-loop drivable (but not steerable) robot the first night. For the first few days, all of us toyed around with strategy ideas, tried a few things with lego, and soldered . . . a lot. Ed built another robot chassis fairly early, but the gearboxes weren't too hot. After going to the gearbox workshop, Ed and Josh built another robot chassis (somewhat similar to the final version actually). We spent some time testing the feasability of various features of our strategy with this robot, and even made it into a German Magazine. The next two nights, Ed and Josh tooled away and eventually (thanks to a crazily effective arm-mounting epiphany Ed had) cranked out (by and large) D. P. Jasper spent much of this time writing functions to test incremental parts (sensors, drive, etc.). We spent most of the rest of the time debugging and adding functionality to D. P. The week before impounding (which was Wednesday at 5pm), the team went to lab just after the Superbowl on Sunday and stayed there until impounding (67 continuous hours in lab . . . thanks to lots of Mountain Dew, Red Bull, and Spree).

The Robot

Our robot barely fit in the cubic foot size requirement with the arm up. We used a differential drive with a steering wheel in the center of the robot (controlled by a servo). The two rear wheels each had three motors for drive (fast and strong remember?). The sides of the robot had freewheels to spin easily as it followed walls. The arm is truly a work of art . . . Ed amazingly managed to very solidly mount two turntables and servos onto the robot with few pieces left (we used all of our beams of length > 2 and most of everything else). Two shorter arms gathered balls for the large arm to capture. The batteries were mounted fairly low with the Handyboard over them. Surrounding the batteries lived two symmetric 45:1 gearboxes . . . in case you're interested, simplicity, short axles, support, and correct spacing are the keys to good gearboxes. Electronically, we used 4 phototransistor / LED pairs for line detection, 1 CDS cell for start light detection, 2 rear bump sensors, 1 IR distance sensor, and the IR beacon/detectors. D. P. also sported some nifty sponsor logos (though we already mentioned them) as well as it's own artwork. Overall, the thing is fast, low, somewhat heavy, stylin', and damn solidly build (a drop test survivor :-).

Rear ViewTop ViewLeft Side ViewRight Side ViewFront ViewRear Closeup

The Handyboard is programmed in Interactive C (IC). Jasper and Josh developed the code for D. P. which resides in a few files: main.lis, main.c, mainfunctions.c, actions.c, handlers.c, orient.c, and arm.c

The Competition

Luck. That's my word of the year. They tell you on the first day that luck plays a huge role, but that doesn't do anything to take away the sting when you get a bad hand. Oh well, we still did really well. In the Mock Contest, we made a good showing, but faced Team 10 (the ultimate winners) in the second match and narrowly lost (we improved our strategy after that and subsequently beat them in a practice match). In Round 1, we lost our match due to failing to adequately shield our sensors against spotlights (we couldn't really practice with those conditions though, so it's a pretty honest mistake . . . all the other teams that went on the white side of that table in round 1 lost too). We came out very strong in Rounds 2+, solidly defeating opponent after opponent. We were one of only two teams to score a 7-0 round, and the other match involved the opponent accidentally scoring 3 points for the winner . . . in other words, we clearly had a strong, very functional robot. The only round that wasn't particularly exciting was when we ran into the other robot early on . . . it turned out they weren't broadcasting IR, so we couldn't detect them (if we hadn't beaten them anyway, they would've been disqualified for that though). Our number came up however, in the quarter-finals (or thereabouts). We faced Team 10, "Don't Worry" (who eventually won the contest). We'd faced them before in the mock contest (they won) and in practice rounds (we won), so it was somewhat nerve-wracking. Unfortunately, with our motors not providing as much juice as before, we went too slow to get past them (which was really disappointing, because we had successfully gotten away from them before). With that, we were doubly-elimanated (earning somewhere around 6th place of 60 teams) :-(.

For some more detailed pictures of D. P., or some video footage of our matches in the contest, try here.

Advice

Building D.P.Tooling the Night Away
Top Left ViewWorking on the Table
D.P. (detail)

Questions / Comments to: jpeters@mit.edu