[ZZII 527]

The encoders are giving you a nice actual value of position(like an accelerometer that's already integrated twice, in a way), so those won't have this problem.

The gyro is giving you a rate, though, which is where the problem you are describing occurs. Enter Euler's Method: given rate data at every point and a starting position, you can approximate a solution by using very small straight lines, as everyone else has mentioned. The 26.2 ms loop assures that the step size will be very small. Even if you have one of the gyros that can measure 150 degrees/sec (the BEI one from two years ago is 75 degrees/second I think), 150 degrees/second * 0.026 second/loop = 4 degrees/loop before your gyro reaches its limit and the data is useless anyway. So for any given loop, you can assume the robot has not deviated from a straight path by more than 4 degrees, a pretty good approximation.

If you are looking for more accuracy, you can average two rates as probizzle suggested. Through some mathematical property which I can't explain, error in these numerical integration methods is approximately proportional the step size raised to the power of the number of slopes sampled per step. So if you have a small step size and you sample two slopes, you will have a very accurate approximation.

For the purposes of FIRST, you are more likely to have error due to not being in the exact starting position or getting bumped by another robot and sending the gyro above its yaw rate limit, so averaging slopes may be unneccesary. However, it doesn't eat computing time and it's a cool project anyway. Have you thought about adding an accelerometer to get position data that isn't dependent on the wheels not slipping (but does have the disadvantage of having an acceleration limit of something like 1.5g, which can be easily broken by running into something)?