paper: Shooter Wheel Speed Control

When it comes to getting the shooter velocity, we have a prox sensor that registers one raised edge per shooter rotation, and then we use the Counter class in LabVIEW to handle the input. This uses the FPGA to calculate the MS time between raised edges of the input (don’t have access to the code and the specific VI) and we just convert that to RPM.

Something like that may be possible with these encoders, if the FPGA can register all of the raised edges. The only issue we have found is that we occasionally get very large times resulting in astronomical RPMs (nearing 100,000 I believe). We just throw those out and feed in the last code cycle’s RPM value.

It doesn’t look like I’ll have a chance to write code to test, or use Bill’s, on a robot before Championship.

What is “MS” time ?

Sorry, that is misleading. I meant milliseconds.

Specifically, we are using the, 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. (

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

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.

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 + Kprevious_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.

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)

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.

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.

[strike]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?[/strike]

See ensuing posts. Doh!

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

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?

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

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

No, you’re right.

I think the rule violation would either be:


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:


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)

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

Yes, I would think so. See footnote2 on Page1 of Rev C of the paper.

I just want to thank all of you that have posted useful information in this thread. It has helped us greatly! We only have one student programmer and one mentor that do programming on our team.

For the first time this season we finally have a “smart” shooter…

It took us three nights this past week to get things sorted. At first we tried a banner sensor, but it only had 12 “ticks” per rev at random reflective tape spacings. :ahh:

Saturday we connected up a Grayhill 64 bit encoder to the wheel axle.

We were able to get it somewhat tuned in for fender shooting.

See Here:

The only current downside is that the encoder is rated for only 5000 RPM’s and we exceed that. :eek:

FYI we are using two Banebot 775’s for the drive, two victors, and two Shepherd 6" wheels.