Dancing with Dogs

6.270 can be fun, if you avoid a number of pitfalls. If you're thinking of taking the class, try to learn from our mistakes. I learned a number of things in the course of working on the robot. Sensors can be terribly unreliable: always test them as an independent unit before integrating them into a bigger part of the robot, glue them in place to save yourself the grief of errors caused by shifting tape. Be aware that accuracy can vary wildly depending on your setup. For color reading, the angle of the sensor(phototransistor) relative to the LED can be extremely finicky. Scaling up the distance from the object being read also causes problems. When dtecting the color of a ball, develop some way of having your robot reliably hold the ball at some fixed distance from the sensor. If this is not done the darkest reading for a white ball may be indistinguishable from a green ball for example. If you're using IR sensors, it's not as important, but shielding is a good thing (TM).Simple is best; having built everything from a synchro-drive to a 4-wheel drive and everything in between, I say this from painful experience. Choose an idea for functionality and then implement it in the simplest and most reliable way possible. This means if your task is simply to drive straight and pick up a ball, you should not use a syncro-drive with shaft-encoding and some sort of grabber-claw. In this example, you'd want to try some simple drive train coupled with wall following and some sort of cage/box to grab the ball. This tidbit only applies if your goal is to achieve functionality. If you're aiming for simply a cool robot, ignore everything in this paragraph. A little more on sensors- use heat-shrink and/or hotglue on all connections, having wires short is a bad thing(TM). Use ribbon cable pretty much everywhere, copper single-stranded wire is far too brittle unless you're unbelievably careful. Back to simplicity: again, if you're aiming for something a robot that will place well, it's probably best to design incrementally- have a fully working system after every build. Achieve the goal the simplest way possible, make it reliable, then refine and embellish to your heart's content.

We went through several iterations of robot design and attendant strategy, we settled on a robot that would line follow up between the balls on its side and then try to use color detection to grab the appropriate balls. Grabbing was made possible by a set of cage like appendages actuated by servos. The implementation was very rough and really couldn't make any sort of corrections. It tried once to grab balls, if it missed it was screwed. The idea was that it didn't really matter too much if the main robot only got one ball because the mini robots would completely mess up the opposing robot by scurrying to the far opposite corners of the table. Hopefully they would run into the other robot or its balls or both. The main robot actually sat still after the start light for 3 seconds while the little robots did their thing, and then it started driving up the table. It would drive until it hit a wall, try to grab some balls and then drive back until it was on the middle plateau.

We made it through the qualifying round with a loss and subsequently got our second and final loss in the first round of real competition. Short and sweet or something like that. It was in some way sad to think that we had spent that much time on something that didn't really even achieve minimal function, but by that point I was too tired to care. Just kidding, losing quickly was annoying, but it seemed to be the popular thing to do; this year's competition was dominated by the double loss.

[*] This stylesheet was blatantly ripped from gentoo the file manager(not the distro). My thanks and apologies to the author.