Best way to measure period between pulses? Counters and FPGA
 

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?

Re: Best way to measure period between pulses? Counters and FPGA
 

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?

Re: Best way to measure period between pulses? Counters and FPGA
 

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

Re: Best way to measure period between pulses? Counters and FPGA
 

I am currently trying to do the same thing, using a light sensor to create a custom tachometer. As it has been explained to me (correct me if I am wrong) the crio FPGA has an integrater function built in, so even if pulses moving faster than 20ms can be measured. I calculated that on our shooter even with a 1 tick tachometer it will be sending a pulse every 1-2ms, which may be too fast for the AndyMark optical sensors, but I haven't checked too closely. However, it does seem like a good idea for certain high speed feedback.

Re: Best way to measure period between pulses? Counters and FPGA
 

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

Re: Best way to measure period between pulses? Counters and FPGA
 

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.

Re: Best way to measure period between pulses? Counters and FPGA
 

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?

Re: Best way to measure period between pulses? Counters and FPGA
 

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.

Re: Best way to measure period between pulses? Counters and FPGA
 

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?

Re: Best way to measure period between pulses? Counters and FPGA
 

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

Re: Best way to measure period between pulses? Counters and FPGA
 

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?

Re: Best way to measure period between pulses? Counters and FPGA
 

The FPGA encoder support requires a pair of sensors in order to give a quadrature signal. In one direction of motion, A goes high, then B goes high, then A goes low, then B goes low. In the other direction, B goes high, then A goes high, then B goes low, then A goes low. If you can arrange your sensors and marks so that's what you get, the WPI library encoder functions should work.

But the counter functions should work just fine with a single sensor.

Re: Best way to measure period between pulses? Counters and FPGA
 

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.

Re: Best way to measure period between pulses? Counters and FPGA
 

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.

Re: Best way to measure period between pulses? Counters and FPGA
 

As described in another post, hidden in the LabVIEW programming forum (even though we were doing this in Java), Team 1519 had success last year using the Encoder object at 1X sampling to count pulses from a USDigital E7P encoder with a 250CPR optical wheel spinning at around 4000RPM. However, we performed our RPM computation in a different manner than using the built-in functions. We found our approach to give excellent accuracy. This same strategy should work just fine for a Counter object.

First off, we set up a separate task in Java to periodically compute the RPM of our shooter wheels. (This task also will control the motor for the wheels, too.) Below is a code excerpt showing how to set this up:

Below is the definition for the ShooterWheelTask, of which the "run" method will be executed every 20 milliseconds. This code computed the wheel RPM by dividing the number of counts observed since the last invocation by the elapsed time since the last invocation, with appropriate unit conversions. Time was measured using the FPGATimestamp, which has a resolution of approximately 6.5usec 1usec. (Edit: updated resolution per jhersh posting, below.) We then compared the measured RPM against the desired RPM, and used a "Bang - Bang" controller to set the wheel speed. This simplistic approach worked incredibly well. We plan to use it again this year.

We can't take the credit for the "Bang - Bang" controller application -- lengthy CD discussions on this last year led to Ether's white paper on the subject.

Below is a snippet of our "ShooterWheelTask" code. Various declarations of variables are not in this code snippet, but I think you'll be able to figure out what they are from the context.

PS: See you at GSR, Mr. Lim!