Best way to measure period between pulses? Counters and FPGA

[Mr. Lim]

We have a digital optical sensor, and we want to measure the time between between pulses. Once we get the time, we would then calculate the rotational speed of a wheel.

I thought the Counter class did this for us using the FPGA?

Using the GearTooth class (which extends Counter), for some reason we're getting very poor resolution from getPeriod().

GearTooth geartooth = new GearTooth(1);
rpm = ??? / geartooth.getPeriod();

Our RPM steps up and down in increments of 375 RPM!

You might ask how many pulses per revolution we have, but should that even matter? I was under the impression that the resolution should be dependent on the precision of the timing device?

Ironically, we did the math, and the resolution of 375 RPM is what we would get if we polled the Counter every 20ms, and calculated the period by dividing 20ms by the number of pulses received.

What am I missing here? Do I need to explicitly set up the Counter to use the FPGA / Timers / etc? Or is this all a ruse, and the Counter doesn't measure time between pulses at all, but polls every 20ms instead?

Has anyone successfully calculated a wheel speed by measuring time between pulses using the FPGA via the Counter/GearTooth class?

[Mr. Lim]

I need to clarify this post...

I am having problems with how the period is being calculated.

There is a BIG difference between these two approaches:

1) Polling the counter every 20ms and counting how many pulses occurred. Period = 20ms / pulses

2) ACTUALLY measuring the time between two pulses using the FPGA. Period = the measured time

Approach 2 results in a much higher resolution in our application, and the documentation in WPILib is unclear when 1 or 2 is used with Counter/GearTooth objects.

From looking at source more, I'm lead to believe approach 2 ONLY happens if you've specifically setup a 4x Encoder object and you can't do approach 2 at all with a Counter/GearTooth object.

Has anyone else seen otherwise?

[Mr. Lim]

Well, to answer my own question...

It seems it is possible to directly measure time between transitions with a Counter object by using SemiPeriodMode.

Thanks to Joe Hershberger's post on the FIRST Forums here:
http://forums.usfirst.org/showpost.p...8&postcount=12

[jhersh]

Originally Posted by Mr. Lim

Well, to answer my own question...

It seems it is possible to directly measure time between transitions with a Counter object by using SemiPeriodMode.

Thanks to Joe Hershberger's post on the FIRST Forums here:
http://forums.usfirst.org/showpost.p...8&postcount=12

That's not quite an accurate interpretation of my post. You can measure the frequency in any of the counter / encoder modes. The point I was trying to make was that the semi-period mode is pretty much useful only for timing.

From reading your application description, you probably want to use Up/Down counter mode, and only specify the "up source". When you read the timer output, it will be reporting the speed based on "method 2" that you described above.

Cheers
-Joe

[Thad House]

So for our shooter last year we used a counter with a light sensor. How we got the correct value is we took the period, then took the reciprocal. We then divided that number by how many pulses you get per rotation, and then multiply that by 60. That gives the RPM.

[saikiranra]

Oooh, we were doing this today! Thank you for potentially solving any questions that we might have come up with!

Also, teams who have done this before, how accurate is finding the RPM using an optical sensor compared to using an encoder?

[Alan Anderson]

Originally Posted by saikiranra

Also, teams who have done this before, how accurate is finding the RPM using an optical sensor compared to using an encoder?

The typical quadrature encoders used on FRC robotis are optical sensors. The accuracy is going to be the same, assuming the sensor detects all the marks it's looking for. The precision will be a function of the number of "ticks" per revolution and the consistency of the spacing of the light and dark marks. In general, more marks seen going by in a given time gives better precision.

[Mr. Lim]

Originally Posted by jhersh

That's not quite an accurate interpretation of my post. You can measure the frequency in any of the counter / encoder modes. The point I was trying to make was that the semi-period mode is pretty much useful only for timing.

From reading your application description, you probably want to use Up/Down counter mode, and only specify the "up source". When you read the timer output, it will be reporting the speed based on "method 2" that you described above.

Cheers
-Joe

This is odd, because all weekend we were have major resolution problems.

We had a Counter set up exactly as you describe above. The periods we were getting had a very pronounced stepwise response. As a result, our RPM readings changed in increments of about 375 RPM.

We did the math, and these increments corresponded with 1 count / 20ms, which led us to believe the reads were still being done via method 1.

Very strange.

Is it possible that the other modes (other than semi-period) use the FPGA to count pulses over a 20ms period instead of measuring the time between pulses directly?

[saikiranra]

Originally Posted by Alan Anderson

The typical quadrature encoders used on FRC robotis are optical sensors.

So in theory, is it possible to use the WPI Encoder Libraries with an optical sensor and a piece of reflective tape?

[Mr. Lim]

public double getPeriod() {
        double period;
        if (m_counter.readTimerOutput_Stalled()) {
            return Double.POSITIVE_INFINITY;
        } else {
            period = (double) m_counter.readTimerOutput_Period() / (double) m_counter.readTimerOutput_Count();
        }
        return period / 1.0e6;
    }

Something isn't jiving here. In the above code, why would you take the period and divide by the count? If the FPGA is measuring the period directly, should we just be taking the period directly? Will count ever be anything other than 1?

[Joe Ross]

Originally Posted by Mr. Lim

Something isn't jiving here. In the above code, why would you take the period and divide by the count? If the FPGA is measuring the period directly, should we just be taking the period directly? Will count ever be anything other than 1?

The FPGA doesn't return floating point values, so the period isn't in units you can use directly. Presumably, the Period is actually the period in clock cycles, and the count is the number of clock cycles per second. Dividing those two gives you a period in seconds.

[Thad House]

I dont know about in Java or C++, but in labview the library already converts it into period per pulse in seconds. So if you do 1/x on that, you get pulses per period. Then you have pulses per second, and that is easy to convert to rotations per minute with just unit conversions. We used geartooth mode for this purpose and it worked perfectly.

[jhersh]

Originally Posted by Joe Ross

The FPGA doesn't return floating point values, so the period isn't in units you can use directly. Presumably, the Period is actually the period in clock cycles, and the count is the number of clock cycles per second. Dividing those two gives you a period in seconds.

Close. The "period" is in microseconds. The "count" is the number of samples accumulated by the averaging engine. The code also divides by 1.0e6 before returning to give the required "seconds" unit.

[jhersh]

Originally Posted by Mr. Lim

public double getPeriod() {
        double period;
        if (m_counter.readTimerOutput_Stalled()) {
            return Double.POSITIVE_INFINITY;
        } else {
            period = (double) m_counter.readTimerOutput_Period() / (double) m_counter.readTimerOutput_Count();
        }
        return period / 1.0e6;
    }

Something isn't jiving here. In the above code, why would you take the period and divide by the count? If the FPGA is measuring the period directly, should we just be taking the period directly? Will count ever be anything other than 1?

The variables are not terribly verbose... the "count" is the number of samples in the sliding window average. Count will always be 1 if you specify not to average (NumberOfSamplesToAverage = 1).

The FPGA does not like to divide without using up a bunch of gates, where and the RT CPU with an FPU has no problem doing this. This is an optimization where all the addition and synchronization is done in hardware where it needs to be done, but the divide operation to get the actual average period is pushed to the driver.

If you want "Method 1", you have to do it the way Ken Streeter described. If you want "Method 2", you must use the FPGA.

Cheers,
-Joe

[Ether]

Originally Posted by jhersh

the "count" is the number of samples in the sliding window average.

Joe,

How is this implemented under the hood in FPGA? Is there a ring buffer in the FPGA which the FPGA populates with the 6.525us_resolution_timestamp for each rising edge it detects (assuming it's not in semi-period mode), and then when requested retrieves the elapsed time between the N+1 most recent samples in the ring (which the cRIO CPU then divides by N)?

Count will always be 1 if you specify not to average (NumberOfSamplesToAverage = 1).

How large can "NumberOfSamplesToAverage" be? I searched the 2012 C++ and the 2013 Java WPILib code but couldn't find that search string.


EDIT:

@all:

I attached a small Excel app that computes the RPM jitter caused by the 6.525us timing resolution of the edge detections. There will be additional jitter due to manufacturing tolerances in the physical locations of the edges in the sensor, but I've not included those here.

Note how large the jitter is with a 360 PPR sensor at 5000 RPM with averaging set to 1. If you set the averaging to 120 (1/3 revolution) you can reduce the jitter dramatically, at the cost of some phase lag in the signal.

If you make a 1 PPR sensor with averaging set to 1 you'll be able to get an updated reading every 12ms at 5000 RPM with very low jitter.