Quote:
Originally Posted by Tom Line
Success in one area, and failure in another.
We've changed where our encoder is mounted and subsequently doubled the count rate. Our biggest problem appears to be the use of the Labview (and therefore WPI) Encoder getrate to get the instantaneous rate. The getrate returns horribly noisy data, presumably because of a very short measurement period.
We now calculate our own getrate, and that has completely smoothed the encoder input signal. This, in turn has smoothed both our PID and our bang-bang. We can switch back and forth with the click of the button. The best tuning of the bang-bang (combination of filter and slew rate) nets us approximately +/- 60 RPM. Our PID is around +/-25, which I'm very happy with. The bang-bang gets up to speed is about 2.0 seconds. The PID is about 2.5 seconds.
We do still see the same slow drop off from a high speed to a low speed with PID. However, we don't ever have an issue with that because once the fire button is pushed the drivetrain is zeroed and the pneumatic brakes are engaged. That's the polite reminder to the driver not to try driving while we're shooting
This is a 400% improvement in our RPM repeatability from shot to shot. We'll see if it translates on the field at nationals. Thanks to Ether and Chris for keeping the ideas flowing.
|
Tom,
Thanks for posting this. Even if it helps no-one else, it does validate the approach I took with the vi's I created.
In them, I calculate the rate based off the counts/period. The period is fixed by the Timed Structure, so the measurements should be consistent.
By comparison, the WPI GetRate appears to be calculating the rate based on the period of two pulses.
Based on the shooter we currently are using:
360 counts/rev.
Sampled every 10ms.
180 counts translates to 3000 RPM.
That means 180 pulses are used to determine the rate instead of just two. The variability of those 180 pulses is averaged out over 10ms vs. the variability of just two pulses in one sample. It makes perfect sense that calculating your rate is a less noise prone process.