Introduction
Mechanics
Electronics
Software
Conclusions
|
EE/CS118 Final Project 2002
Introduction
Team members showing the coach the various points where the robot was assaulted.
From left to right: Aren Sandersen (coach), Adit Koolwal, Eehern Wong, Arun Kishan, Darren Lewis.
The EE/CS118 Winter Project for 2002 was an open-ended project to design and build a basketball playing robot.
Here is a link to the actual project description. Briefly, the task at hand was to construct a robot that could shoot 1.75 inch diameter nerf balls into each of three different milk crates, evenly spaced along the back of one of end of the field. Mounted above each crate were infrared beacons that transmitted light at a frequency of 1.1 kHz. Our robot was to detect which crate's beacons were transmitting light (only one crate's beacons could transmit light at a time) and shoot a nerf ball into that crate. The goal was to make as many baskets as possible in 2 minutes.
As early as our initial brainstorming sessions, we decided that our driving motivation should be to keep
the robot's design and implementation as simple as possible. The main areas that we decided to simplify
were the following:
Depend as little on analog sensors as possible.
From experience in analog electronics classes, we knew that it was very difficult to get
multiple sensors to behave in exactly the same way. Therefore, we knew that depending on
relative rather than absolute values would greatly simplify our design.
Drive the robot as little as possible.
From our experience with the cockroach lab
earlier in the quarter, we knew that our motors might not give us the performance we
desired. We also heard many stories about motors burning out and bearings failing
on the day of the competition. Keeping these points in mind, we figured that the best
design for our robot would be to rely on movement of internal parts rather than the
the whole robot. We also felt that this would increase the speed of our shooting,
because moving a small portion of the robot would take much less time than moving
the entire heavy bot.
Tailor the robot directly to the playing field.
Since we were provided with the complete specifications of the playing field and
competition, generalizing the robot's design and functionality for other purposes
would be a waste of time. We felt that we could optimize our design specificially
for the problem at hand. For example, it was easier to calibrate our shooting from
just one point on the field rather than designing the logic to account for shooting
from multiple locations.
Design the robot to only shoot three-pointers
Since the field is not too large, we figured that designing for three-pointers would
only be marginally more difficult than free throws or twos. We also wanted to score
as many points as possible.
Keep the software as short and simple as possible.
Some team members created very complex state machines for their cockroach designs
earlier in the quarter, but were dismayed at the resulting behavior - the cockroaches
did not seem to behave any more intelligently than simpler designs. From this knowledge
we decided that having as few states as possible in our state machine would simplify
both the functioning of the robot and the actual design of the code. We knew that we
could always add states as needed, but it turned out that our original design was
almost robust enough without modification.
With these general design choices in mind, we constructed our robot, "The Assaulted", as described in the remaining sections of this website. In the end, our robot was able to sink a large percentage of the shots that it took, and during competiton it made 21 of 24 from well beyond the three point line, scoring a total of 63 points.
|