High Speed Encoder Problem
 

Hey, we have a 128 click encoder for our shooter speed. Our java programmers managed to get an encoder velocity, but it updates constantly and is all over the place, it ranges +/- 1000 clicks per second when we run a constant speed on the shooter motors, any way to clean up the "noise," if that's the problem. Thanks.

Re: High Speed Encoder Problem
 

How are you calculating the rate? Are you using WPILib?

Re: High Speed Encoder Problem
 

It that a lab view feature? We're using a pre-made java class from the 2012 API. It has a " .getRate() " that returns the angular velocity.

Re: High Speed Encoder Problem
 

WPILib is basically the whole thing. I think encoder.getRate() works by reading the number of encoder counts from the FPGA and then dividing by the time elapsed between readings. As your RPMs increase, your noise will increase. Have you tried a moving average?

1000 ticks per second is actually pretty darn slow. That equates to about 470rpm. Is that the speed you're looking for?

Re: High Speed Encoder Problem
 

That's the encoder we gave you :) .

The getrate from the library is an instananeous rate. You'll be better off using the 'get count' function, and then measureing the time between loop updates like this:

(New count - old count ) / loop time

If that ends up still being noisy, you can average, or calculate over more than one loop. Also, make sure you're running in single sample mode rather than 4x to remove phase errors.

Re: High Speed Encoder Problem
 

Here's some more info on the data behind the .getRate() method and the equivalent LabVIEW and C++ functions.

http://www.chiefdelphi.com/forums/sh...d.php?t=101485

As you can see, it requires some processing to smooth out the output. Tom recommended a good alternative and a quick way to smooth out the getRate() output.

Re: High Speed Encoder Problem
 

IIR and FIR filter options explained here:
http://www.chiefdelphi.com/forums/sh...4&postcount=37

Re: High Speed Encoder Problem
 

Are you sure that your encoder will track that fast? We are making a custom disk for an encoder with only 3 Clicks per rotation to ensure velocity accuracy.

Re: High Speed Encoder Problem
 

Yeah. :rolleyes: :rolleyes:
I thought about an average value too, but our programmers don't know how to implement that.

Re: High Speed Encoder Problem
 

Yeah, I was wondering if we could do that. All the java classes for encoder need an A and B channel. Could we just sample pulses from one digital port and compare it against the code's timer????

Re: High Speed Encoder Problem
 

Yes, but with the Counter class instead of the Encoder class.

Re: High Speed Encoder Problem
 

Perfect, Thanks.:)

Re: High Speed Encoder Problem
 

The periodic rate can be controlled either by a fixed value or follow the driver station. If it is set to follow the driver station, which is the default, then the period time will vary because of being a windows app. If you set the period to a specific value the cRIO will maintain a very precise periodic rate. This could also be a source of your problem.

-Hugh

Re: High Speed Encoder Problem
 

... or you could read the actual elapsed time since the last sample, rather than assuming it is 20ms.

Re: High Speed Encoder Problem
 

If you use an infinite impulse response filter, it is very simple to do:

new_filtered_value = K*previous_filtered_value + (1-K)* new_sample

... that's all there is to it.

"K" is a tuning constant, which you use to adjust the "strength" of the filter. K must be in the range zero to +1. When K=0, there is no filtering. When K=1, the filtering is so "strong" that the filtered value never changes.