Encoder rate noise
 

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

Re: Encoder rate noise
 

How are you mounting and driving the encoder?

How are you decoding it?

And what speeds.

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

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?

Re: Encoder rate 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?

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

Doh >.<

Re: Encoder rate noise
 

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 :mad:

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.

Re: Encoder rate noise
 

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.

Re: Encoder rate noise
 

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

Re: Encoder rate noise
 

Look at the datasheet for the tolerance specs on symmetry and quadrature delay for this encoder. These also affect the max speed the FPGA can handle.

Using 4X decoding with no sampling is likely to be very noisy, given the above-mentioned tolerances on symmetry and quadrature.

Free play between the encoder shaft and whatever it engages can exacerbate the noise, especially if using 4X decoding with no sampling.

Re: Encoder rate noise
 

Switching to 1x decoding does not lose direction sensitivity. It still uses the B channel for direction, but only 1 transition of the A channel.

1x decoding helps reduce noise beyond just reducing counts to within the limit of the FPGA. It also allows additional digital samples between each count, effectively acting like averaging 4 samples at 4x. It also ignores manufacturing tolerances between the different signals, like Ether mentioned. For the S4 encoder, B lags A by 90 degress +/- 60 degrees (max).

Re: Encoder rate noise
 

Like Aren pointed out, this was added prior to the 2014 season. http://wpilib.screenstepslive.com/s/...d-known-issues

Re: Encoder rate noise
 

Ah, thanks for that, good to know. I'm guessing 2x behaves similarly, skipping the falling edge of each channel and using it as a second sample to smooth things out relative to 4x.

Re: Encoder rate noise
 

Are you driving the encoder using the press on plastic gears on the backside of the gearbox (near the shifting cylinder)? The larger of these gears is known to sometimes have a sloppy press fit, you could superglue it in place if this is the case to ensure no slip between the ball shifter output shaft and this gear that drives the encoder gear.

Re: Encoder rate noise
 

What if the FPGA cannot keep up with all of the counts it would be averaging at 1x? Does it still properly count every 4th tick, even though the 3 in between go by too quickly? And then adds in the extra samples (and direction sensing) provided 3 intermediate ticks, provided they are slow enough to capture? Sort of nitpicking...

Re: Encoder rate noise
 

2x uses the rising and falling pulse of channel A (since those are 180 degrees apart).

Re: Encoder rate noise
 

All that matters is the edge that it is looking for at 1x does not exceed the digital clock rate (It will count and handle direction correctly, but will have horrible rate noise). It doesn't matter if the other edges happen too fast, because it will latch the values on the digital clock.

Re: Encoder rate noise
 

thanks you very much for all of your suggestions. I put the config timer in the begin file and it cleaned up a lot of the noise. what number of samples do you normal avareage

Re: Encoder rate noise
 

I would still like to know what you refer to as "noise".

Re: Encoder rate noise
 

We used a Low Pass filter of 20% to reduce the noise of our drive encoder rates. I've linked to the code below. Key note: The Low Pass filter code I linked needs to be executed as a preallocated clone reentrant because data is stored for more than 1 iteration. Go to vi properties>execution for this setting. You can tune LPFilt to whatever works best.

Context:
http://puu.sh/9ADYL/292687bb80.png
LPFilt.vi:
http://puu.sh/9ADVq/5b0cc41731.png

Re: Encoder rate noise
 

This is not entirely true. The behavior of the quadrature decoder is not guaranteed if both signals change value on the same clock cycle. For the cRIO, that means if A and B channels both change within a single 6.525 us sampling period on the DIO module, that the count will fail. I don't recall what the FPGA does in this case. If it doesn't count at all, it means there is nothing to measure the time of. If you are seeing glitches where the rate is occasionally close to half of subsequent rate measurements (with averaging off of course) then you may identify this.

Fundamentally, the 1x vs 4x decoding only affects the amount of averaging you can do (by essentially being an average of 4 samples). It also affects how much position resolution you have if you care about that (but exposes you to mechanical inaccuracy as described above). Another difference is simply that there are 12 quadrature decoders in the FPGA... 8 counters (capable of 1x and 2x decoding) and 4 dedicated 4x quadrature decoding units. Bottom line, the FPGA still has to "see" all 4 edges in sequence no matter what the decoding scheme.

Of course if you are running anywhere near the digital I/O sampling rate, then the FPGA's built-in rate calculations are so noisy that they are practically useless. In this situation I recommend that you calculate the rate by reading the number of counts that changed in a fixed time period. This will be far more accurate at these high speeds. You can very accurately get the counts in a fixed time period by using the DMA feature of the FPGA to send the encoder count value at exact intervals measured by the FPGA.

Re: Encoder rate noise
 

...because you can't tell which edge came first, so you don't know the direction.

Unless you setup the FPGA to do averaging over a large enough sample size?

Are there code examples how to do this in all 3 supported languages?

Re: Encoder rate noise
 

Correct. Also for noise rejection. If you get a bounce or even a little electrical noise around a transition, you may count that edge more than once (you could use digital filtering, but that drops the max rate even further).

That would break noise rejection and could also be an invalid assumption. The point is the decoder simply doesn't know.

Perhaps, depending on your requirements. Generally it is the wrong approach for very fast encoder signals.

Not that I'm aware of. I don't even know that DMA was implemented at the API level in WPILib for C++ and Java.

Re: Encoder rate noise
 

I did a little math about this about 10 months ago:

http://www.chiefdelphi.com/forums/sh...34&postcount=7


If there's anyone reading this thread whose team has successfully implemented Joe's DMA recommendation, would you please share your code.

Re: Encoder rate noise
 

Sorry for the slow response but here is a picture of the encoder noise i was talking about. The red line is the right wheels with the config timer encoder block and the white line is the left wheels without this block. The scale is y axis is FPS and x is time

http://www.chiefdelphi.com/media/photos/40710?

Re: Encoder rate noise
 

What is the RPM of the encoder shaft?

Re: Encoder rate noise
 

around 30 rev per second

Re: Encoder rate noise
 

That's 1800 RPM, which far exceeds the spec for your sleeve-bearing encoder.