Click either picture for a bigger view.
To see our code, click here.
In designing our robot, we made the following decisions
Since our robot was not designed with any specific strategy in mind, we were not limited in programming. We thought about scoring one ball and playing defense or trying to score all the balls. In the end, we decided on a hybrid strategy: score 3 to 4 balls in the time it takes most robots to score 2 and then use IR to stay between the opponents robot and the scoring trough.
The strategy broke down as follows. For any starting position, the robot began by turning towards the obstacle and using two Sharp distance sensors to determine the obstacle's position.
If the obstacle was in either position far away from the start, the robot moved at a 45 degree angle to collect the ball farthest away from the trough, turned towards the trough and pushed all three in.
If the block was close to the robot and close to the trough, the robot backed up against the side wall, moved at 45 degrees until it cleared the obstacle, went straight to collect the 2 balls, turned towards the trough and deposited any balls it collected.
If the obstacle was close to the robot, but far away from the trough, the robot moved sideways knocking in the closest ball to the trough and then moved towards the block at a 45 degree angle, went straight to collect 3 balls, and then turned towards the trough and deposited the balls.
After running any of the three programs, the robot was basically in the same place. It now simply slid down the trough side of the table until it was on the opponents side. Once on the other side, the scissors were deployed and the robot moved back and forth along the trough using IR to stay between the opponent and the trough. We also had timeout code for when the robot detected it was no longer moving (using shaft encoders). When stuck the robot would simply stop all power to the motors, re-orient it's servos, back up, turn a little and try to continue along. This correction code actually worked very well and was not hard to program at all.
Unfortunately, we did not do that well in the tournament. In designing our robot, we chose to use a very low gear ratio of 15:1 to keep our robot as fast as possible. This worked very well for us on the practice tables, as by the end of IAP, our robot was running perfectly on the tables in lab. However, the competition tables were freshly painted before competion which increased the friction level significantly. With our low power drive system and the increased friction, our robot was not able to turn on the final contest tables. We needed the wheels to slip a little, but they were not able to. We would suggest using a higher gear ratio to any future competitors. Always remember, the environmental conditions of the final rounds may not be the same as those in lab.
In the end, despite our disappointing performance, we were happy with our robot. We implemented a novel idea (independently rotabable drive wheels) which lead to a unique robot design that had a lot of potential for doing well in the contest. We were most upset that we were not able to demonstrate the ability of our robot to move in any direction without having to change its orientation at all. As a final word of advice we can only say, remember to have fun. Only one robot wins, so the odds are against you. However, if you implement an idea you find interesting, you can feel good even if you lose.