My Mama

How to Win 6.270

There is a simple way to do exceptionally well in 6.270. Start early and work aggressively. You don't have to put in crazy hours to have a great robot. You just have to concentrate solely on the work that is most critical at any given time. Don't work on anything except things absolutely necessary to get the robot working on the table. Test your robot on the table all the time. Things never go as you think they will, so the only way to have a reliable robot is to test it time after time to make sure it performs consistently. If you can get your robot to consistently get carry our your strategy one week before the mock contest, then you have a sure ticket to the finals, and an excellent chance of winning.
Parting Shots

"Be careful whose advice you buy, but be kind to those who supply it. Advice is a form of nostalgia. Dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts, and recycling it for more than it's worth."

For every question you have in 6.270, there are two ways of finding the correct answer. There's the easy way, which is to ask a whole bunch of TA's and trust the consensus (90% of them are uber-clueful). Otherwise, you'll eventually find out the hard way, which generally happens if you didn't ask enough TA's to render the unclueful responses statistically insignificant. Here is a list of the Truths that we found out along the way:

If you're after speed and power, use three motors per wheel, at a gear ratio of 45:1 or lower (we settled on 25:1). Some TA's will tell you that the gain of going from two to three motors is hardly worth it. They're wrong. Mouser's right.
This we learned the hard way. (Well, we could have listened to James from the beginning, but we didn't.) The legolized motors have mounts of double-stick tape and have some freedom to wiggle, which makes your geartrain annoyingly huge and unhappily noisy over the course of handling and testing, so you might as well go with non-legolized motors. To build an awesome geartrain you've got to keep it simple (use as few gears as possible), unquestionably fix your motors in their positions with hot glue, and use proper spacing. To check for proper spacing, before mounting your motors you should spin your geartrain with your finger. If it doesn't whirrrr and go on spinning for at least a couple of seconds on its own, fix your spacings again. Once your motors are mounted, check for proper spacing by backdriving (roll the wheels by hand and make sure the geartrain moves smoothly). While your robot runs, check for proper spacing by listening to how noisy it is. It shouldn't be. Many teams never grasp just how quiet a good geartrain should be. It should *hum*, so don't settle for anything less. If it sounds like a chainsaw, you've got problems.
When wiring sensors, finish one and test it first, before wiring additional ones of the same type. Also test each your sensors prior to mounting them. Both of these tips came to us by way of Paul, after we'd fried two breakbeam sensor packages because their resistors had been, um, forgotten (perhaps attributable to sleep-deprivation).
The distance sensors actually work. If they aren't working, it's a mounting problem. The mounting of your distance sensors has to be perfect. Other than your geartrain, this is the one other time in 6.270 when you must be 100% anal-retentive. Do not waste time on some kind of software fix. Thanks to Benji, we were able to get dead-on readings in the end; we had settled for some seriously sketchy readings before...
Do not implement multithreading, it will only make your processor feel wimpy. You'd do much better if you code the simplest and most efficient implementation possible from the get-go.
If your handy board has died a horrible death, try to find Yonah, "an organizer from back in the day." He revived ours by somehow figuring out that we'd fried our LCD and a hexinverter, among other things. Don't ask how we managed to pull that off.
If your servos twitch and spasm, it's probably because you have more than one distance sensor plugged in, which results in power glitch issues unless you wire a .1 uF capacitor across power and ground on each distance sensor. But of course, Yonah figured this out for us too.
If your IR beacon is malfunctioning, for the most part the TA's can't tell you much about the IR beacon, so go to Jan. Jan knows everything and he's also a truly nice guy. When it came down to crunch time and our IR beacon still didn't work, he built us a new one right before Round I.
Oh yeah, label your equipment. Of course it's an obvious thing to do, but we didn't, and ended up buying new pliers and wire-cutters because other people narfed ours.
One last thing. Should a TA-who-will-remain-unnamed insists that he's sure he's giving you a phototransistor, even though its pins are different from those on the ones you've already got, don't waste time trying to figure out the pinout yourself. If the pinout is a mystery, something is seriously wrong. Back away slowly from that TA and go to Jan. In this exciting episode, Jan found that our mysterious "sensor" was in reality a friggin' infrared light-emitting diode.

Home | Design | Pictures | Strategy | Results | Advice | 6.270