The Tortoise, like many other robots in the competition, was a robot which sought to slowly and accurately gather up as many balls as possible, without ever trying to attack the other robot or block its attempts at scoring. Our strategy from the very start was the "five ball strategy", meaning we aimed to score at least five balls in every game.
First, our robot would orient itself, and detect the position of the block. It would then immediately score the first ball, travelling backwards. This was done to at least double-win with the many robots who scored one and then attempted to block the opposing hole. Subsequently, the robot would move forward and gather the second ball up in its trap-device, which shall be described soon. It would then turn 90 degrees and go forward until it could turn towards the ridge, with three balls in its path. It would then turn 90 degrees again until it faced the three balls and the ridge. It would push the three balls, as well as the ball it was carrying, down over the ridge into the trough, thus scoring a total of five balls. Subsequently, if time allowed, the robot would try to get the sixth ball in.
Initially, we ambitiously also intended to score the six balls quickly, and then proceed to chase the other robot. As it turned out, scoring six balls took the full minute and sometimes more; so our robot was named the Tortoise, slow but steady. Well, perhaps not so steady...but we'll get to that later.
This strategy was initially hashed out at our first strategy session, and did not substantially change for the remainder of the competition. As the debugging went on, we noticed a possible flaw - that when the obstacle was close to the starting point, and far from the wall (front left, look from the point of view of the starting position), this strategy hit a snag. For it to work, it would be necessary for the robot to wedge itself through a very narrow alley between the obstacle and the wall before making a sharp turn to face the ridge. Fortunately, some clever coding made this tight maneuvering possible.
We set to work almost immediately on the physical construction of the robot. We used a differential drive motor system with a 45:1 gear ratio. This means that we had two wheels, each of which was controlled by a separate motor. To go forward, both wheels would go full speed ahead; to turn, one motor would go forward, and the other backwards. Two motors drove both wheels for added torque. Additionally, we had a third wheel in the rear of the robot that was controlled by a servo. This wheel would turn 90 degrees whenever the robot would turn, and provided added stability to the robot. We later found that turning the back wheel small increments could cause the robot to arc, a capability that proved useful.
In front of a robot was a trap that could hold balls. This trap was controlled by another servo, and consisted of a Lego grating that could raise and lower to trap balls behind it. Mounting this servo to be stable proved quite tricky but we were up to the task, and in the end we were able to trap balls with little trouble. We placed the batteries above the chassis, and above this was a stand where the handyboard could be placed.
The robot's construction did not go perfectly smoothly. In the beginning, the robot would have extreme difficulty moving without the motors stopping; this was improved substantially when we noticed that the gears were pressed against a bar in the gearbox. Even after this was corrected, however, the robot's motors tended to go slowly, overheat, and die. Sometimes, the robot would just start heading to the left, and be unable to straighten itself out. It turned out that stopping for a second or two after a rapid motion helped ensure that the motors would not die during the run; and boatloads of error correction were used to keep the robot going the right way as well. Indeed, by the end, our robot went relatively straight, albeit slowly.
Our robot turned out to be a renaissance robot, quite attuned with the outside world. We had a total of four light sensors, 11 bump sensors, 2 distance sensors, and 2 shaft encoders - and almost all of these turned out to be quite useful in the final product.
The four light sensors were predictably used to orient the robot at the beginning, and later, it was used to make sure that the robot was correctly on top of a line, before proceeding to go forwards. Patrick's calibration code and Brian's orientation code worked magnificently throughout the competition. Additionally, the distance sensors were able to consistently determine the position of the obstacle; we were worried at the beginning about their accuracy, but they turned out to be strikingly successful. The shaft encoders were placed around pulleys attached to the wheels, and they allowed us to go straight by counting the number of wheel revolutions on each wheel and making sure they were equal.
Finally, the bump sensors. We had 11 total:
We typically used the metal-lever sensors instead of the keyboard sensors, as they were generally more stable. All this combined to nearly fill up the inputs on our handyboard by the very end.
Most of our code was hinged around error correction. We wrote functions for simple tasks like turning and going straight which seemed simple at the beginning, but conspired to nearly completely fill up our handyboard by the end. For instance, the turn function stopped on a timeout, or any of the side or front sensors being struck. Then, a return code returned the reason it stopped, and a variable pointed to the amount it had turned. Using this, if the turn did not complete completely, the robot could adjust itself forward or backwards, depending on which side sensors were hit, and then try again. Similar activites occurred when attempting to go straight; if a side sensor was pushed, the robot would readjust itself accordingly, then keep going forward. All this error correction took up a lot of room, but given our robot's mechanical imperfections, this error correction was extremely useful. It took up much of our time and effort while coding.
The last three days before the competition were rather insane. We took shifts to ensure that we had 24 hour a day representation in lab. We debugged, tested, and added error correction to ensure the robot could act consistently.
Alas, all did not end up well. In the first round, due to table differences, our turns were substantially off; we thus crashed and lost in a double loss. In the second round, we scored one and nearly scored the other four before being blocked by a blocker; a solid double win. In the third round, frictional or lighting differences caused our robot to go too far forward on our initial movement, alas, our turns failed. Still, it was certainly an educational experience.
