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
2 comments:
Hey, man, we got medals. That's cool.
I agree with you on all the problems, especially the programming (which Hugo told me about). At least we learned stuff!
Agreed. You all know how I feel about that mentor.
I think it should also be added that mentors will MENTOR, and not treat kids that go against their wishes as if they were hogging the robot... or calling the programmer stupid because he can't understand a single part of that crappy, useless code.
Post a Comment