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




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



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