Chief Delphi - High speed encoder with slotted / flat end... can't find one.

Page 4 of 6

Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Electrical (http://www.chiefdelphi.com/forums/forumdisplay.php?f=53)

- - High speed encoder with slotted / flat end... can't find one. (http://www.chiefdelphi.com/forums/showthread.php?t=106568)

Ether

22-05-2012 22:12

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Tom Line (Post 1171097)

How does getrate calculate the rate?

I would assume it takes the elapsed time (between the last two counted edges) and divides that into whatever value you have set for DistancePerPulse.

Quote:

having the longest period between ticks that still gives you new data for each loop would give you the most accurate rate calculation. Am I interpretting this correctly?

That should give you a very accurate and noise-free rate calculation, assuming the edge location tolerance compared to the edge spacing is small (in other words, if you are making your own sensor with more than one piece of reflective tape, make sure they are evenly spaced).

Tom Line

22-05-2012 22:13

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Ether (Post 1171100)

Yes. That's why GetRate is so noisy for high-count encoders. The tolerance of the locations of the edges relative to the spacing between edges is high, so you get jitter.

In the C++ implementation of WPILib (but not the LabVIEW or Java implementations), GetRate does do some averaging in an attempt to reduce the noise, at least according to this post.

Well isn't that entertaining :eek: . As a result of the noise we saw with getrate with our 128 count counter, we switched over to calculating rate ourselves, and have been moving to progressively higher-count encoders to reduce noise. It's a bit of a kick in the butt to understand we should have been going the opposite direction for the most accurate reading, and should go back to using getrate.

Guess I'll figure out our lowest speed tonight and our loop time and determine the lowest count encoder we can use.

AdamHeard

22-05-2012 22:16

Re: High speed encoder with slotted / flat end... can't find one.

In terms of precision and how wpilib implements them, are getRate and getPeriod comparable?

apalrd

22-05-2012 22:17

Re: High speed encoder with slotted / flat end... can't find one.

You can configure getRate to tell the FPGA to average a certain number of samples - This is NOT done in the Get Encoder VI, but in a different VI (Counter Set Averaging). You can also set the maximum time between pulses before the counter declares the encoder to be stopped. I believe it sets the time to 0 in that case, which the VI that reads the FPGA register then uses to determine the "Stopped" boolean output, but I don't have the VI in front of me.

We set it to 12 (using a hand made 4-line encoder) and there was very little if any noise. We don't even filter the output and it looks very clean.

My current laptop doesn't have WPIlib on it, so I can't read the exact documentation.

On a semi-related note, make sure to use Up/Down mode for the counter, and not Semi-Period mode. Semi-Period mode measures the time of either the logical high or logical low pulse (not the time between rising or falling edges), as to read a sensor which outputs a PWM signal, so differences between black and white line size will cause measurement errors in Semi-Period mode (I know the documentation conflicts on this, I have observed this behavior and know it to be true).

Edit: All of this applies to LabVIEW. I have not read through any of the other WPIlib's.

Ether

22-05-2012 22:19

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by AdamHeard (Post 1171109)

In terms of precision and how wpilib implements them, are getRate and getPeriod comparable?

From the WPILib C++ Encoder class:

Code:

/**

 * Get the current rate of the encoder.

 * Units are distance per second as scaled by the value from SetDistancePerPulse().

 * 

 * @return The current rate of the encoder.

 */

double Encoder::GetRate()

{

        if (StatusIsFatal()) return 0.0;

        return (m_distancePerPulse / GetPeriod());

}

AdamHeard

22-05-2012 22:25

Re: High speed encoder with slotted / flat end... can't find one.

If using getPeriod or getRate, would the optimal precision be the smallest amount that still guarantees a new data point per cycle of the control loop? Or is this difference likely negligible when compared to other errors in the system?

Ether

22-05-2012 22:30

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by apalrd (Post 1171110)

You can configure getRate to tell the FPGA to average a certain number of samples - This is NOT done in the Get Encoder VI, but in a different VI (Counter Set Averaging). ...All of this applies to LabVIEW.

I don't have LabVIEW installed here; could I ask you to please post a screenshot of the LabVIEW help where it says that the FPGA is being configured to average a certain number of samples?

Ether

22-05-2012 22:52

Re: High speed encoder with slotted / flat end... can't find one.

Regardless what method you use the read the encoder, it should be mounted so that free play between the encoder and the flywheel is minimized.

apalrd

22-05-2012 23:10

Re: High speed encoder with slotted / flat end... can't find one.

5 Attachment(s)

Quote:

Originally Posted by Ether (Post 1171114)

I don't have LabVIEW installed here; could I ask you to please post a screenshot of the LabVIEW help where it says that the FPGA is being configured to average a certain number of samples?

Attached are a few screenshots of the LabVIEW help illustrating several of the things I mentioned in my post above. I also attached the contents of the VI's (CounterConfigureTimer and CounterGet) and all relevant SubVI calls.

Tom Line

22-05-2012 23:39

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by apalrd (Post 1171124)

I see. I'm assuming the encoder getrate has no similar ability to set the sample number to average?

Ether - the method you described of calculating our own rate is the own we switched to when we threw out the getrate because of noisy returns with our high-count counters.

Now that I'm comparing the two I wonder which would be more accurate: a 512 count encoder using our own rate calculation, which will potentially lose accuracy based on when the last count happened, or a low encoder count method using the FPGA... how precise is the FPGA's internal timer?

apalrd

22-05-2012 23:48

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Tom Line (Post 1171127)

I see. I'm assuming the encoder getrate has no similar ability to set the sample number to average?

I see the confusion.

There are two (Actually three, only two are exposed) sets of Encoder VI's in LabVIEW:

-Encoder (what most people use for Encoders, can be set to 1x,2x,4x decoding, set number of distance per count, etc.)
-Counter (what Encoder internally uses for 1x or 2x encoding, can be set in many more ways than Encoder, can set averaging)
-There is another module which is not exposed which handles Encoder 4x decoding, it is like Counter but uses a different set of FPGA modules.

The FPGA has 8 Counter and 4 Encoder4x modules which can be used. Counter can do 1x or 2x quadrature or single wire, as well as Gear Tooth and PWM input handling. Encoder4x can do 4x quadrature decoding.

I have been talking about Counter as the Encoder VI's, since we use Counters directly for our shooter controller.

JamesTerm

23-05-2012 00:04

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Ether (Post 1171091)

In what way do you think it is similar?

I don't think it is similar... I think it sounds similar to this behavior:
"
and set a max and minimum that limits the amount of change from reading to reading
"

The kalman limits the amount of change from reading to reading when noise is introduced. I looked at the labview's definition of coerce and it looks like it is more like the priority averager I showed earlier... from what I can tell. (I do not use labview, so these terms are unfamiliar to me).

JamesTerm

23-05-2012 00:12

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Tom Line (Post 1171127)

The thing I find interesting here is that you threw out the GetRate()... In our tests the GetRate() worked every bit as well as using...

well that's the question... what exactly did you use?

We used GetDistance() which is virtually GetRaw(). I did not see the need for critical sections, so I'd be curious to see how you did this.

Tom Line

23-05-2012 00:36

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by JamesTerm (Post 1171135)

Initially we used getrate with the equivalent of a 64 count per rotation encoder. We would easily see swings of +/- 200 counts / second.

JamesTerm

23-05-2012 01:15

Re: High speed encoder with slotted / flat end... can't find one.

Quote:

Originally Posted by Tom Line (Post 1171137)

Initially we used getrate with the equivalent of a 64 count per rotation encoder. We would easily see swings of +/- 200 counts / second.

That sounds just like what I showed in the noisy graph that was posted in pages 2-3. Notice how the reading jumps above and below a more predominant line (cyan).

And we use WindRiver... so now I'm wondering if we really did get some averaging features in the WindRiver builds.

All times are GMT -5. The time now is 05:55.

Page 4 of 6

Show 100 post(s) from this thread on one page