Our strategy was simple: we intended to get to the middle of mass ave as quickly as possible, release two arms so that we would be able to pull all the four professor back to our side of campus for a total of 12 points. This was the same strategy that King Louie used to win. If we'd been able to pull that off consistantly, we'd have been all set! Unfortuantly we failed to anticipate just how reliable the real world can be, as our gear train jammed up, shaft encoders died, and our motors ejected 8-toothed gears.

We had intended to get to the center of the board as quickly as possible, to gain control of the professors before the opponent robot. Our final design used a combination of differental drive (2 motors per gear train, with a 15:1 ratio) and tricycle steering. Orignally, we had planned to use four motors driving each side of the robot, but we had to cut down to two a side when we switched to the HandyBoard controller. In the end, these two motors were definately fast enough.

We spent a while improving the efficiency of our gear train. After being plagued by tremendous amounts of friction, we realised that we had used spacing that wasn't quite an integral number of lrus. Once this problem was solved, we got more than adequate performance at 15:1. One worry was that we wouldn't be able to climb the staircase in the center of the board. At high speeds, we would be able to make it up, but going over the steps at a sufficient speed causing the robot to deviate from a straight path.

We orientated ourselves using four light sensors mounted on the mast. The principle was that the light sensor orientated towards the light would have the lowest resistance and thus the lowest of the four readings. In practice, this worked very well. However, during competition in 26-100 we incorrectly determined our orientation twice. A more robust approach would have been to sample the values in each possible orientation during callibration, and use a nearest neighbour method to identify an unknown orientated.

Both drive trains had a shaft encoder on the axel connected to the output. These counts were used to gauge rotations and distance travelled. When travalling straight, we used a simple (and seeming quite stable) control system. Each side of the robot could be run at high speed or low speed. If the difference between the counts by the two shaft encoders pased a certain threshold, the lagging side would be driven at full power and the leading side would be drive at lower power. This was quite succesful.

We used stored energy in elastic bands to extend our arms from the folded in position that kept them within the 1' foot, to the fully extended position with a total span of around 30". We attached the elastic bands such that they would all be under tension when the arms were folded up. Thus, a lego plate attached to a servo could retain the arms until we passed the professors.

In the final analysis, we did not carry out enough testing to ensure that the robot was able to consistently align itself when on the game board. Our high speed compounded our steering inaccuracies, and our forward weight distribution created problems stopping. Thus, although our basic strategy was sound, we were unable to perform reliability. Our advice to future teams? Test, test, test.