robot side view


We decided to implement a canon mechanism to dispense ping pong balls into the center of the playground. The canon uses two wheels spinning in the opposite direction, with one of them geared to spin five times faster than the other. We had an encoder on the axles of one of the gears so that our program knew how fast the wheels were spinning, and we used a PID controller to keep the wheels at the speed we wanted. We calibrated the cannon so that it knew how fast to spin the wheels given the distance it wanted the ping pong balls to travel. After pulling the lever, the balls were funneled into a small holding area. It was then fed into the canon by use of an arm attached to a servo that pushed the balls one-by-one into the spinning wheels.

robot back view

We also implemented a standard lever that spans the length of the robot to help mine for balls. This mechanism proved to be the most challenging part on the programming side, because alignment for the lever was at an angle such that the robot could mine and dispense ping pong balls simultaneously. It would have been nice if we had a mechanical stop so that the robot would not have to decide by VPS coordinates where to park to pull the lever. Some other teams implemented this, which seemed to be a successful idea. However, it was not a viable option for us because we were already too close to the size limit.

Initially we had a small robot for the first mock competition of driving to points so that we could test our navigation code. Because it was built quickly without much thought about how our robot would function, we rebuilt our entire robot after this mock competition. We were unsure near the beginning if we were going to use the ball cannon or if we were simply going to carry and deposit the ping pong balls. Therefore, the new chassis was designed to be large so that it could hold many ping pong balls at once; this turned out to be useful once we actually decided to implement the canon idea because the cannon required a lot of space. A design decision we made was to place the larger wheels near the center of the robot for more accurate turning. We also decided to have lego blocks around the outside of the wheels not only so that the wheels would be more protected, but also so the chassis would not sag in the middle. The chassis was more or less symmetric in the beginning, but we had to modify the chassis multiple times as the competition progressed, partly to fit within the size limitations. For example, the chassis had two castor wheels for support initially, which was modified to just one castor wheel in the front. We later put the second castor wheel back in so the robot would not tip over backwards. In the end, the castor wheels ended up nearer the center of the robot than was originally intended because of size. One of our regrets after building the chassis was that its width in the middle was half a block's width shy of being able to fit the happyboard; we ended up mounting it vertically on the side of the robot. There were unfortunately many moderately sized cavities in the robot that were just a little too small to fit the batteries.


During one of our last practice rounds before impound, another team's robot rammed into ours. The resulting effect jammed the axle of the lower wheel of the canon, rendering it unable to spin. This collision damage burned out the motor that geared the canon's wheels. We spent hours debugging the problem until Scott, one of the organizers, identified the issue just three hours before the competition.

Because of this serious mechanical problem we were unable to do last minute alterations in the code. This may have affected our overall performance. Despite all the problems we encountered, our robot performed well and scored.