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.