Consistent Encoder RPM Issues

[Tom Line]

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.