Microsoft Seattle regional FIRST robotics competition

I just got back from the competition. Our team, Saints Robotics, didn't do so well, mainly because various components of our robot failed throughout the competition. We ended up seeding in 30th place out of 31 teams, and though the top alliance in the finals chose us to be part of their alliance (probably out of pity or impulse), our robot failed again during one of the quarter-final rounds, so we were out of the finals.

So we messed up in this year's competition. It's not that big of a deal, but what can we do next year to avoid it happening again? First let's see what went wrong.

The most important contributing factor to our failure was that we introduced unnecessary complexity. Our drivetrain, rather than using the known-good tank drive system (each side of wheels runs together) we tried to build a car-like drive system (rear wheels are powered, front wheels turn). We chose this much more complicated system in the hopes of getting more maneuverability. As far as I know we didn't have any hard evidence to back up the claim that the maneuverability justified the extra complexity. So next year we should either just use tank drive, or prototype a different system well in advance so we can really understand whether the new system is worth it.

Another problem was robustness. During most of the competition rounds, when our robot was jarred a little too hard, something would go wrong. The problems included a short in the electronics, the battery coming loose, and something bad, the details of which I never figured out, happening to the wheels. This is a hard problem to avoid, but an important countermeasure we can take is stress testing. We need to stop being so protective of the robot, getting scared if it so much as runs into a wall, and instead kick it around a bit. Run it into bricks, kick it, drop stuff on it, and so on. Also, we need to design it to be robust. The main thing we can do to that end is make sure everything is organized and planned out. One important example is the wiring. We should have a map of the electronics layout done ahead of time, with places for wires, so nothing comes loose.

Similar to the problem of too much hardware complexity, our software was too complex in similar ways. Because we had so many sensors, most of which weren't worth the complexity they introduced, we had to add lots of sensor code all over the place. Our code wasn't version controlled. This was a major problem that arose mainly because the mentor who knew how to program the sensors didn't want to use version control, instead littering the code with #ifdef's (for building for FRC or Vex) and #if 0's (for disabling code). He also didn't communicate well about what changes he was making to the code, so we were constantly confused about whether problems were caused by the software or the hardware. Next year, we will start from scratch, and I will make sure everyone on the development team understands what every part of the code does so that anyone can fix problems and no one treats the code like a magical black box. We will also only attach sensors if we are certain that their benefits will outweigh their complexity and added risk of failure. We'll keep the code under version control, and make sure to have different branches that each work around a missing sensor so we're always prepared for failures.

So we did pretty badly this year. But I'm still glad that next year at least we'll have a big list of things not to do :)

Update 2008-03-22 20:23: Well let me correct myself—we weren't second to last but rather second because the alliance that chose us finished second. Of course, we only got second because our robot died and got swapped out with a more useful one. Still, it's certainly a good feeling to be second :D


Upgrading TiVo's hard drive the second time

We've had a TiVo for three or four years. It started out as an 80-hour Series 2 model, but two years ago I replaced its 80GB hard drive with a 300GB one using the Hinsdale guide. That was plenty of space until a few months ago, when we ran into the space limit again.

So we bought a 750GB drive. I tried using the same guide to upgrade the 350GB drive to the 750GB one, but the MFS Tools CD wouldn't even boot this time. I found a newer version, MFS Live, and that at least booted. But when trying to run the command to copy the contents of the old drive onto the new one, it gave the error "Backup target not large enough." I decided just to use Linux's dd (disk dump) command to do a bit-by-bit copy of the old drive onto the new one, and from there I planned to expand the copied image using the mfsadd tool provided.

I left the disk copy running overnight, and the next morning I tried to expand the image. When that didn't work (the command said the image was already expanded), I looked around and found out that you can't expand an already-expanded image. Finally, though, I found a tool that advertises that it can: WinMFS. Unfortunately, this requires Windows, but luckily I had an install of Vista lying around on my computer. So I used the MFSSuperSize and MFSadd tools on WinMFS, and that worked, resizing the image to the full 750GB.

So now we have a TiVo with around 1000 hours of recording space. That should last a few more years :)