Consistent Encoder RPM Issues

[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

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.

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

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

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

[nightpool]

Originally Posted by Ether

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.

Indeed. Our team dodged a bullet this year as our physical shooter design made it impossible to put a traditional encoder on and we had to figure out an alternative earlier in the season. It turned out to be very easy to use a normal Rockwell photoeye and a piece of white tape to measure shooter speed. The only biggish change we had to make was our own subclass of Counter to make it work with the WPILib PID controller, but that was pretty trivial, just like 15 lines of code.

The one thing to watch out for is the size of your flag (the tape or what have you). Too small and you might not see it as it flashes past. We had good results with about 30 degrees of coverage.

[Ether]

Originally Posted by meltbox360

Here are the pictures.

I see what you mean about the wiring.

Encoder mounting looks better than I imagined.