paper: Shooter Wheel Speed Control

[kenavt]

Originally Posted by Ether

What is "MS" time ?

Sorry, that is misleading. I meant milliseconds.

Specifically, we are using the WPI_CounterGet.vi, and the Period (sec) output, then dividing 60 by that output to obtain RPM. If you had more than one rising edge per wheel rotation, you could presumably multiply by that factor to obtain RPM.

It seems like the FPGA can track 38,000 pulses per second. (http://forums.usfirst.org/showthread.php?t=11589)

[Ether]

Originally Posted by kenavt

Sorry, that is misleading. I meant milliseconds.

I don't have LabVIEW here. I hope you don't mean millisecond resolution. At 5000 RPM, millisecond resolution would give you an RPM resolution of ~+/-350 RPM

Also, with only one pulse per rev, at 2000 RPM you would be getting stale speed data half the time at 50Hz execution frequency (TeleOp).

[Tom Line]

Originally Posted by Chris Hibner

When you say +/- 100 RPM, do you mean that as: a) noise in the measured RPM, b) slow oscillations of 100 RPM, or c) your steady state (highly filtered) RPM settles at 100 RPM from your target?


We run the unfiltered encoder speed into the bang-bang controller and the speed noise is on the order of +/- 200 RPM at that stage. Once the shooter reaches it's target speed, our heavily filtered encoder speed reads about +/- 15 RPM of noise, but the unfiltered encoder speed going into the controller is still its usual +/- 200 RPM. We keep 2 versions of the speed in our software - one unfiltered to use for input to the controller, and one heavily filtered to use as the input to our "okay to shoot" logic.

Important note: we do NOT rate limit the PWM command to our Victor speed controller. We send it a steady stream of 1.0 or 0.0.
Another important note: our shooter wheel has a fair amount of inertia.

Chris, now you've got me really really curious. How are you filtering?

The only filtering I'm used to is floating average with X number of samples. However, that introduces significant lag. Are you using something more exotic?

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.

[Ether]

Originally Posted by Tom Line

The only filtering I'm used to is floating average with X number of samples...

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.

If what you're doing is saving X samples and averaging them, then that is an FIR filter.

The basic difference between FIR and IIR is that FIR uses only the sampled values, whereas IIR uses the sampled values and the previous filtered value(s).

A simple example of an IIR filter would be:

new_filtered_value = (new_sample_value + previous_filtered_value) / 2

The above is a special case (where K=1/2) of the
so-called "exponentially weighted" IIR filter (commonly used):

new_filtered_value = (1-K)*new_sample_value + K*previous_filtered_value

... where "K" is a tuning constant which varies from 0 to 1.

when K=0, there is no filtering. as you increase K towards 1, the filtering gets more aggressive.

[Chris Hibner]

Originally Posted by Tom Line

Chris, now you've got me really really curious. How are you filtering?

The only filtering I'm used to is floating average with X number of samples. However, that introduces significant lag. Are you using something more exotic?

I've read up on IIR and FIR, and frankly I haven't found a decent English-language explanation of what they DO.

IIR filtering is related to one of my favorite jokes (explaining the difference between math/science and engineering):

There's a game show and the contestants are a mathematician and an engineer (both male).

The host explains the game as follows: There's a beautiful model on the other side of the room. For each question the contestants answer correctly, they get to move half way toward the beautiful model.

At that point the mathematician throws his hands up in the air in anger: "What's the point! If I move halfway there every time, I can never get to the model! This is pointless." Then he storms off the stage.

The host then turns to the engineer and says, "after hearing that, why are you sticking around? You can never get to the model!"

The engineer says, "while everything he said was theoretically correct, I can get close enough for practical purposes."

(rim shot and laugh track here)

How does this relate to IIR filtering? The part of "you move x-fraction of the way toward the goal" is what IIR filtering is about. It's called "infinite impulse response" because you can NEVER get to the goal because you always approach it at a fixed fraction of the way there.


FIR filtering (Finite Impulse Response) means you actually get to achieve your goal (hence the "finite"). If the game show were changed to: "the model is 100 feel away and you get to move 10 feet closer with each answer", that would be an FIR filter - in 10 answers you would get to the final result.

(my answer about how we're filtering is in a future post - I didn't want to clutter my joke with too much other stuff)

[Tom Line]

We've settled on PID because we simply can't get the bang-bang method to give us better results. The real issue that I think I've hit is mechanical - we're at the limits of what our system can provide. No matter how we play with gains, filtering, etc, we're struggling to get the shooter more than +/- 40 to 60 rpm (actual RPM, not filtered much at all other than to remove big spikes that are obvious errors).

Filtering the speed before our 'enable shooting' vi really doesn't help shooter run any more consistently - it just makes it easier for us to check the limits.

I did put a 4 sample moving average in to filter the pid input. That helped with some of the oscillation. We also turned down our proportional gain (we wrote a velocity PID, we're not using the position PID) to help some of the oscillation. The shooter still spins up in around 2 seconds, but that helped the oscillation as well.

I had hoped to manage a major improvement before nationals. We've improved our velocity control probably 50%, but other folks are reporting numbers that are still close to 100% better than ours. That means that in real time ball shooting, we're seeing something like +/- 1 foot in height when hitting the backboard.

[NeatNit]

Hey, I didn't read the whole thread but just wanted to mention that this will not work with a Spike. I haven't tested, but a while ago I read into how the Spike works and it cannot coast, it either powers the motor or breaks.

[Ether]

Originally Posted by NeatNit

Hey, I didn't read the whole thread but just wanted to mention that this will not work with a Spike. I haven't tested, but a while ago I read into how the Spike works and it cannot coast, it either powers the motor or breaks.

Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?

See ensuing posts. Doh!

[NeatNit]

Originally Posted by Ether

Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?

Either way, the SPIKE can connect that side of the motor to either + or -, so wouldn't it still break when both sides are connected to -? (regardless of one passing through a SPIKE and whatnot)

I could of course be very wrong

[nighterfighter]

Originally Posted by Ether

Not true for this application, since motor is being driven in one direction only.

Connect one lead of the motor to the PDB(-), and run the other lead through one relay in the Spike to the PDB(+).

anyone: Is this FRC legal?

It wouldn't be FRC legal.

Also, because a Spike is a mechanical relay, don't they have a limit as to how quickly they can switch to ON/OFF?

[Ether]

Originally Posted by nighterfighter

It wouldn't be FRC legal.

When you make such a statement, you should reference the rule you have in mind.

[Ether]

Originally Posted by nighterfighter

Spike is a mechanical relay

I'm not saying you're wrong, but what is your source for this information?

[Ether]

Originally Posted by NeatNit

Either way, the SPIKE can connect that side of the motor to either + or -, so wouldn't it still break when both sides are connected to -? (regardless of one passing through a SPIKE and whatnot)

I could of course be very wrong

No, you're right.

[nighterfighter]

I think the rule violation would either be:

[R47]

Custom circuits shall not directly alter the power pathways between the battery, PD Board, speed controllers, relays, motors, or other elements of the Robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the Robot’s electrical system is acceptable, if the effect on the Robot outputs is inconsequential.

Or, more likely this one:

[R50]

All electrical loads (motors, actuators, compressors, electric solenoids) must be supplied by an approved power regulating device (speed controller, relay module, or Digital Sidecar PWM port) that is controlled by the cRIO on the Robot.

Each CIM motor and Fisher-Price motor must be connected to one and only one approved speed controller. These motors must not be connected to relay modules.
Servos must be directly connected to the PWM ports on the Digital Sidecar. They must not be connected to speed controllers or relay modules.
If used, the compressor must be connected to one and only one approved relay module.
Each other electrical load (motor or actuator) must be supplied by one and only one approved speed controller, or one and only one relay module.
Electric solenoids may alternatively be supplied by a Solenoid Breakout Board connected to the NI 9472 cRIO module, which is powered by 12V.

As for the Spike, I'm not sure.

I remember hearing/reading about it being one, and it seems to behave like any electro-mechanical relay I've used also. (Mainly, the clicking sound when it switches)

[Ether]

Originally Posted by nighterfighter

I think the rule violation would either be... Or, more likely this one...

Neither of those rules seem to apply unambiguously in this case. The first rule you cited arguably doesn't apply ("custom circuit") and the second rule explicitly allows a Spike to be used to control certain motors.

(Mainly, the clicking sound when it switches)

Well that seems like a dead giveaway. I've never listened to one. (And if I had, I probably couldn't hear it anyway).