Quote:
Originally Posted by artdutra04
What kind of ± resolution on the RPM are you looking to achieve? And at what frequency do you want to know the current RPM of the shooter?
I would suggest creating an Excel document to calculate how various changes to the CPR and sampling time interval affect the resolution of the shooter speed output. Depending on what you are looking for, you may be able to achieve your desired results without hardware changes.
For example, with a 128 CPR encoder (and 1x decoding) sampling over a 100ms time interval, you can achieve an RPM resolution of 4.6875rpm per encoder count, while sampling over only a 30ms window yields a resolution of 15.625rpm per encoder count.
|
Art, excellent questions. Obviously, I'd like the tightest RPM control I can get. Working backwards, I'd like to be no more than +/-6 inches in height, and I still suspect that's more than many top teams are aiming for. That means my shooter velocity can vary from 35 ft/s to 34.3 ft/s.
That means my rpm may vary from about 2674 to 2619 (single wheel)
In retrospect, that means that the 30ms time frame with the 128 encoder we'd been trying to use takes up a huge chunk (30%+) of our tolerance. 5% seems like a more reasonable number. Which means that a 512 count encoder should get us fairly close to having a measurement error of 5% over 30ms.
Obviously I'm trying to minimize calculation (delay) time. The fewer cycles required to get an accurate reading means that much less 'lag' between a change in the system and your response to that change. Where is the sweet spot, based on shooter momentum and motor update rate? Heck if I know...