paper: Shooter Wheel Speed Control

[billbo911]

Originally Posted by Ether

I should have been clearer:

The "low_command" is a tuning constant, not the target speed, and was not intended to be so low that it tops out at a speed below the "spinup_speed". "low_command" should be high enough that it briskly accelerates up to (and beyond) spinup_speed, at which point the full voltage is applied.

Many shooter wheel setups can handle application of full voltage to the motor even at zero RPM, but some can't. It's a function of the gear ratio and the wheel inertia and the motor being used. For such setups, simply set spinup_speed=0.0

The code I posted was for those shooter setups that can't handle a full 12 volts being applied at zero RPM, but could, for example, handle, say, 8 volts at zero RPM and 12 volts at 1000 RPM. For that example, you would set spinup_speed to 1000 RPM and low_command to 8 volts. Simple, and gets the job done.

With the code I posted, the minimum continuous RPM is simply commanded as the target speed by each team's software to whatever they want it to be, and the code I posted will bang-bang regulate at that speed. That target speed can be zero if the team so desires.


For really finicky setups (e.g. high inertia wheel, not much gear ratio), you could always add a third "else" statement:

if (measured_speed >= target_speed) motor_command = 0.0;

else if (measured_speed >= spinup_speed) motor_command = 1.0;

else if (measured_speed >= medium_speed) motor_command = medium_command;

else motor_command = low_command;

Got it. So, in essence, you want the absolute maximum acceleration possible, for the particular shooter design, that it can handle without tripping the over-current.

With the version I added today, you can set the trip point for low to high acceleration as well as the rate of slew rate limiter. By tuning these two, you can achieve almost exactly what you are describing. The only difference is the start up voltage will be a ramp, with an adjustable slope, instead of a step from 0v. Granted, it is not the absolute fastest acceleration you can get, but I doubt the differences will be noticeable in actual performance. You will see it on a scope, but that's pretty much it. I'm guessing a only few millisecond difference between the two designs from 0 RPM to target RPM in the 2500-4000 range.

[Tom Line]

I'm interested in teams claiming +/- 15 rpm accuracy.

We've implemented robust PID control, and today implemented bang-bang control as a second option.

We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM.

The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM.

The best the PID loop could do completey unfiltered was arond +/- 80 RPM.

The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds.

I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems.

Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).

[Tom Line]

Originally Posted by Ether

Thank you for posting the data.

Would you mind posting the following additional information please?

- what motor(s)

- total gear ratio from motor to wheel(s).

- what type and diameter wheel(s)?

- Jag or Vic?

- coast or brake mode?

- voltage ramp rate? symmetric or up only?

- what encoder model, and where mounted

- what language

- 1x 2x or 4x decoding?

- Counter or Encoder class?-

to measure RPM, are you measuring the time between consecutive counts, or are you dividing the counts by the delta time?

- if dividing counts by delta time (see above item), how are you computing the delta time

- encoder signal not filtered?

- what execution cycle update rate?

PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example.

Is there any specific reason to use a counter class rather than encoder class?

[Ether]

Originally Posted by Tom Line

Is there any specific reason to use a counter class rather than encoder class?

For the shooter wheel application, you don't need the extra channel for direction. Less wiring, frees up a channel on the DS.

Just curious: did you try using the encoder as described on pages 1 & 2 in revA of the paper?

[billbo911]

Originally Posted by Tom Line

I'm interested in teams claiming +/- 15 rpm accuracy.

We've implemented robust PID control, and today implemented bang-bang control as a second option.

We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM.

The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM.

The best the PID loop could do completey unfiltered was arond +/- 80 RPM.

The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds.

I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems.

Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).

Ether pointed this out to me. Using the "Wait" timing loops is not as reliable for timing events as you might think. Read this paper call Timing is everything by team 358.
I truly believe you can get much more reliable rate control simply by switching to a "Timed Structure" instead of a "Wait" loop.

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

[Ether]

Originally Posted by Chris Hibner

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

... or use brake mode instead of coast mode. This will slow you down real quick. But things may get too hot.

[Chris Hibner]

Ether makes a good point. You'll probably also find your final speed to be less than your desired speed if you use brake mode (see my comment above on our practice robot with the bad gearbox - extra friction caused the actual speed to be less than the desired speed).

A couple of more things to note:

1) Originally, we accidentally hooked up the output of our IIR filter to the bang-bang controller "actual speed" input. The results were not very good. The shooter speed oscillated quite a bit. When you think about it, the oscillations make sense: the phase delay of the IIR filter made the controller stay at 1.0 for too long even if the actual instantaneous speed dictated that the power be 0.0 (or vice versa).

2) Speed controller resolution: Consider that a Victor speed controller has 254 discrete output states (two states are reserved). If the top speed of your shooter is about 5000 RPM (for a shot from the bridge), the best resolution you can do with a constant power command is about 20 RPM (imagine if your PID controller output a very nice steady PWM command). However, if your PWM command dithers the right amount, you can gain resolution on your shooter speed. Don't believe me? Just consider that we're getting tons of resolution to control various speeds just based on commanding 1's and 0's to the power. (I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.). Anyway, that extra dithering of the output is why I advocate not filtering the encoder signal input to the bang-bang controller.

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

[Ether]

Originally Posted by Chris Hibner

(I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.)

I feel your pain. I wrote a paper on it when I was in grad school back in the early '70s.

[Ether]

For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?

a) at t=0, send a request to the Jag via CAN for a speed signal
b) at t=t1, receive the requested speed signal from the Jag via CAN
c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN
d) at t=t3, the Jag receives the new command

[mjcoss]

We have the setup that you're looking for, and I'd be willing to run the test. I'm just not sure how to collect the test data. Do you know if the elapse time for a command is just when the "SetSpeed()" function returns?

So that
t1 = GetClock();
jag->SetSpeed(500);
t2 = GetClock();
elapse time = t2 -t1

Or are you looking for something more complicated? We're currently running the PID loop on the Jaguar, and I'd wish I'd seen this earlier. I might have changed what we were doing as this looks like it might get us what we wanted without the headaches of the PID controls on the Jaguars.

Originally Posted by Ether

For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?

a) at t=0, send a request to the Jag via CAN for a speed signal
b) at t=t1, receive the requested speed signal from the Jag via CAN
c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN
d) at t=t3, the Jag receives the new command

[Ether]

Originally Posted by mjcoss

So that
t1 = GetClock();
jag->SetSpeed(500);
t2 = GetClock();
elapse time = t2 -t1

Thanks for the offer.

No, the elapsed times I am looking for are:

dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back

dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag

dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command.

If you aren't doing all three operations in the same execution cycle, please mention that too.

If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.

[mjcoss]

The question is how to get at that information and what kind of accuracy are you looking for. Note that we are using C++, so ...

GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.

dt2 is a bit trickier. We aren't using your speed control method but rather are running the PID loop on the Jaguar. Each time through our TeleopPeriodic loop, we update the set point. Our periodic loop will do some work if no packet arrives from the driver station, but for the most part we update based on the arrival of new data from the driver station. We don't check to see what the set point currently is, we just reset it to the requested value.

dt3 is even trickier, if not unknowable. Again we could use the total round trip time of the Set() command which is used to register the current set point, but that includes the time to the Jaguar, and the return ack across the CAN bus, and thru the 2CAN and back up the ethernet stack and to the CANJaguar module.

Finally there is a lot of checking that I've added to around the Set() operation. Every Set() is followed by a CAN bus message requesting the fault status of the Jaguar, and then a CAN bus message requesting the PowerCycled flag. If a brown out occurred then the Jaguar configuration is reloaded.

When I get a chance I think I'll implement you're speed controller and see how it does relative to running the PID on the Jaguars as we currently are doing.

Originally Posted by Ether

Thanks for the offer.

No, the elapsed times I am looking for are:

dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back

dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag

dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command.

If you aren't doing all three operations in the same execution cycle, please mention that too.

If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.

[Ether]

GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.

This is what I'm looking for, because this elapsed time (or perhaps half of it) causes phase lag in the process variable. If you could run this one test it would be helpful.