Team Crankshaft

Home Documents Code Photos Design Perspectives

 

What we did that worked

The AI that we used is explained in the software documentation, but here are a few reasons why it was something that worked well for us: (1) The AI was robust. We could count on plays following a well-defined structure. We had confidence that the plays were coded correctly since they were generated by a seperate program - see playmaker in the code section. (2) The AI config files helped with testing and overall structure. By defining regions and other conditions, we were able to put together a general ai plan easily. This also allowed us to change the robot's personality.

Our vision system was written completely and thoroughly from the start. We never dropped below 30 frames/sec when scanning the bounding boxes. While we did tweak the vision late in the semester, for the most part it was reliable.

Going with C++ allowed us to create classes for the major components of the system. For examples see Object.h and Vision.h. C++ is a lot more flexible than C, we definately saved ourselves some headaches by avoiding the many globals Dr. Beard defined.

What we did that didn't work

We underestimated the complexity of controlling an omnidirectional robot. Mathematically, we should have been able to control both position and angle simultaneously, but because of an imprecise model, we found that we could only control angle or postion, not both at the same time. This had huge reprecussions in how we wrote plays - we couldn't count on the robot being at the angle we told him by the time he reached the end of the path.

What we are glad we did

Despite the problems with the control, the omnidirectional design was fun to do and very interesting to get working. Our robot was definately the most agile of the group. Extra batteries allowed us to move quickly and test for longer periods at a time than what the handyboard would have allowed us.

One interesting strategy that we implemented was the idea of breaking up the field into regions. Because there are areas of the field where it is not possible (or desirable) to push the ball in a straight line to the goal, we came up with mathematical equations that determined these areas and then broke the field up into 9 regions. This allowed us to write different plays for every region and easily tailor our AI.

What we wish we would have done

We think the control would have been better if the noise from the camera was elimated and our velocity determined by encoders on the motors. This way we would know precisely how fast our wheels were moving and could compensate for friction.

One strange problem we encountered was when the ball was in our plow, but our angle was uncontrollable - this led to us sometimes spinning the ball towards our goal. It would have been better to have all the sides uniform to insure that the ball always went towards the oppenents goal. Of course, if we had been able to control our angle at all times, this wouldn't have been a factor.

It would have been nice to have smaller motors to pull the wheels closer in - this would have allowed us more room for a kicker or dribbler (but again, since we couldn't control our angle, this isn't much of an issue).

One thing that frustrated us was that since most of the other teams put off finishing their hardware, we didn't have many chances to test against the other robots. We should have gone in at different times than normal to play the teams that worked when we didn't.

How we worked together

From the very start, we divided up the problem; we had 1 person for hardware, 1 for ai, and 2 for control/vision. This allowed us to work somewhat in parallel.

We met together often to code and to discuss strategies. We met most Saturedays and 3-4 nights during the week. We spent on average 20+ hours a week per person. We tried to avoid working individually as much as possible.

How we paced ourselves

From the very beginning we put in the time. We finished all of our labs and tried to do them in a way that we could use later on. We created our schedule and refered to it to make sure we stayed with our plans. When we realized that we wouldn't have time for something, we cut it and got on with the project. Perhaps the best thing we did to pace ourselves was to be consistent - we never crammed and we never took any time off either (in fact, we left at 9 p.m the night before the competition).

Practical Advice