Trouble with Tetrix Encoder and Move Fixed Distance VI

[4644Mentor]

We are an FTC team with a 4 wheel drive train, with two wheels powered by motors (with encoders) and the other two wheels unpowered.

We have a fairly simple LVLM autonomous code that uses the Move Fixed Distance VI to go forward, turn, go forward.  We use the reset encoders before each attempt to move a fixed distance.  After each movement, we display on the NXT the encoder values.

70% of the time, it works perfectly.  30% of the time, it does not.  When it fails to function properly, it will: not go forward, turn, go forward, OR, go forward, turn, not go forward, Or, go forward, not turn, go forward.  In each of these cases, the values displayed on the NXT accurately reflect what the robot did (not what it was programmed to do).  I.e. if it did not go forward, but turned, then went forward.  The NXT would display:

Left: 0 (measured after reset before moving)

Right: 0 (measured after reset before moving)

Left: 0

Right: 0

Left: 2000

Right: -2000

Left: 10000

Right: 10000

Here is an example of the first "go forward" code:

We are happy 70% of the time, but does anyone have suggestions of what we can do to address the 30% failure rate?

Thanks,

      Lance

P.S. the broken wires are the result of the copy/paste, they don't exist in the actual code.

[Kevin_F]

I dont see anything obvious. In the past there were some issues with the encoders where they would jump for one tick to a really high number, the LabVIEW block would say it was done and then continue. I think that issue has been fixed this year (its certainly not coming up with the frequency it used to). Would you be able to do some tests with your setup where you just log the output of the encoders and see if you see any of these jumps. I also think on the move fixed distance you can give a positive speed for all cases and that the distance specifies which direction to turn- not sure if that will make a difference but it might be worth a try.

[4644Mentor]

The team's competition was last week.  For the tournament they modified the code to use a "Move motor" vi, and the "Read motor" vi, inside a While loop, with the loop continuing until the specified distance was achieved.  That appeared to solve the problem.  Not sure why the "Move fixed distance" vi didn't work for the team, but they were able to work around it. 

Thanks for your help.

                  Lance