Encoders — Noise

[keehun]

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

[wt200999]

Is it possible that this is your problem:

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

[rwood359]

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

[bayesianlogic]

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.

[j_johnson]

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.

[rwood359]

Originally Posted by j_johnson

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.

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.