Encoders — Noise
 

Hello teams,

How are you going about and "cleaning" up the encoder signals? I'm getting as high as 100rpm "jump"... When the speed is low, it's tolerable, but at high speeds it reads 700 then next reading reads 900 then reads over 1000 then jumps down to 700 and it's just horrible.

I've looked in to the signal processing sub-vis and they are just way to complicated. If anyone can make that signal a clean one, please let me know!

Thanks,
Keehun
Team 2502

Re: Encoders — Noise
 

Is it possible that this is your problem:

http://www.chiefdelphi.com/forums/sh...ad.php?t=72176

Re: Encoders — Noise
 

We spent days on the encoder rate problem, before we gave NI enough information for them to isolate the FPGA bug.
Here's the thread that includes our testing:
http://forums.usfirst.org/showthread.php?t=11004

Re: Encoders — Noise
 

Well, while I don't know anything about the details of these encoders, averaging -- presumably over some kind of lagging window -- is not the best approach. First of all, averaging is sensitive to outliers, so one spike will pull the mean of a group of samples high for the duration of the time it remains in the window. Second, averaging will lag the current value by typically a half window width, possibly longer, even if the window is optimally weighted. It's possible that because it's an encoder, the lag isn't so critical. Third, it depends upon how many impulsive values you get in a typical timeframe and whether these are bursty or not. Bursts are difficult to handle without introducing lags no matter what's done. If lag's a problem, getting a better sensor might be your only answer.

The other approaches are to use a different kind of processing. Instead of averaging, try a median in a window having an odd number of taps. You might also look into hysteresis smoothing, although if the signal is really impulsive or bursty, that won't help much. You could try combinations.

It's difficult to recommend more without looking at a dataset capturing a series of outputs from such an encoder.

Re: Encoders — Noise
 

We are using Windriver, but were able to set up a task (indirectly through the PIDController) that retrieved the encoder count every so often (about 20 ms for us), and dividing the difference in encoder counts by the time between checking. If you are using Labview, I believe it has a timed loop that you could use for something similar.

Re: Encoders — Noise
 

Doh, I was obsessing about the FPGA bug and didn't consider that distance was correct and I could get delta times to compute the speed in LV.
Thanks for reminding me.