Encoder rate noise

[Bpk9p4]

I have been playing with some s4 encoders on are robot and am getting very large noise on the encoder rate. I was wonder if people are also seeing this problem. If so what type of filter are you using or is there another way to get a cleaner signal

[Ether]

Originally Posted by Bpk9p4

...getting very large noise on the encoder rate

How are you mounting and driving the encoder?

How are you decoding it?

And what speeds.

[Bpk9p4]

Originally Posted by Ether

How are you mounting and driving the encoder?

How are you decoding it?

And what speeds.

It is mounted to an idler sprocket to a gear box. So there should be no slip

I have the encoder running in a 100 ms period task. It is setup how it says in the example

I am getting around 9600 pips per second

[Al Skierkiewicz]

What kind of noise are you experiencing? How fast is it spinning?

[Bpk9p4]

I am seeing about a 33% noise. I attached a picture of my code bellow. The encoder is running at about 1500 rpm

http://www.chiefdelphi.com/media/photos/40706?
http://www.chiefdelphi.com/media/photos/40707?

[Al Skierkiewicz]

Originally Posted by Bpk9p4

I am seeing about a 33% noise.

???

Are you using the S4 ball bearing version? The sleeve bearing lists 100 RPM as max shaft speed. Are you seeing noise on an oscilloscope?

[Aren Siekmeier]

Some of the wires in your VIs are overlapping or hidden, so it's difficult to be sure where they are connected...

What happens if you switch 4x decoding to 1x? You lose direction sensitivity, but it only counts one edge of one channel, instead of both, so it may be able to keep up better.

Do you know the CPR (counts per revolution) of your S4 encoders? I believe the standard options are 100 and 360.

Can you post a plot of your encoder rate over time? Also make sure there is no load on the gearbox so it can spin freely to ensure a constant speed.

Edit: Thanks for the note, Joe, good to know. Note Joe's later post for more about 1x vs. 4x.

[Aren Siekmeier]

Also, I forgot to mention. There should be a VI in the Encoder palette to set the sample interval. You can call this in Begin.vi on your encoder reference to change the duration of the rolling interval the FPGA calculates the rate over.

[notmattlythgoe]

Originally Posted by compwiztobe

Also, I forgot to mention. There should be a VI in the Encoder palette to set the sample interval. You can call this in Begin.vi on your encoder reference to change the duration of the rolling interval the FPGA calculates the rate over.

I really hope they make this available in C++ and Java without having to modify the source in this next year's version of the API.

[Ether]

Originally Posted by Bpk9p4

It is mounted to an idler sprocket to a gear box. So there should be no slip

I have the encoder running in a 100 ms period task. It is setup how it says in the example

I am getting around 9600 pips per second

What do you mean by "pips" in this context?

What example are you referring to?

What is the complete model number of the S4 you are using?

How fast are you spinning the encoder (RPM) ?

Are you using the FPGA to compute rate? If so, what sample size are you using? And what mode 1X, 2X, or 4X? Or are you reading delta counts and dividing by elapsed time? If so, are you just dividing by 100ms? Or are you reading the system clock to get elapsed time? For the 100ms task, are you using a timed loop or a wait loop?

It would help if you would post a picture of the relevant portion of your code showing all the parameter values you are using to decode the encoder signal.

[Aren Siekmeier]

Originally Posted by notmattlythgoe

I really hope they make this available in C++ and Java without having to modify the source in this next year's version of the API.

edu.wpi.first.wpilibj.Encoder.setSamplesToAverage?

[notmattlythgoe]

Originally Posted by compwiztobe

edu.wpi.first.wpilibj.Encoder.setSamplesToAverage?

Doh >.<

[Aren Siekmeier]

Originally Posted by Ether

What do you mean by "pips" in this context?

What example are you referring to?

What is the complete model number of the S4 you are using?

How fast are you spinning the encoder (RPM) ?

Are you using the FPGA to compute rate? If so, what sample size are you using? And what mode 1X, 2X, or 4X? Or are you reading delta counts and dividing by elapsed time? If so, are you just dividing by 100ms? Or are you reading the system clock to get elapsed time? For the 100ms task, are you using a timed loop or a wait loop?

It would help if you would post a picture of the relevant portion of your code showing all the parameter values you are using to decode the encoder signal.

The Encoder Get VI he showed in 100ms loop screenshot is spitting out the rate that the FPGA calculates (via the orange wire) in distance/s based on the average encoder period for the last N samples (see setSamplesToAverage) and the Distance/Tick number fed in in Begin.vi. The Begin.vi shows he is decoding in 4x mode. The 100ms loop is merely polling the FPGA for an updated rate number every 100ms. LabVIEW is really not the easiest to read

I would like to see a plot vs. time of the rate you get from your 100ms loop. Also, can you give any details about the gearbox (input motors, input voltage, reduction between motors and idler sprocket/encoder, and any load applied). A complete S4 encoder part number will also help us know what speeds it is rated for, the CPR, etc. Something like S4-X-250-X-S-B.

[Aren Siekmeier]

OP: Let me try to explain a little bit what we are trying to get at and also a little about how the encoder works.

As far as I can tell, you have the S4 encoder attached to an idler sprocket in a gearbox, which is spinning at a constant 1500rpm (please correct me if any of this inaccurate). Then the two data wires are connected to DIOs 2 and 3 on your digital sidecar. Each of these wires carries a square wave, 90 degrees out of phase with each other (this part is what makes it a quadrature encoder), which the FPGA reads to keep track of distance traveled. In 4x mode, it watches for rising and falling edges on both channels A and B to determine which direction the encoder is spinning and then increment or decrement it's local counter (making it an incremental encoder). It also computes the period, the length of time between the last two of these "ticks." The average period is computed over a certain number of samples. If this average period is above a maximum, the FPGA treats the encoder as "stopped." If not, it takes this average period, divides your Distance/Count by it, and comes up with the Rate number. All of this computation is done in hardware pretty lightning fast inside the FPGA.

When you call the Encoder Get VI, you are asking the FPGA to tell you how many ticks it's counted and the current rate it has computed. When you initialize the encoder, you initialize all these parameters I described above, the 1x/2x/4x mode, the Max Period, the samples to average, etc.

Noise on the rate can come from a few places

1. The rate is actually, physically, that noisy. You can make sure this isn't the case by removing all load from your gearbox to ensure that the motors can get it up to a constant speed.

2. The encoder is spinning so fast that the FPGA is missing some of the ticks go by, so sometimes it's getting much longer periods than usual, so the calculated rate is inconsistent. The FPGA runs pretty dang fast: the last time I looked into this I think the encoder had to be running something upwards of 5 or 10,000 rpm to outrun the FPGA. But this could be your problem, and you can help the FGPA keep up by telling to only count 1 edge of 1 channel (1x mode). Knowing the CPR of the encoder helps you know just how fast it can run.

3. It's also possible that you are not average any samples at all, you are just always looking at the very last period calculated by the FPGA. This really shouldn't be that inaccurate, but it could be. Edit: see Ether's post about this. You could make sure that you are averaging more like 10 samples to be sure of this.

[Bpk9p4]

Thanks for all of the great replies. It is amazing the support you can get on this website.

I am using the sleeve bearing (not sure on part number) so you could be correct and i am exceeding the max speed. however i still get a lot of noise at low speed

I will add the config timer tonight when i get home and try reducing it to x1 to see if that helps. I am currently running it with no load already. i will also post a plot of the encoder values and noise and more information about which encoder i have


edit:
Gear box: VexPro 3 cim ball shifter with 2.16 ratio and we are mounting the encoder to the gear box with an idler sprocket
encoder: us digital s4 with 256 cpr