paper: Shooter Wheel Speed Control

[Tom Line]

Originally Posted by Chris Hibner

Tom,

We're using Victor speed controllers and running the controller in a 30 ms timed loop. We are using a high-quality internal ball-bearing encoder (can't remember the brand), 32 counts per rev, 1x decoding. No filtering on the encoder signal going into the bang-bang controller.

Our shooter logic uses a single pole IIR filter at about 0.5 Hz on the encoder signal. The output of the IIR filter shows noise of about +/- 15-20 RPM. The mean appears to be right at our desired speed. Our practice robot with a really bad gearbox was about 50 RPM less than the desired speed.

I haven't done a data log to actually calculate the mean and noise level with our competition robot, but it looks really good. Our shooter logic requires the filtered shooter speed to be within 30 RPM for more than 4 consecutive samples before we'll shoot a ball. We do have data logging for each shot and shooter speed has not been an issue for delaying shots (aim is usually the long lead time).

The biggest upside we found when switching to this control method is getting the shooter to slow quickly. When we were using PID, shooter speed was often delaying shots, especially if we enabled the shooter and then moved closer to the goal. The I term was always adding some power to the motor which delayed the slow down time. The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).

That explains a decent amount.

We've been using the unfiltered signal, which is fairly noisy. Filtering that should bring it more inline. I'll try that tomorrow with our moving average filter and try a bang-bang again.

Our encoders are all 128 counts per revolution, but they are geared so that we get 55 counts per shooter revolution.

We are using the timed structure set at a 10ms loop rate in periodic tasks (not a while loop with a wait). We did not see much of an improvement moving to a timed structure because our cpu utilization is usually around 70% and our periodic loops have been running fairly consistently (we flag an error message on our driverstation LCD whenever they get too far out of whack).

To give you an idea, we were using a check of +/- 100 rpm for 4 consecutive counts and still getting good distance accuracy from the key. That tells me that our actually speed is fairly accurate, but the noise is masking it. The filter should help.