Re: paper: Shooter Wheel Speed Control
 

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)

Re: paper: Shooter Wheel Speed Control
 

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

Re: paper: Shooter Wheel Speed Control
 

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.

Re: paper: Shooter Wheel Speed Control
 

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.

Re: paper: Shooter Wheel Speed Control
 

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)

Re: paper: Shooter Wheel Speed Control
 

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.

Re: paper: Shooter Wheel Speed Control
 

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.

Re: paper: Shooter Wheel Speed Control
 

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!

Re: paper: Shooter Wheel Speed Control
 

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 :D

Re: paper: Shooter Wheel Speed Control
 

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?

Re: paper: Shooter Wheel Speed Control
 

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

Re: paper: Shooter Wheel Speed Control
 

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

Re: paper: Shooter Wheel Speed Control
 

No, you're right.

Re: paper: Shooter Wheel Speed Control
 

I think the rule violation would either be:

Or, more likely this one:

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)

Re: paper: Shooter Wheel Speed Control
 

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.


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