Team 57
The Angry Dragon
We began our project by deciding on a strategy. Early on we had decided that
victory by placing a ball on the plateau was a possible win, but because of the
table configuration, would always loose to a robot that could successfully place
a ball in the cup at the bottom of the table. Therefore we decided on a cup win
strategy.
Our task then was to design a robot that could reliably place a ball in the cup
at the bottom of the table. Initially, this seemed rather difficult because it involved
raising the ball two inches from the ground. The balls were large, although not very
heavy, which made this difficult to do with legos. Eventually we decided on a robot
that was essentially a large cavern with a ball ramp in the middle. By propelling the
ball from the front of the robot to the back, the ball would rise about two inches.
In order to first capture the ball, we designed a pair of large spinning rubber wheels on
a moveable arm at the front of the robot that could grip a ball and draw it up a shallow
ramp to a holding area in the middle of the robot. There, a color sensor would determine
the color of the ball, and if it was the wrong color, it would be ejected out the back
of the robot by an ejector mechanism. The ramp leading to the back of the robot was
comprised of two parallel rails, and the ejector arm between them. The ball balanced
on the rails and was pushed from below by an arm on a servo motor.
By the time we finished all this, the robot was too long. We designed a system to hold
the wheel arms vertically and a motor to kick them down after it started. The arm was
quite heavy, and to keep its inertia from destroying the mountings when it fell, we
designed a shock absorber to slow its descent but not inhibit its operation. The shock
absorber is the large appendiage on the top of the robot in the photos.
Navigation was another key consideration. We chose to rely entirely on shaft encoding.
Since our robot used practically all the legos in the kit, it was very heavy and would
not slip. Therefore, by integrating the ticks on each shaft encoder, we could predict
exactly where we were at all times. We discovered early on that the six hole shaft
encoders did not provide the resolution we needed, and we designed a 24-tooth shaft
encoder using a gear. This performed quite well.
Our robot by this time was quite heavy, and had so much inertia that it tended to coast
for quite a while after the motors were shut off. Initially, we added circuitry that
would, given a signal from the handy board, close relays that would short out the drive
motors and provide enough drag to keep the robot from coasting too far. However, the
organizers vetoed our designs and we had to settle with software controls. Therefore
we designed code that, during the initialization period before a match, would calculate
the coasting distance and figure this into all the drive commands we gave it. Since
the coasting distance was a function of battery charge and table surface, it had to be
done every time before a match. It calculated distances by using color sensors on the
bottom to determine (if it had been aligned correctly before initialization) exactly when
it made 180 degrees in turning, which it could then divide down to make perfect turns of
all degree.
Furthermore, we added a few sensors to help the robot. A start sensor, a ball color
sensor, two bump sensors on the back (to detect when we hit the bottom wall when going
downhill), and a "ball in transit" sensor were added. On the bottom, a bank of three
color sensors were added to detect floor colors.
By the time we finished the software, the robot could navigate perfectly. In qualifying
trials, the robot made perfect turns, and drove perfectly straight. It captured a ball
on its first try and stopped on the plateau. (we had not finished the code at this
point).
However, disaster struck in the actual competition. Though we had absolutely no warning
during any of the trials, at least one of the bottom color sensors (that had been
completely shielded by the robot's bulk) was blinded by the intense television camera
lights in 26-100. Thus, in our first round our robot could not decide which side of the
table it was on and stood still. We won, because our opponent didn't activate his beacon.
In our second round, the robot failed to calibrate its turns properly (because it depended
on being able to see the floor color to decide how far it had turned) and the robot
ran straight without turning and gripped its opponent with its ball grabbing wheels,
ending in a double loss. Here is a link to our code