We use the Tetrix motor encoders quite a bit during autonomous. For our straight drive the robot simply drives a until either the left or right encoder exceeds the target (steering is via Gyro).

19 times out of 20 everything works perfectly, but once in a while the robot stops very early at a random point along its route, and proceeds on to the next command in the program. In particular, last night the initial drive down the ramp cut-off so early (say 16" instead of 54") that the robot was still on the ramp when it turned and drove off the side - big problem. I can't attribute this to wheel slip, so the only way I can figure this happens is for the code to get a bogus high value from the motor encoder from time to time. Is this a phenomenon that is known to happen?

We're leaning towards a modification where the encoder must read above the target multiple times before the robot stops. If we do that, is there a need for a short delay between successive encoder reads to ensure the program is really getting a new value from the HiTechnic motor controller rather than the same (potentially bogus) buffered value?

I've never had this happen with the Tetrix encoders, but from the information that you've given, your analysis of the problem sounds correct. I would suggest having a ~10 ms delay between readings, and wait for 2-3 readings above the threshold. would you mind posting your code so we can make sure of what the problem is?

We had that problem last year. Please take a look at this thread -> viewtopic.php?f=52&t=3164

Don't wait for a "time" wait for an encoder value to change again. We solved it by:

1. loop until you see a greater than threshold motor value you are looking for.
2. store that value you just saw.
3. keep looking until you see a new different motor encoder value.
4. If it also is a greater than threshold value then you stop the move
5. If it is not also greater than threshold value then go to step 1

We have had no problems since implementing this algorithm.