Sensors, Code, and Overall Strategy

Main Strategy

When we first sat down to think about our robot's strategy, we decided we wanted to win the competition more than building a cool robot. We decided that our best bet was to try to collect the first two balls in the corners and three of the balls by the block. If we assumed that the other robot tried to score only on their side, and not interfere with the hole on our side, then we would have five balls for a total of 15 points. Unfortunately, we never got down the scoring of the first two balls. Up until the end, that remained our focus.

Starting Orientation

Our robot used three shielded light sensors over three of the quarters of the starting square. By reading what color (black or white) the three quarters were, the robot could figure out which side of the board it was on, and which way it was facing. For example, if two or more of the sensors read either black or white, that told us whether or not we were on the black or the white side. In addition, if one of the sensors read a color that was not the primary color of that side, then we knew that the corner that sensor was reading was the "odd" corner and how we were oriented. Likewise, if all three sensors registered the same color, then we knew the fourth "unsensed" corner was the odd corner. This strategy worked beautifully. The robot never failed to figure out which side it was on and which way it was pointing.

General Navigation

We used 2 bump sensors on each corner of our robot to detect to detect collisions. Each sensor was less than half an inch off the ground level. Each corner had one sensor facing along the path of travel (whether to the front or to the back) and one sensor facing out to the side. All the side sensors had a piece of lego taped on to to make it more sensitive to "point" collisions (where it might just be one corner of the robot that hits something or the robot hits the corner of a block or both.)

Mainly, we used the forward and backward-facing sensors to align the robot along one of the axes of the board. At the point during travel where, both front-facing sensors or both rear-facing sensors were activated, we knew that either our front or back was flat against a wall. This was used effectively when we went to pick up the corner ball with our ramp. We used to realize when we were completely up against the wall, which was the time to raise the ramp. Also, when we turned around after picking up that ball, we backed into the wall so that we knew were facing the trough head on, and not from an angle.

Corner Balls Strategy

Once the robot figured out the starting orientation, it would turn away from the goal and drive into the far wall. The idea here is that the ball there would be wedged between the wall and the ramp. The ramp would lift up so that it would pick up the ball. Once the ramp was high enough, the ball would be sitting on the "uphill" end of the ramp and roll down into the robot. If the ball made it inside, it would depress a button at the bottom which would signal to the robot that it has the ball. If the button wasn't activated, the robot would back up, lower the ramp and drive forward into the wall again, hoping to get the ball this time. It would repeat this 3 times before giving up.

After getting the far corner ball or giving up trying, it would turn around and head towards the ball in the corner by the goal. The robot would plow into this ball and push it over the lip into the trough to score. After it hits the lip, the ramp would lower to release the stored ball if it had it. Everything up to this point is what we were able to get to work and experiement with in field tests and used during the competition. The following is what we wanted the robot to do, but could not implement successfully.

Block-Vicinity Balls Strategy

In capturing balls by the block, we had to first know where the block was. The plan was to use distance sensors mounted on the sides of the robot to give readings of the nearest object under the height of the block. The idea was that since the robot traverses the width of the table once while scoring the first two balls, we could determine the position of the block from the readings. When there is no block next to the robot, the distance sensor reading is very high and erratic. When the block is in any of its starting positions, it becomes very low and more stable. By determining when the reading became low, we could determine where the block was (close to the goals or farther away from them). By looking at the low readings, we could determine if the block was in a position closer to the robot or farther from the robot. By using these two pieces of information as coordinates in a 2-dimensional grid, we could pinpoint the location of the block. Unfortunately, this did not work out as the readings taken from the distance sensors were eratic when the robot was in motion. They are not very precise.

Coding Issues

We ran into some problems in the final week because we were coding inefficiently. The memory on the handy board only allowed for about 16,000 bytes worth of code. We hit that limit the day before impounding. Although we managed to get in all the essential code for getting the first two balls, our work on other parts of our strategy was limited as testing new code meant taking out existing code. The final 24 hours or so was spent refining the existing, working code.

Timeout Code

One positive thing about coding was the timeouts. As the robot progressed through the code and ran into problems, we had "timeouts" programmed in so that it wouldn't sit there trying the same thing over and over until time ran out. Ultimately, this only helped to prevent total code failure where the robot would do nothing for 40 seconds.

Randomness Code

In addition to the main code, we had what we called "lost" code, for when the robot didn't know where it was. When this happened, the robot would give up on the direct strategy for getting the ball and start spinning around while raising and lowering its arms with fury hoping to knock in some of our balls accidentally. Although this didn't work during the competition, we still hold to the belief that randomness plays a large part in the competitions and that when all else fails, haphazard motion gives us some non-negative chance of scoring an extra ball or two.

Shaft Encoders

There's a section on Shaft Encoders in the Mechanics page.


Back to the Main Page