Re: Consistent Encoder RPM Issues
 

I see what you mean about the wiring.

Encoder mounting looks better than I imagined.

Re: Consistent Encoder RPM Issues
 

I don't have any C++ examples.

This link might help:

http://firstforge.wpi.edu/sf/go/artf...v=1&_pagenum=1

Re: Consistent Encoder RPM Issues
 

I may not be understanding but do i have to recompile WPIlib to change that? Thanks.

Re: Consistent Encoder RPM Issues
 

Without recompiling, just setting everything up I am getting a spread of 1100 rpm at max speed. Between 5200 and 6300 rpm so the same issue as the encoder class with pretty much the same spread. I am unsure of how to handle the FPGA but I will keep digging around. Thanks to everyone who has helped out so far. You guys showed up quick!

Re: Consistent Encoder RPM Issues
 

You have to recompile the parts you change, I guess. I've not done this with C++. Do you have a guru you could ask?

Re: Consistent Encoder RPM Issues
 

I think setting the FPGA sample ring buffer will bring that down to an acceptable level without introducing undue phase lag. If you can get a good signal you may be able to use the very simple bang-bang control.

Re: Consistent Encoder RPM Issues
 

I do not at this moment but yes if I am to change the C++ I will have to recompile. Lets see how difficult this is. I'll post back as soon as I figure something out. I'm sure there's at least a semblance of a guide on compiling it. The link you posted is immensely helpful. The changes will be simple.

Re: Consistent Encoder RPM Issues
 

I may be gone shortly, it's past 1am here.

Re: Consistent Encoder RPM Issues
 

Not a problem. Check back tomorrow if you could. Appreciate the help. :)

Re: Consistent Encoder RPM Issues
 

I'm here. How's it going?

Re: Consistent Encoder RPM Issues
 

Cool trick, I wasn't aware we could poke the FPGA in that manner. This should work for the OP, but a "slower" sensor shouldn't do anything but help.

Re: Consistent Encoder RPM Issues
 

Indeed. At frisbee shooter wheel speeds, many teams have had excellent results with one-count-per-rev sensors (optical and magnetic). One-count-per-rev sensors don't require changing the FPGA sample ring buffer default size.

Re: Consistent Encoder RPM Issues
 

If you're having issues recompiling WPILib, you can do this more simply by grabbing copies of Counter.cpp and Counter.h and renaming the files and class from "Counter" to something like "AvgCounter". Then add them to your workspace and make a code change similar to the java one in the FirstForge link. In fact, I'd recommend doing it this way since it's a lot simpler than recompiling WPILib. It's what I did when I wanted a modified version of the PIDController and the PIDSubsystem classes.

Re: Consistent Encoder RPM Issues
 

We saw the same problem in LabView last year (you'll find many threads about it). The getrate (or period) only calculates between the last 2 ticks. So if you have many many ticks between loops, it actually hurts you because the time used between the ticks is very small, and creates a large amount of error. The benefit of using the counter is that you can set it to average a certain number of results to minimize the error.

If you can't follow what others are saying, there is a quick and dirty way that we used in LabView.

Each time your code loops, take the total number of counts from each loop and divide it by the total amount of time between loops.

You'll get some inaccuracies, but it should give you all the accuracy you really need for a frisbee firing PID loop. They're not nearly as sensitive to speed as the basketballs were last year. We're using this method on our first shooter wheel (only because we already had it wired up and didn't want to swap sensors) and have had acceptable results.

We're using 341's method of the 2011 photosensor and reflective material that results in 1 count per RPM. The resolution that we see on that wheel is superior to the first method.

Re: Consistent Encoder RPM Issues
 

Just a heads-up. The above method has some issues of its own to be aware of:

1) the answer is only as good as the method you use to get (or control) the elapsed time

2) any task swaps or lengthy interrupts which occur between reading the counts and getting the elapsed time will create signal spikes.

3) the faster you run your code, the more RPM jitter you get due to count quantization (for example, at 10ms and 6000 RPM with a 250 counter, the jitter would be ~24 RPM)

4) the slower you run your code, the more phase lag you get in the sensor signal (for example, at 20ms there'd be ~10ms lag)