Programming a flywheel shooter

My first year of FRC was 2017, and as such I’ve never had the opportunity to program a shooter, which concerns me in regard to Infinite Recharge. In the chance that 2020 is a shooting game, I’d like to be prepared.

How do teams typically program a shooter? Is doing the physics for the projectile motion the way to go, or do people plug distances/heights and flywheel speeds into a spreadsheet and fit the data?

Any input is appreciated.


In 2017 we took distance in from vision tracking and found an rpm that worked and we make an equation to fit. If I remember correctly it was quite linear.


I was under the impression that shooters are dependent on design as well as programming. I didn’t know that you could get multiple ranges with a fixed hood. I thought you’d have to change the angle of the hood to achieve different distances.

1 Like

In 2017 we also used an equation that took in distance from the camera and converted it into rpm. We recorded the distance and which RPM was best and then entered them into a spreadsheet to do a best fit equation and ours ended up being quadratic. In other years we’ve just had different RPMs for different positions.


I mean horizontal velocity certainly affects horizontal displacement, so a change in rpm is a change in the projectile’s final landing spot.

This system seems quite intuitive, and I trust it based on your team’s success. +1

How I would theoretically do it is through an equation. I made an Excel spreadsheet to tell you specific values, and just used desmos to do graphing since excel can’t(I think).

1 Like

We ended up doing something similar, but also taking hood angle into account (servo, so infinite positioning). No complaints out of the drive team or programmers, so I’ll take that as being successful.


A good PID loop is definite your friend when coding up a shooter. You want the ball to come out at a consistent speed. Depending on the through put of game pieces really changes how fast you speed needs to recover. 2016, one game piece made it not very critical. 2017 was a different beast all together.

I’ve been part of a team that’s done some beautiful math to calculate the trajectory of balls. I’ve also been part of a team that said, “Screw it, if you shoot fast enough, it basically shoots in a line anyways”. Same team, same results either way.

I suggest doing the math, then adjust based on the real world. No mechanism is going to be perfect, but often factors like gravity don’t change. The biggest thing that changes is you flywheel friction, so clean those wheel after every match if possible.

When to Shoot
Now… ok, now…now? When does the robot shoot? Is this determined by vision processing? a driver camera? A flashlight? (Last one is legit) Know going in how you are going to be aiming this thing. Whatever you choose, any done poorly is not going to be beneficial. Know when to keep coding, and when to bail for more driver practice.

Ultimately, FRC is a cycle game. More cycles, the better. In programming, you need to find what will speed up your robot the most. In 2016, we had the biggest speed improvement by stringing together the auto-aiming, shooter speed up, and shooting into one command. So the driver had less to focus on.


That depends entirely on the type of target. A boiler or basketball hoop is a much harder target to hit than a vertical hole/slot, which can have a “sweet spot” of angle/speed. On the one you need an accurate lob, on the other you can either do a finesse shot or just brick it depending on the circumstances.

Either way, from what I’ve seen, good, reliable, fast shooters need: (a) LOTS of power, (b) a good amount of flywheel mass, and © well-tuned PID. If you’re only allowed to carry/shoot one thing at a time, you can probably skip the flywheel.

Definitely can. The easiest way is to select the data, right click, and on the insert tab, pick one of the charts. For plotting variable against variable, use the “scatter” chart with lines or curves.

For a flywheel especially, if you’re going to do your own control loop (as opposed to an SRX or other smart controller), bang-bang spins up faster and works quite well. Just turn the motor on full speed if it’s too slow, and turn it off if it’s too fast. Be sure to leave a few RPM which is “just right” where you leave the motor in the state it was already in.

To levelset: As others have mentioned, the software tends to be the lesser of the concerns - As long as you can get your shooter wheel to the correct speed, mechanical design and construction are much more impactful then manipulating shooter wheel voltage command.

That being said…

In my opinion, after living through 2016 and 2017: PID is overkill for most shooter applications. Bang-Bang or take-back-half are better suited for the task. This blog post has examples of PID and bang-bang on the same shooter wheel - bang bang running at 20ms is almost as good as PID, with a heck of a lot less programming/math/tuning. Not that you can’t make it work with PID, but I think you may end up with more work than you needed.

The conclusion is correct though - the ultimate goal of any shooter is to cause the ball to exit with a consent velocity (both horizontal and vertical) and with a consistent spin. Having a control algorithm which consistently imparts this energy to the ball is part of it, but robustness of the mechanical things around that control algorithm is also key.

The biggest takeaway that I recall from 2016 and 2017 back-to-back: compression is necessary. I recall people talking 20% to 30% being ideal, though I don’t have a source for that one. In 2016, the game-piece itself was squishy. In 2017, the shooter wheel or the backplate or some other part of the shooting mechanism was squishy.

On the topic of 2017:
254 has some good details on their custom shooter controls design for 2017. Team Titanium also had the unique (but totally not unreasonable) choice of using five 775 pro motors:
Anyway. Less of “Stuff you need to know for sure right now”, and more of “unique permutations to keep in mind, in case 2020 end up being similar to 2017”.

Bang bang control is really just a P controller with an infinite gain and command limits 0-1. Any positive error is multiplied by “infinity” then limited to 1. Any negative error becomes “negative infinity”, which is then limited to 0. For mechanisms that have a large MoI compared to the forces applied (like a flywheel), the controller would have relatively high PID gains anyway, so just setting them to infinity is a “good enough” and much easier solution.

For the record I agree PID is probably overkill for most flywheel shooters. At most you probably want a PI controller, but P, bang-back, or take back half are all reasonable alternatives.

1 Like

Absolutely! Very important point.

1 Like

I would strongly recommend against a PID controller for flywheel speed. Using an integral term will make your flywheel get to the right speed, but it will also overshoot. Using a derivative term can help prevent overshoot, but in the end it will just slow down your spin up time. A proportional controller with a feedforward will work very well - it spins up quickly and reaches the target speed with little to no overshoot.

For certain assumptions of how the I term is implemented, and what the shooter system looks like, these are true statements. I think they apply to the vast majority of shooters…

But, it should be noted that constructing an exotic mechanism or unique (a la 2017) requirements may cause the statements to become less true.

Also, I’m being sloppy in my terminology: whenever I say “PID”, I am referring to “a tunable controller that assembles a motor command from the error, its derivative, its integral, and some arbitrary feed-forward term, each tuned by a multiplicative constant”. I’m not saying that any particular tuning term ought to be zero or non-zero - knowing that requires more knowledge of the exact situation.

1 Like

I’ve seen videos of teams using this in Stronghold. How do you program it to turn on/off?

You could put a servo pushing the switch off and on! :stuck_out_tongue:
Serioiusly, usually these are controlled with relays if you need more current than a PCM port can provide. (The flashlight will need to be modded a bit to bypass the battery and switch, but it’s not difficult.)

Added: and unless you can convince the robot inspector that the flashlight is a computing device or self-contained camera, its internal batteries would likely be illegal.

What about AM’s targeting light? (we haven’t gone through our complete inventory yet, but mentor recalls owning it)

Sorry to hijack my own thread, but I am not interested in using a flashlight instead of a limelight-like device