[FTC]: Tips page on using FTC Encoders with LabVIEW

[jbbjjbt]

Originally Posted by PhilBot

Once such strategy is NOT to reset the encoders. If you never reset them, that problem goes away.

Phil,

We have been trying code that uses this strategy based on the examples in your paper. We read the encoder, add the number to it that we want to go to, run the constant speed vi until the encode reads the new number and stop.

Most of the time this is working really well. It definitely has gotten rid of the jerky motion that won't die without killing the power.

But sometimes either the encoders don't read or the loop processes to slowly and the robot goes way past where it is supposed to stop. It is somewhat random as it will work one run and not the next. It is frustrating and time consuming.

Have you seen this? Do you have any ideas how to fix it?
Thanks,

[Rick TYler]

Originally Posted by jbbjjbt

But sometimes either the encoders don't read or the loop processes to slowly and the robot goes way past where it is supposed to stop. It is somewhat random as it will work one run and not the next. It is frustrating and time consuming.

Have you seen this? Do you have any ideas how to fix it?

I'm not Phil and I've only worked with Vex and FRC encoders... so, for what it's worth.

You sometimes get this if your encoder is spinning too fast for the computer to keep up with it. Adding a gear to a half-speed shaft running just for the encoder can fix this. In other words, if your encoder is on your drive axle, add a small gear to the drive shaft driving a big gear on another axle with an encoder on the shaft. The second shaft doesn't do anything except drive the encoder running at half speed.

If it's more subtle than that, let's wait for someone who knows what they are talking about.

[PhilBot]

Originally Posted by jbbjjbt

Phil,
But sometimes either the encoders don't read or the loop processes to slowly and the robot goes way past where it is supposed to stop. It is somewhat random as it will work one run and not the next. It is frustrating and time consuming.

Have you seen this? Do you have any ideas how to fix it?
Thanks,

Hi

I still see times when for some reason the NXT stops being able to talk to the Motor controller. When it happens, it usually continues for about 2.5 seconds, and then corrects itself. Not helpfull if you are planning a complex sequence.

The encoders keep running insider the speed controller, but don't get seen by the NXT untill after the bus fault clears.

Are you keeping track of your 12V battery voltage? My experience is that these "random" problems occure much more if the battery voltage is let go below 13.5 V (some have said 13.75V)

This isn't a great lot of help, but we've just resigned ourselves to keeping the battery charged and putting up with random motions.

I'll say that we also get our best results if we power down BOTH the NXT and 12V betwen each run. It just "seems" to help. The glitch seems to occur whenever we forget this power-cycle step.

Phil.