Well, this is a bit wordy, but I think I've discovered the essence of this problem after discussing this issue at length with both National Instruments rep Jeff Steele and with Team 3658 (BOSON - Subatomic Particles, finished #2 in Edison division) last week at the World Championships. We think that the problem is actually within the sub-VI for moving the motors in "position" mode. On the FTC site, I noted that the problem was also seen by some teams using ROBOTC, while we were experiencing the problem in LabVIEW. However, based on what I think is actually happening, it doesn't surprise me that the problem would occur in either program.
What happens is this - when you are using the "position" sub-VI, you are telling the motor to turn a certain number of rotations or degrees (for example, "move from 0 to +8130"). However, the Tetrix encoders will sometimes throw out a spurious number (e.g., 1, 2, 3, 4, 8450, 6, 7). If that spurious number is higher than the limit set by your program for the move (e.g., +8130), then the sub-VI will immediately consider the move "finished" and move to the next step. So the program is not actually "skipping" a step, it is just receiving an erroneous input that tells it to finish the move early. That's why sometimes it appears to skip a step altogether, while at other times it appears to "stop short" in the middle of a move (i.e., not complete a move).
We figured that it must be some sort of HW issue somewhere in the encoder chain (encoder-encoder wire-motor controller-data cable-NXT) that causes the spurious signal, so we started replacing everything one at a time. At one point, after replacing the encoder cables themselves, it appeared to fix the problem (we ran our program 20 times straight with no errors). Unfortunately, the problem soon appeared again, and we were stumped.
However, the coach from 3658 told me that, after extensive research and doing all the things that we did, they solved the problem by switching from "position" mode for a move to "speed and time" mode - in other words, instead of telling the motor to move a certain number of degrees, they programmed it to move at a specified speed for a certain amount of time. This solves the problem because, even though the encoders may still occasionally throw out a spurious signal, the move is now bounded not by encoder position but by time, which is of course controlled by a very accurate clock in the NXT itself. So let's say you set the motor to move at 20 deg/sec for 6 seconds - the program is still using the encoders to get feedback on motor speed, but that won't create a program error in and of itself. The motor speed readings may be (20, 20, 20, 300, 20, 20, ...) - but that obviously erroneous reading in the middle is essentially smoothed out (i.e., the controller may send out a very brief signal to slow the motor down after reading 300, but it will immediately increase voltage to the proper level as soon as it reads the desired speed of "20" again). And that slight voltage surge starts and stops so quickly that it has no noticeable effect. So the move will continue to work until the 6 seconds is completed, at which point the program will go to the next move. The only way that the program could think that the move was completed "early" is if it received an erroneous clock signal from the NXT (which is very unlikely).
So we actually reprogrammed our robot in the middle of the World Championships last week to work in this "speed/time" mode, and sure enough, it seems to have solved the problem! Unfortunately, you need to be careful, as programming in "speed" mode can create new problems - when our robot locked up on a ramp during autonomous mode, the controller kept sending power to the wheels to try to get them up to the programmed speed - but since the robot wasn't able to move, the wheels were grinding on the ground, and the controller kept trying to increase the voltage to increase the speed to the set point. This resulted in us burning out BOTH motors during autonomous mode in one match, which sunk us. So we need to figure out a better way to handle error correction based on unexpected encoder readings.
In addition, we don't think that the speed/time mode is as accurate as position mode, so we had noticeably more variation in terms of where our robot ended up at the end of a series of moves. But this certainly seemed to be an acceptable trade-off given the alternative of just skipping steps in the middle of a position move!
The best alternative would probably be to program in some better error handing in the position sub-VI - i.e., it should be able to "toss out" any reading that is not sequential (as the encoder rotates, it always must go immediately to the nearest 1/8 degree on either side, right?). It isn't physically possible for the encoder to skip from position 4 to position 8000 and then back to 5 - but the sub-VI apparently doesn't know that.
Hope this helps!
Michael Butler
Head Coach, Iron Eagles Robotics Team (FTC #3708)
. Whatever... I'd just like to know one way or another. And whether it can be fixed.