pic: Encoder Noise

[Bpk9p4]

[cdm-description=photo]40710[/cdm-description]

[notmattlythgoe]

How many samples did you set the FPGA to average?

[ayeckley]

Is this with the bot on the ground, or supported on blocks? If there is no load on the drivetrain then this seems pretty normal. We've been able to attribute this to backlash and the accompanying rattle within the drivetrain. With a "real" load the measurement should be more well-behaved since the masses are 10x-100x larger and the backlash-induced rattle goes away. Overdamping of the measurement (by cranking up the number of averages) brings it's own set of problems.

[Bpk9p4]

This was on blocks. I am using 50 for the config timer. I have not tried it on the ground yet but plan on doing that this weekend. Thanks for the advice

[notmattlythgoe]

This was on blocks. I am using 50 for the config timer. I have not tried it on the ground yet but plan on doing that this weekend. Thanks for the advice

Did you try with a sample count somewhere around 10? We did this last night and our smoothed graph looks similar to yours, so you might not be gaining anything by having 40 more samples. The more samples you average the slower the system reacts to changes.

[Ether]

Plot of encoder noise.

How fast is the encoder shaft spinning (RPM) ?

[notmattlythgoe]

How fast is the encoder shaft spinning (RPM) ?




Ours were spinning at about 7k RPM max speed, I'll try to remember to grab a picture of our data next meeting, but that's not for another week.

[Tom Bottiglieri]

What is the "config timer encoder block"?

[notmattlythgoe]

What is the "config timer encoder block"?

I believe its the setting that sets how many samples you want the FPGA to average when it reports the encoder rate. In java it would be the setSamplesToAverage() method for the Encoder class.

[Ether]

Ours were spinning at about 7k RPM max speed

I was asking the OP, but that's OK. What exact model encoder were you spinning at 7K RPM ? And how were you decoding it ?

[Aren Siekmeier]

I believe its the setting that sets how many samples you want the FPGA to average when it reports the encoder rate. In java it would be the setSamplesToAverage() method for the Encoder class.

The Configure Timer VI for encoders in LabVIEW sets both the number of samples to average (setSamplesToAverage(int)) as well as the max period before the FPGA interprets the encoder as "stopped" (setMaxPeriod(double)).

[notmattlythgoe]

I was asking the OP, but that's OK. What exact model encoder were you spinning at 7K RPM ? And how were you decoding it ?




I figured you were, but the more information the better.

We are using these (http://www.usdigital.com/products/encoders/incremental/rotary/shaft/s4) and we were decoding in 4x with 10 samples being averaged.

[Ether]

We are using these (http://www.usdigital.com/products/encoders/incremental/rotary/shaft/s4)...

...we were decoding in 4x with 10 samples being averaged

...the more information the better...

Agreed :-) So:

What is the complete part number of the part you're using (including CPR, bearing type, etc)?

Were you reading counts from the FPGA and dividing by elapsed time, or reading the rate from the FPGA? Please post code if you have it.


@jhersh: (if you are following this thread) would there be any advantage, tolerance-wise, to change the sample size to an even multiple of 4 (say 12 or 8) so that the averaging would always take place over an integer number of cycles?

[notmattlythgoe]

Agreed :-) So:

What is the complete part number of the part you're using (including CPR, bearing type, etc)?

Were you reading counts from the FPGA and dividing by elapsed time, or reading the rate from the FPGA? Please post code if you have it.


@jhersh: (if you are following this thread) would there be any advantage, tolerance-wise, to change the sample size to an even multiple of 4 (say 12 or 8) so that the averaging would always take place over an integer number of cycles?




S4-120-250-N-S-B

We were reading the rate from the FPGA. I'l post some code when I get a chance.

[Ether]

S4-120-250-N-S-B

Your S4 is less than half the CPR of the OP's and has ball bearings. So the two are not comparable. What works for you won't necessarily work for the OP.

At 7K RPM you are exceeding the speed the FPGA could handle if your S4 were at max tolerance for quadrature phase error:

Welcome to RLaB. New users type `help INTRO'
RLaB version 2.1.05 Copyright (C) 1992-97 Ian Searle
RLaB comes with ABSOLUTELY NO WARRANTY; for details type `help warranty'
This is free software, and you are welcome to redistribute it under
certain conditions; type `help conditions' for details
>
> format(5);
>
> CPR = 120 # cycles per rev (single channel)
120
>
> EPRS = 2*CPR # edges per rev (single channel)
240
>
> EPRQ = 2*EPRS # edges per rev quadrature (both channels)
480
>
> RPEQ = 1/EPRQ # angular distance (revs) between cross-channel edges
0.0020833
>
> per = 261/40e6 # FPGA sampling period, seconds
6.525e-006
>
> RPS = RPEQ/per # maximum revs per sec
319.28
>
> RPM = RPS*60 # maximum RPM (revs per minute)
19157
>
> # angular distance (revs) between cross-channel edges
> # with "typical" tolerance:
>
> RPEQ_TYP = (90-10)/90*RPEQ
0.0018519
>
> RPM_TYP = RPEQ_TYP/per*60
17029
>
>
> # angular distance (revs) between cross-channel edges with "max" tolerance:
>
> RPEQ_MAX = (90-60)/90*RPEQ
0.00069444
>
> RPM_MAX = RPEQ_MAX/per*60
6385.7
>
>
> # RPM with no tolerance, typical tolerance, and max tolerance:
> RPM
19157
> RPM_TYP
17029
> RPM_MAX
6385.7
>
>

[notmattlythgoe]

Your S4 is less than half the CPR of the OP's and has ball bearings. So the two are not comparable. What works for you won't necessarily work for the OP.

At 7K RPM you are exceeding the speed the FPGA could handle if your S4 were at max tolerance for quadrature phase error:

Welcome to RLaB. New users type `help INTRO'
RLaB version 2.1.05 Copyright (C) 1992-97 Ian Searle
RLaB comes with ABSOLUTELY NO WARRANTY; for details type `help warranty'
This is free software, and you are welcome to redistribute it under
certain conditions; type `help conditions' for details
>
> format(5);
>
> CPR = 120 # cycles per rev (single channel)
120
>
> EPRS = 2*CPR # edges per rev (single channel)
240
>
> EPRQ = 2*EPRS # edges per rev quadrature (both channels)
480
>
> RPEQ = 1/EPRQ # angular distance (revs) between cross-channel edges
0.0020833
>
> per = 261/40e6 # FPGA sampling period, seconds
6.525e-006
>
> RPS = RPEQ/per # maximum revs per sec
319.28
>
> RPM = RPS*60 # maximum RPM (revs per minute)
19157
>
> # angular distance (revs) between cross-channel edges
> # with "typical" tolerance:
>
> RPEQ_TYP = (90-10)/90*RPEQ
0.0018519
>
> RPM_TYP = RPEQ_TYP/per*60
17029
>
>
> # angular distance (revs) between cross-channel edges with "max" tolerance:
>
> RPEQ_MAX = (90-60)/90*RPEQ
0.00069444
>
> RPM_MAX = RPEQ_MAX/per*60
6385.7
>
>
> # RPM with no tolerance, typical tolerance, and max tolerance:
> RPM
19157
> RPM_TYP
17029
> RPM_MAX
6385.7
>
>





After thinking about it more we weren't at 7k rpm the encoder was reporting a rate of 7k.

[Ether]

After thinking about it more we weren't at 7k rpm the encoder was reporting a rate of 7k.

7k what?

[notmattlythgoe]

7k what?




Pulses per second. Which I believe should put it around 875 RPM.

(7000 pules/s / 480 EPRQ) * 60 s = 875 RPM

[jhersh]

@jhersh: (if you are following this thread) would there be any advantage, tolerance-wise, to change the sample size to an even multiple of 4 (say 12 or 8) so that the averaging would always take place over an integer number of cycles?


It depends on the decoding that you have selected. If you select 1x, you have effectively chosen to always average a full cycle, thus averaging out phase noise, If choosing 2x, then multiples of 2 is advised, and if choosing 4x, multiples of 4 is advised (at least if phase noise is something you would like to eliminate, but its a trade-off). I can't imagine a scenario where selecting 4x and 63 samples averaged is better than 64 averaged. I'd love to hear it if you have thought of one.

[Ether]

...we were decoding in 4x with 10 samples being averaged.

@notmattlythgoe:

if you are still following this thread, you might want to try 8 or 12 samples instead of 10 (see jhersh's post).

[notmattlythgoe]

@notmattlythgoe:

if you are still following this thread, you might want to try 8 or 12 samples instead of 10 (see jhersh's post).




I saw that, thanks. We'll have to give it a try.