paper: Shooter Wheel Speed Control

[nighterfighter]

Hi all, I was the programmer for 1771, and I played around with this method a lot. (Differing ramp rates, update times, etc.)

Our hardware set up was originally 1 FP motor in CIMulator to power the wheel.

The code didn't run in the main tele-op loop, I had it run in its own task. It was set to read the encoder value and change the motor voltage every .05 seconds.

I had the CANJaguar voltage ramp rate set to 110 volts per second.

An important thing that I didn't see mentioned, was WHERE the encoder got read.

We plugged the encoder directly into the Jaguar, and used the CANJaguar's GetSpeed() function.

We believe that having it go directly to the Jaguar, NOT the cRIO's FPGA, allowed it to be read faster. This may or may not have been true.

Of course all these values will change based on your shooter wheel.

As for the RPM consistancy-
When reading the values, we saw an average of 15 RPM difference from our set point for the RPM. If we had more time to dedicate to JUST tuning that, I feel we could have gotten a little bit more accuracy on that.

[Ether]

When reading the values, we saw an average of 15 RPM difference from our set point for the RPM. If we had more time to dedicate to JUST tuning that, I feel we could have gotten a little bit more accuracy on that.

You didn't mention, but I assume you had the Jag set for coast mode, not brake, correct?

If you get a chance, try getting rid of the voltage ramp*, and increase the update rate to 20ms instead of 50ms.

We believe that having it go directly to the Jaguar, NOT the cRIO's FPGA, allowed it to be read faster.

I would think that reading the FPGA would be much faster than talking to the Jag via CAN bus. Does anyone have numbers for this?



*unless you need the voltage ramp to keep the Jag from shutting down at spinup. If so, try turning off the Jag's voltage ramp and put a ramp in the cRIO instead, and make it active only in the increasing direction, and only for speeds below the necessary spinup speed.

[billbo911]

Originally Posted by Ether

If you get a chance, try getting rid of the voltage ramp*, and increase the update rate to 20ms instead of 50ms.


[i]
*unless you need the voltage ramp to keep the Jag from shutting down at spinup. If so, try turning off the Jag's voltage ramp and put a ramp in the cRIO instead, and make it active only in the increasing direction, and only for speeds below the necessary spinup speed.

I can easily see that setting the "Slew Rate Limiter" to only apply in a positive direction when the wheel is below a certain RPM could have a big benefit.

With the largest current loads taking place in the first few loops when starting from 0 RPM, that is when the Jag. would shut down. So, if the limiter only applied when the wheel was below, say 100 RPM, then you would always get full power pulses to maintain the desired RPM.
Easy enough to do in LabView. I'll update my .vi's and have them posted shortly!

[nighterfighter]

Yes, it was coast mode, both on the jumper, and it is set to coast mode in our code.

When we didn't have a ramp rate, we found that our RPM was less consistent, but I can try again. Although,from what we noticed, there was no ramp down, only ramping up.

As for the CAN vs FPGA, we aren't sure. We used 2CAN, as we read that it its much faster than the serial form of CAN. And this shouldn't matter but it was th last jaguar in our chain. (The sixth jaguar)

All of this was done with a single motor. At the north Carolina regional, we added a second motor and jag. We had the same code, and would justave the output to the new jaguar.
We found that it became less consistent, but after we tweaked the values, we got it tuned back. One thing we did try was having the second motor in brake mode, this worked and controlled the RPM nicely, but it got too hot for our liking.

[nighterfighter]

As for the biggest loads being in the initial spin up, I made it where we always spun at a minimum of 500 RPM, so it would never have to pull too much current again.

[Ether]

As for the biggest loads being in the initial spin up, I made it where we always spun at a minimum of 500 RPM, so it would never have to pull too much current again.

Are you talking about the bang-bang controller here? And are you saying that you did not set the motor voltage to 0, but rather set it to some small non-zero value, even when at the control point?

[nighterfighter]

Sorry, should have been more specific.

I told the set point to be 500 RPM, using the bang bang controller.

For ramping down, I told it to go to zero. We never noticed a ramp down, it went straight to zero.

[Ether]

Originally Posted by nighterfighter

As for the CAN vs FPGA, we aren't sure. We used 2CAN, as we read that it its much faster than the serial form of CAN.

Just to be clear: CAN is a serial protocol. 2CAN also uses serial protocols (Ethernet on the cRIO side and CAN on the other).

What you meant is that Ethernet (2CAN) is faster than the RS232 connection from the cRIO to the Jag. No argument there.

But I'd bet a hundred bucks that reading the FPGA is faster than querying the Jag for speed.

One thing we did try was having the second motor in brake mode ... but it got too hot for our liking.

That's one reason why the paper says don't use brake mode.

[Ether]

Originally Posted by nighterfighter

We never noticed a ramp down, it went straight to zero.

How could you tell?

[nighterfighter]

The 2CAN Web page showed it drop to zero throttle. And the jaguar leds didn't blink, just went straight to yellow.

Yes that's what I meant with the 2CAN. You are probably correct about the FPGA thing. I think another reason we decided to have the Jag report it was due to the encoder problems with the FPGA from previous years.

And no arguments about the brake mode, we were getting desperate...

[Ether]

Originally Posted by nighterfighter

The 2CAN Web page showed it drop to zero throttle.

I'm not familiar with the "2CAN Web page". To what does the pronoun "it" in the sentence above refer? If it's the motor_command (throttle), then yes it drops to zero. The ramping is done on the Jag's output.

And the jaguar leds didn't blink, just went straight to yellow

If the ramp rate is 63ms to go from 12v to zero (the Jag default), I don't know if you'd even see it blink.

[nighterfighter]

The 2CAN has a web page interface that displays each Jaguar, lets you set a new CAN ID, and displays the output of the throttle, voltage being output, temperature, current, and a few other things.

I was referring to the Jaguar itself, yes.

I have noticed the blinking when ramping up, but not ramping down. It might be it is changing too fast I suppose.

I think we have an old oscilloscope lying around, I can hook the output to that if it would help, (assuming I can find it).

[Ether]

Originally Posted by billbo911

I can easily see that setting the "Slew Rate Limiter" to only apply in a positive direction when the wheel is below a certain RPM could have a big benefit.

With the largest current loads taking place in the first few loops when starting from 0 RPM, that is when the Jag. would shut down. So, if the limiter only applied when the wheel was below, say 100 RPM, then you would always get full power pulses to maintain the desired RPM.
Easy enough to do in LabView. I'll update my .vi's and have them posted shortly!

Here's the logic I had in mind:

if (measured_speed >= target_speed) motor_command = 0.0;

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

else motor_command = low_command;

Make "spinup_speed" as low as possible and "low_command" as high as possible, without causing the Jag to shutdown.

[billbo911]

Originally Posted by Ether

Here's the logic I had in mind:

if (measured_speed >= target_speed) motor_command = 0.0;

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

else motor_command = low_command;

Make "spinup_speed" and "low_command" as high as possible.

Again, this would be very easy to implement in LabView.

Here's my thoughts on why I didn't jump on this as an option:
1) There can easily be periods of 20+ seconds when the shooter wheel is not being used in a match. During that time, you are just consuming power, even though it may be a small amount, that may be needed later in a match.

2) Depending on where the shooter is in relation to a camera, if you use it as we did, the extra vibration the shooter may be creating can interfere in the imaging process, thus your aim.

3) If a slew rate limiter is used below a certain threshold, then you avoid the possibility of tripping the over-current in the Jag. (Not an issue with a Victor.)

If there is enough interest, I will most certainly create a version that follows the minimum continuous RPM model. Who knows, I might just become a fan of it too.

[Ether]

Originally Posted by billbo911

Again, this would be very easy to implement in LabView.

Here's my thoughts on why I didn't jump on this as an option:
1) There can easily be periods of 20+ seconds when the shooter wheel is not being used in a match. During that time, you are just consuming power, even though it may be a small amount, that may be needed later in a match.

2) Depending on where the shooter is in relation to a camera, if you use it as we did, the extra vibration the shooter may be creating can interfere in the imaging process, thus your aim.

3) If a slew rate limiter is used below a certain threshold, then you avoid the possibility of tripping the over-current in the Jag. (Not an issue with a Victor.)

If there is enough interest, I will most certainly create a version that follows the minimum continuous RPM model. Who knows, I might just become a fan of it too.

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 as high as possible (without causing the motor controller to shut down), and at the very least, 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, high stall current motor), 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;