The Whole 6.270 Story by Snively '11

In mid-December a friend of mine, Jared ’10, asked if I’d be interested in being on a team with him for a LEGO robot competition during IAP. It would be him, me, and Dan ’11. “Sure, why not?” I replied, and one $50 registration fee later I was enrolled in 6.270 for IAP.

The official description of the class is:

6.270 is a hands-on, learn-by-doing class open only to MIT students, in which participants design and build a robot that will play in a competition at the end of January. The goal for the students is to design a machine that will be able to navigate its way around the playing surface, recognize other opponents, and manipulate game objects. Unlike the machines in Introduction to Design (formerly 2.70, now 2.007), 6.270 robots are totally autonomous, so once a round begins, there is no human intervention (in 2.007 the machines are controlled with joysticks).

The goal of 6.270 is to teach students about robotic design by giving them the hardware, software, and information they need to design, build, and debug their own robot. The subject includes concepts and applications that are related to various MIT classes (e.g. 6.001, 6.002, 6.004, and 2.007), though there are no formal prerequisites for 6.270. We’ve found that people can learn everything they need to know by working with each other, being introduced to some material in class, and mostly, by hacking on their robots.

The students work in teams of two or three. Each team is given the same kit containing various sensors, electronic components, batteries, motors, and LEGO. The kits are handed out in the beginning of January and they have three weeks in which to transform the parts into a working robot.

It started off fast. I was unable to attend the first lecture because of a conflict with my physics class but Dan and Jared attended, were told the rules of the contest, and came home with a big box of LEGOs. $1500 worth of LEGOs to be precise. I don’t know how much you know about LEGOs, but when you’re given as many LEGOs as we were, it’s completely overwhelming and insane. We had bags full of different pieces laying all over the floor, pieces we’d never even seen before. The scene looked something like this:

Our first assignment was to build the “Car of Awesome.” It was a pdf file containing a LEGO car that we could use as an example for our gear train and chassis. This was the most useful tool, by far, of the entire month. General consensus is that without the Car of Awesome we would have been completely sunk. In honor of said car, we decided that our team name should be “Team Awesome.” Simple, yet just awesome enough to be awesome.

In addition to being completely overwhelmed by LEGOs we were also given the rules for the competition. After it was explained to me I was a little stunned. I looked at my team and all I could say was “That’s really hard!” and all they could say was an exasperated “Yeah!” The playing table would look like this:

There are two starting corners and then three slots along each wall. The slots are painted black so the robot can see them. Next to each slot is a bin to collect balls. Each robot is responsible for different bins, depending on where it starts. Each slot/bin pair is assigned a number between 1 and 4. Here’s a schematic to clear things up:

Ignore the skunk ball for now. As you can see, robot A is in charge of scoring in the middle bin on the side nearest to him and in the nearest/farthest bins on the opposite wall. The same is true for robot B. Each robot can start with 6 balls in it, meaning they can score a maximum of 24 points (all balls in the 4 bin). How many points is the robot supposed to score though? That number is determined before each round. A number between 15 and 24 is picked and you have 1 minute to calibrate your robot. The robot then has one minute to drive around, deposit the correct number of balls in each slot, and try to score closer to the number than the opposing robot. The closest to the number wins. The skunk ball is a penalty ball. If your robot can capture the skunk and then take it back to your opponent’s starting area then they receive 4 penalty points.

Complicated enough? Meh, manageable. Hard enough? Yes.

We played around with a ton of strategies, everything from line following, gyroscopes, cutting across the middle of the field, a rotating turret, going for the skunk, flipping the opponent over, dropping pieces to confuse the other robot, and countless other strategies. I mean, we’re MIT students, we try to find as many work-arounds to the rules as possible. One thing we did decide on was to keep the robot simple and to have a rotating turret that dispensed balls over the slot and into the bin rather than into the slot. I set to work on building the chassis and gear train while Dan and Jared worked on the turret.

Work on these continued for over a week and a half. Refining, tweaking, reinforcing (you could punch our robot and drop it onto the table and it wouldn’t break at all). Eventually we had a basic little robot with a turret that could release one ball at a time. This is when we had our breakthrough. Jared came up with a strategy that was absolutely brilliantly simple, if not a bit cheap, but perfectly legal. Instead of our robot trying to score the given number of points, we planned on having it drive straight forward, deposit all the balls in the two bin, and then drive backwards to block the opponent’s 4 slot. The opponent wouldn’t be able to put any balls into its 4 slot, meaning in order to even tie it would have to dump all of its balls in its own two slot. All of the possible numbers, 15-24, required at least 3 balls in the 4 slot, meaning unless their robot dumped all of its balls in the 2 slot (which it probably wouldn’t be programmed to do) we would win.

Realizing all of this was a very happy day for us. We changed our method of ball deployment from one by one to all at once, cut the rotating turret, and starting working on programming. This is when it started getting rough.

Now that we had a strategy it was time to start integrating the non-LEGO elements, mainly the sensors. This was one of my roughest days. Try to imagine breathing lead for 9 hours. I had to solder all of our components together and I decided to get it all done in one day. It was a loooooong day, believe me. At the end of it we had 3 motors, 3 distance sensors, 3 dark/light photo transistors, and 4 bump sensors. Lightheaded maybe yes?

6.270 was abruptly interrupted by Mystery Hunt, cutting down on the amount of time we had by three days. My pistol tournament the next weekend also took me away from our robot, until all of a sudden it was Monday, the robot was due on Wednesday, and it didn’t work. This is when things started to get really rough. We essentially lived in lab for the next several days. Jared and I headed to lab at 7 pm to begin work. A lot of things happened. Some were good. They were quickly countered by things that were VERY VERY bad. I’d go into detail but some of the details are still a little to painful to recount. Here’s the gist of what happened:

• Our break-beam sensors, that we used to drive straight, worked for a while and then just stopped. After messing around with them and re-soldering our board we managed to get one to work.
• Our gyroscope, our new strategy for driving straight, started to drift the instant we turned it on.
• After fixing the gyroscope the gear train on the right side began to skip. This caused the robot to drive straight, um, never.
• Our dark/light photo transistor failed.
• Our caster broke.

By now it’s 3 in the morning. Jared was tired and went back to the dorm but I stayed a while longer. I fixed the photo-transistor and wrote some orientation code but was having a hard time being productive since I’d been awake for almost 24 hours. What’s one to do? I curled up into a ball under my workbench in lab and fell asleep for a couple of hours. When I woke up I had no motivation to try and figure out what was wrong with the right gear train so I stumbled for a while, sending sporadic and desperate text messages to Dan and Jared to relieve me. At 12:30 I was finally relieved and went back to the dorm to sleep. I took a nap, went to pistol, and at 7 I headed back to lab. I got there and was hoping that somehow, miraculously, everything was done. It wasn’t. In fact, spirits were pretty low and almost nothing had been done. This was the low of the entire process. Two days left, a robot that didn’t work, and no clue how to fix it. We worked through the night on repairing the gear train and fixing the gyro.

Our gear train began at a gear ratio of 75:1 which was ideal. In order to get rid of the skipping we had to re-route some gears, accidentally making the gear ratio 225:1. The robot just quivered when it tried to move forward. To compensate for this we added more gears in order to bring the ratio back down to 75:1. Now, when you look at our robot, it looks as if somebody vomited gears into it, but it works, so we’re not complaining.

To this day I’m still not quite sure how we did it, but by some miracle of coding we managed to get our gyro (which drifts 5 degrees) accurate to within .1 degrees. That made it a very useful tool. By three in the morning we were far from done, but we thought we had most of the big stuff fixed. Dan and I planned on getting some sleep, returning at 10 am on Wednesday, and then finishing everything up on Wednesday. Before we left we wanted to make sure we had the code necessary for completing one of the 8 possible orientations.

We decided to make a video log of a lot of our failures. The last clip in this movie is at 3 am Wednesday morning, 14 hours before the robot was due.

Jared stayed in lab while Dan and I slept, but when I woke up at 9 am to get ready I saw the following e-mail in my inbox:

Hey,
So I am having problems with calibrating the robot. The main issue is that the gyroscope fails too often to be used alone in this manner. I think this problem can be solved by using a bump sensor, but am having issues installing it. The idea is similar to the physical bump that moves the robot back in line, but much much much more reliable. As is, the robot simply runs into a wall and is not able to correct. The gyroscope has to be absolutely perfect, and this perfection is nearly impossible to achieve, and not all that reliable when achieved.

Another alternative is to use motor current as a defacto bump sensor, but this is very difficult. Even though we were able to get the gyro to work alone for one case, in the long run it will be much more efficient and practical to
implement a system in which wall following acts as a check to the gyro. Right now I am too tired to get much done, so I will go get some sleep. Good luck
guys.

Wonderful, the robot doesn’t work and it’s due in 14 hours. Dan and I showed up in lab to find a sleep-deprived Jared doing busy-work on the robot and not looking very productive at all. We relieved him and took over. This is when we buckled down and settled in for the final grind. We messed with the gyro, break-beam sensors, and orientation. Eventually things started to come together. The robot started doing what we wanted it to, and with 2 hours until it was due we were making real progress.

We ended up finishing our robot on time and getting it turned in at the deadline, which is more than what most teams could say. We spent that night doing very little, taking a break until the competition the next day.

Before the main competition on Thursday we had a seeding round. Each robot competed twice and was then placed into the bracket for the competition based on how well it performed. Our robot won both times so it was seeded very high.

That night was the competition. Our team, Team Awesome, decided to be a little goofy/awesome and bring an R2D2 to the competition. Dan also decided to dress like a pirate. The competition was very fun, and we ended up getting 3rd place overall! Out of 30 teams at an MIT robot competition, I’m happy with 3rd! I’d describe the different matches we were in, but there’s no need because due to my 1337h4x0|P skilz I have managed to pull the live webcast from the internet, convert the file format, edit it, and post each of our matches to YouTube. For those of you with dial-up, the video you’ll want to really watch is Round 4, so don’t bother loading any of them but that one for starters.

Without further delay, I bring you the adventures of Team Awesome in the 2008 MIT 6.270 competition:

Round 1:

Round 2:

Round 3:

Round 4:

Round 5:

Round 6:

Both losses were fairly disappointing, but what loss isn’t? In the end, after treating ourselves to some ice cream afterwards, we decided that 6.270 was a really cool experience and that it was all worth it. The sleep deprivation, the anger, and the lack of personal hygiene for 3 days was rough, but in the end it all paid off. We won 2 webcams and a keyboard for coming in third and we’re thinking of installing one of the webcams into R2D2 and streaming it somewhere. I’ll let you know how that goes. Hope you enjoyed!

-:-