Consistent Encoder RPM Issues

[Ether]

Originally Posted by meltbox360

Here are the pictures.

I see what you mean about the wiring.

Encoder mounting looks better than I imagined.

[Ether]

Originally Posted by meltbox360

I asked in a second edit earlier. Not sure at all. Sorry I checked the docs and then I realized I have no idea how to do this stuff correctly without some experimentation.

I don't have any C++ examples.

This link might help:

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

[meltbox360]

Originally Posted by Ether

I don't have any C++ examples.

This link might help:

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

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

[meltbox360]

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!

[Ether]

Originally Posted by meltbox360

do i have to recompile WPIlib to change that?

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?

[Ether]

Originally Posted by meltbox360

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 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.

[meltbox360]

Originally Posted by Ether

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?

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.

[Ether]

Originally Posted by meltbox360

I'll post back as soon as I figure something out.

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

[meltbox360]

Originally Posted by Ether

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

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

[Ether]

Originally Posted by meltbox360

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

I'm here. How's it going?

[Tom Bottiglieri]

Originally Posted by Ether

I don't have any C++ examples.

This link might help:

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

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.

[Ether]

Originally Posted by Tom Bottiglieri

This should work for the OP, but a "slower" sensor shouldn't do anything but help.

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.

[Kevin Sevcik]

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.

[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.

[Ether]

Originally Posted by Tom Line

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.

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)