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 :)

Firefox 3

I'm trying out Firefox 3 on my laptop running Ubuntu 7.10. It's a huge improvement over Firefox 2 because of three things: it's very fast, it integrates much better with the rest of the desktop in terms of UI, and it has full-page zoom.

The speed improvement is really noticeable. Opening a new tab is absolutely instant. Javascript benchmarks show it to be 10 times faster than Internet Explorer 7 (this particular benchmark was featured on Slashdot).

Firefox 3 uses Cairo/GTK2 for rendering all its page elements on Linux. (On Windows and Mac it uses the appropriate toolkits as well.) This means that it looks like any other Gnome application on my computer, and though that may seem like a small thing, it actually benefits the experience tremendously.

Full-page zoom, a feature I've always wanted in Firefox, is finally implemented in the browser. (It was implemented in various extensions for Firefox 2 but they did a pretty bad job.) Full-page zoom is where instead of the just the text size increasing, the images and the layout scale as well. It's worth noting that IE7 and Opera already have this feature.

To install it on Ubuntu Gutsy, I installed the package firefox-3.0. Unfortunately, there is one important flaw in how the Ubuntu people built the Firefox 3 package: it's not built against a version of Cairo that supports detection of the system subpixel font rendering settings. This means that the fonts have ugly color bands around their edges. In theory I could build my own copy of Firefox 3 from source with the --with-system-cairo flag, which would fix the problem, but after a few hours of reading bug reports and forums I found out that Firefox 3 requires at least libcairo version 1.5.2. The Ubuntu Gutsy repositories only include version before that. Turns out the only repository that has the correct version of Cairo is the Ubuntu Hardy repository, which means that I have to upgrade to Hardy, which is still in development, to get the correct Cairo library to be able to build Firefox 3.

I briefly considered upgrading to Hardy but decided it wasn't worth it. But Firefox 3 is good enough that I'm not giving it up just because of that font rendering problem. I'll survive with the poor rendering until Hardy officially comes out in April.

Update 1 minute after I finished writing this: Screw caution. I'm upgrading now.

Update 2008-02-28: The upgrade failed because of package dependencies (something to do with update-manager-core) and I tried to roll back but that messed up a lot of the install. So I'll just make a new partition and install Hardy directly. It's only at alpha 5, but I can manage a little instability. Also, I'm going to use the 64-bit version, so for the first time I'll get to use a 64-bit OS on my computer. Interesting how what started as an innocent attempt to try a new browser ended up in me upgrading my OS entirely... :)

Virtualizing Windows XP with QEMU and KVM

For Robotics, to program the robot, we use Microchip's MPLAB IDE with the MPLAB C18 compiler. Unfortunately, those two only run on Windows. So to use them if your primary OS is Linux, there are three choices: boot to Windows, use the WINE compatibility layer, or virtualize a full Windows installation from within Linux.

My first choice was to use WINE. Unfortunately, WINE is pretty slow, annoying to use, and unreliable (the MPLAB IDE install failed for me). So I booted to Windows Vista and installed the tools there. They installed after a little fiddling with compatibility options, but booting to Vista every time I want to make a change is a pain, especially considering how slow Vista is to boot.

So my last option was to virtualize Windows (here's a tutorial if you're interested). Luckily, my laptop's CPU supports hardware virtualization extensions (it's an Intel Core 2 Duo T7200) so full virtualization should be pretty fast—around 80% of native performance. I installed the Ubuntu qemu and kvm packages. Qemu is a basic open-source emulator that can run any x86 OS. It usually runs pretty slowly, at around 10% of native. KVM is the Linux kernel module that takes advantage of the CPU's virtualization extensions to speed things up significantly.

Once those two packages were installed, I modprobe'd the kvm and kvm_intel modules and created a 3-gigabyte disk image. I installed Windows XP onto it (we have 3 or 4 copies of XP lying around, and since we either replaced those installations with Ubuntu or Vista, the copies are available for me to use). I backed up the fresh image onto an external drive and installed Office XP (same thing as above, we have a few licenses) and the MPLAB tools onto the image.

So now I have a nice virtualized session of Windows XP up that boots in around 15 seconds and is almost as fast as the real thing. Here's a screenshot of the robot code building (successfully!) under the virtual machine:

Open Source as an IB Extended Essay topic

I just came back home from the IB Extended Essay presentation, and the one thing that struck me was how many people presented on the history of their country of origin. I'd estimate that three-fourths of the candidates wrote their EE on history and one-fourth on a literary topic. Probably several discussed an art-related topic, only one person (as far as I know) wrote the EE on technology (ITGS), and nobody did anything on physics or math.

Do English and history really interest so many people, or did they choose it mainly for safety in numbers? (Or because O'Byrne discouraged people from doing anything but those subjects?) I searched online for people who had chosen the sciences: math, physics or ITGS (which, since the course focuses on society so much, doesn't seem like a science at first, but at least it's grounded in computer science).

Searching with Google for "ib extended essay math" returns two promising results. The first is an IB EE topic discussion thread. Posts 43 and 44 (search the page for "#43") discuss math as an EE topic. One of the students was going to use game theory as a topic but "my supervisor told me that i couldnt expect the examiner to know anything at all about game theory." So clearly we're very limited by the readers' knowledge—game theory is not an obscure branch of mathematics by any means, so if we do math we'll probably have to either stick to the basics or explain all the more advanced concepts in painstaking detail.

The second good result was someone who had published their math/physics paper on juggling online. The paper seems pretty interesting (I only skimmed it) and the author makes moderate use of equations around the end of the paper, contrary to my expectation that the paper would be almost completely prose. Of course, the paper didn't necessarily get a good score, but at least something like this has been done and the evidence is there for us to see.

Finally, I searched around for a topic more in my area of computer science. During the presentations, I was thinking about some topics I could use in the technology area. For example, I liked the idea of doing something about how the open-source development model has influenced corporate software development, or the growing role of open-source software in society (yes, that's vague, but these are only ideas from off the top of my head). So I searched for "ib extended essay itgs open source" and I got only one relevant result: a (seemingly) official IB ITGS document that, on page 113, gave a sample prompt ("intended for guidance only"): "How Open Source software has led to improved corporate networking." To clarify, corporate networking is intended in the sense of "LinkedIn," and not in the sense of "enterprise networking with Cisco."

So I rephrased the query to "ib extended essay itgs +linux," for which I got a great result: a paper about Free-Libre Open Source Software and its future in K-12 education. This paper is really in-depth and well-researched; it even includes surveys of school sysadmins from around the world.

Anyway, I wanted to be sure that not doing an English or history paper for the IB Extended Essay was viable and proven, and it seems like it's does have some precedent. Although even if there was no precedent, I would probably still do something on ITGS, since I just can't bring myself to be passionate about history, and at best I can only be somewhat enthusiastic about English.