Design Shooter

Hi, my team and I want to be better with our shooters and we want to ask, what do you think are the most important things on design to make a shooter.


The feed to the shooter. If that’s not consistent, your shooter isn’t worth much because the shots will go all over the place. In other words, how you get [game piece] from [storage] to [entrance to robot exit] needs to be consistent in how it does its job (exit location and velocity). Then the shooter can be tuned such that when the feed is consistent the shot is consistent,

Want to test what I’m saying? Here’s a test you can do. Build a flywheel shooter, but don’t supply it with a feed mechanism. When you load a ball in by hand, barely move it towards the entrance (slow velocity). Then, after a few shots like that, try a few where you’re almost throwing the ball in. Compare the two and see how different they are.

Now, with that being said, the answer generally depends on what you’re shooting and how you’re shooting it. Some amount of compression is going to be important for flywheel shooters, but not all that important for a catapult, for instance. Compression is different for 2017 fuel, 2016 boulders, 2019 cargo, and 2020 power cells, despite 2016 and 2020 being similarly constructed and all of them being spherical.

  • Reliability—a broken shooter scores no points.
  • Repeatability—a shooter that hits 95% from 5’ away is likely way more valuable than one that hits 75% from 15’ away.
    ** Stability—does taking a shot change where you are aimed
    ** Speed Control—taking a shot will change your mechanism’s speed, how do you insure it is back at the desired speed
    ** Same Path—does every shot take the exact same path through your mechanism or is there room for it to move around and are all your contact wheels perfectly round, etc
  • Speed—speed comes last. Analyze your cycle times. Is your shooter really where you can make the most improvement? Or should you be spending your time elsewhere?

I’ll second what EricH said about the feed for the shooter being critical. With a proper feed mechanism, you can make a flywheel shooter consistent and accurate. For a slightly different take on this, you might want to watch this video from Adam Savage on modifying a Nerf gun to shoot a lot of small foam balls. It’s more useful than it first seems, since the mechanism of the gun is a two flywheel shooter and it has a very clever feed mechanism that does the job of getting the balls to the flywheels very efficiently and perfectly regulated. It’s an useful take on shooter design.


love this video, but misleading to say that it does a good job of efficiently feeding the shooter itself. In his demo you can see him manually agitating the entire mechanism every few shots. Something a lot of poorly fed/indexed FRC shooters have to do often. Ever rock your robot back and forth if the shooter isn’t feeding consistently? That specific mechanism just doesn’t scale up with hopper capacity just like in FRC.

Lots of good principles in the video, and I do recommend watching it. However making the shooter is only 1/2(or even 1/3) of the equation. Serialization/indexing is arguably just as important. Obviously payload dependent but something that a lot of teams, my own teams included, often overlook.

Flywheel shooters are a pretty well solved problem at this point, just requiring some game/payload dependent tweaks like compression, motor power, linear speed, etc.
I think the average FRC team is just barely scratching the surface of good feed mechanisms. Tons of different, but very effective solutions in 2020, but even just 3 years ago in 2017 a lot of teams struggled with feeding their shooters well. Extra features in shooters like offset flywheels, accelerator wheels, etc are cool to do, but only augment the entire system as a whole, feed mechanism included.

I’m rambling at this point but this is in agreement with the rest of the posts above. Study posts from 2020, 17, 16, and even as far back as 12, 09, and 06 to learn from the wealth of knowledge on shooters, but realize that a lot of shooter design comes from prototyping and how the rest of the ball path interacts with the game piece.

To quote Akin’s Laws of Spacecraft Design:

  1. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
  1. Copy a design from the past that works well that you think your team can build
  2. Limit the locations where you will shoot from and optimize your shooter’s performance to those locations.
    The three shooting locations I’d concentrate on first are:
  • Initiation line in front of power port. (Try for a three inner shots and move off the line auto)
  • End of trench close to power port (protected)
  • Target zone in front of power port(protected)

Refine your design to get faster (cycle times) and more accurate (inner goals). Repeat. Repeat. Repeat.

1 Like

The trick to making any good design is iteration. For our shooter, it took us 3 iterations to get it right, but when we got it right, it was one of the best (in my humble opinion). The most important parts of a shooter in FIRST are reliability and consistency. You want your design to be bulletproof, and to be able to take a decent amount of abuse because that’s just the nature of FIRST as an environment. Repeatability is also key, as a shooter that can consistently make shots from an okay distance is much more effective than a shooter that only makes one in ten shots from across the field.

Our shooter uses two NEOs geared 1:1 to shoot from pretty much the quarter of the field where the goal is. We geared 1:1 because while going higher would allow us to lob from across the field, having the torque provided from a 1:1 versus gearing up was beneficial to us because it allowed an almost A-10 Warthog level of BRRRRT, letting us drain 5 balls into the center hole in 2 seconds from about 20 feet at most.

If you have more questions, let me know through DM or a reply. I’m happy to help with shooter design, as it’s something I’ve spent a lot of time on.

here are some pictures:

(I’d make a good hand model :thinking:)


All of the advice you have gotten so far is good, but most of it is not related to the actual shooter mechanism (not that that makes it less important). When making a shooter there are a few really important variables that you can control. The best way to determine how your shooter should be made is by testing each variable and recording how well it shoots.

Compression is how much smaller the distance from your flywheel to your hood is than the game piece. In 2020 I believe most teams ran somewhere between 1.5 and 2.5 inches of compression.

Wheel size
This is the diameter of your wheel, bigger wheels have a higher speed at the contact point with the game piece than a smaller wheel (for a given RPM). Larger wheels also require larger hoods, which can be a good thing or a bad thing.

Hood length
This is the arc distance the game piece travels when it is in contact with your shooter wheel. Larger arc lengths can be harder to package or harder to manufacture, but generally lead to more consistent shots.

Wheel speed
This is going to be specific to your team and your shooter. Wheel speeds can vary from around 4,000RPM to up to 10,000RPM. Once you have determined the best combination of the other variables you can tune your wheel speed to get shots you like.

Those are a few of the main variables you need to consider when making a shooter. Like other have said the feed and indexing is equally important and usually harder to get right so a simple shooter that allows you to spend more time on feed and indexing is a good plan.


Experimentation is the most important thing.

It’s really tough to design for squish, feeder mechanism variation, air resistance, battery load, etc. all at once and get it right using only paper and pencil. Be prepared to do lots of iteration.

Design your prototypes to be reasonably adjustable. Don’t compromise rigidity, but you’ll be much better off if you can quickly adjust backing material, squish percentage, etc.

While we’re far from the most efficient team when it comes to how we spend our time… We did still devote at least 3 students to spend almost four full weeks to shooter and feeder prototyping this past year. It paid off reasonably well.

As you’ve probably done, try to reference common things that show up in lots of shooters from similar year (motor count? flywheel design? gearing? materials? squish percentage?)

Software has a relatively small impact. Bang-Bang controllers will usually get you by. PID (with feed forward) is also valid. State-space and beyond are also valid.

In theory, if you can avoid ever “railing” the motor command at full blast while you’re in contact with the ball, that should be more consistent (as a “railed” motor is actually now being limited by battery power, which can vary substantially depending on battery state of charge). However, for most teams and years, this would have a much smaller contribution to consistency than other factors.

As a software optimization, we will often switch between different pieces of control logic depending on our goal at the time. Different goals might be “spool up as fast as possible”, “maintain this speed precisely”, “put X specific energy into the ball”, etc. It’s probably overkill, but was a relatively low-effort way to shave a few seconds off of the cycle times.

Overall: Keep in mind the solution space is very large and there are lots of local minimia… ie, there’s lots of very good solutions. Also, lots of tiny tweaks that take a very good solution and make it very bad.


And it’s pretty easy to analyze why he has to shake it: the agitators that move the balls down from the magazine are insufficient (too small) for the job. The belt feed that brings them to the flywheels, however, provides exactly the right kind of consistent feed that you want to have. This is what I was talking about when I said it was a useful take on shooter design.

1 Like

Also depends on wheel size. We’ve had setpoints down in the 500’s for big wheels.


This is a great list of variables. Here are a couple of additional thoughts.

(1) Shooter-type. The “hood” shooter was very popular for Infinite Recharge, but there were other types seen (two-wheel, for example).

(2) Mass. This is an area we spent some time experimenting with (as did other teams). The mass of your shooting wheels affects its inertia, which affects

  1. The time and power required to get up to initially speed, and
  2. The amount of speed lost with a shoot (and hence the recovery time to get back to your desired speed).

(3) Adjustability/Aimability Is it worth your time to add stuff like a turret and/or a variable hood geometry OR is aiming with the robot and/or adjusting distance with motor speed sufficient? How do you aim your shooter? Are you using a vision system for setting angle, angle & distance, or not?

[EDIT] (4) Material choice. Changing the plastic used for the arc of the hood made a surprising difference for us, so…

…as others have said: experiment and prototype. And as Adam Savage says “The difference between screwing around and science [and engineering] is writing it down.”

[EDIT 2] You don’t need to start from scratch, lots of teams share their experience. And so as Citrus Circuits says “Steal from the Best, Invent the Rest”. It is no surprise that successful teams often end up with similar designs. Compare our shooter to 6502’s above:

We went tall, but still lots of similarities.


It’s this thread again, oh boy.

This is important. Unless anyone shows me empirical numbers on the performance of a shooter varying only one variable at a time (and PLEASE DO), i’m not believing any “this much crush is the best” or “you NEED 4 Falcons”. Not even for our own designs. We need to be more rigorous ourselves.

I’d rather use theoretical models to understand important parameters than trying to make comparisons across the interwebs of launchers and testing methods that have little in common other than general form.

The holy grail would be to correlate that model with some empirical testing. Then we can really start talking sense.

On the meta side, I’ll be a bit more positive. Look at your game strategy and a trajectory analyzer (e.g. in conjunction. This can help you identify quickly “do I want a long shot, or a laserbeam”, which can decrease the number of variables you’re trying to iterate towards. In our case, we realized that if we want to shoot full court, a shot that flattens out right as it hits the goal gives us flexibility in positioning without the need for complex software and vision control.


Fwiw, if your target rpm is ~5000, it’s often better to have an overdrive on the motors (aka an “upduction”), so that when you’re spinning back up after a shot your motor’s at peak power, which gives you net more torque

1 Like

In theory, I agree. In practice, we had a devil of a time accurately figuring out the friction force on a squashed ball.


Back when I was coaching my two son’s FLL team, we came up with the phrase “copying without understanding is fatal”. We saw a lot of other teams “copy” their designs but we could see that those copies were missing crucial elements because the team building those copies only took a superficial look at my son’s mechanisms and did not study them in depth. The more successful copies were made by teams who stopped by their pit and asked a lot of questions about the mechanism they wanted to copy. Conversely, my sons always spent a lot of time and effort studying any mechanism that they wanted to emulate and were able to execute them successfully.

I have found that this is true in robotics (FLL and FRC) as well as in my day job (electronic circuit design).

Quality of execution is also very important. At competitions, one can see many examples of X, many of them looking very similar but only a few perform well.

I recall quite a few instances where, at the end of a long day of testing, the team members (including mentors) would say, “We tried all sorts of different combinations of settings of X, Y and Z and had a really good result just after lunch. We tried to improve it some more but now it is worse and we can’t remember what the best settings were.” Heartbreaking…


A reduction would give you more torque. “Upduction” gives you more angular velocity.

1 Like

Sure, assuming the same input power and input RPM, but the idea here is that you gear your motor such that when idling at your target speed, the motor is running at only about 1/2-3/4 of its free speed, so that when your wheel velocity drops, you can increase voltage to 12v and have the benefit of the motor already being at an RPM where it’s near peak power (meaning net greater output torque), whereas if your motor is idling at its free speed, when the velocity drops due to a ball coming through you’re not going to have very much power available unless you somehow drop ~2500rpm, since it’s near the edge of the power curve

1 Like

The biggest effect on RPM drop is compression, which we had a pretty decent amount of.

we ended up about where the arrow points on the NEO motor performance curve, which is pretty much as good as you could hope for.

I’ll reiterate what I said above (no pun intended) Doing a ton of math isn’t going to get you as far as just experimentation and iteration in FRC. Unless you’re really really good at MATLAB, you’re just going to have to build prototypes and see what works for you. I’m really happy with the performance of our shooter, being able to sink 5 shots into the middle circle in 3 seconds, but hey, you might not be.

1 Like

Friction is and will always remain in the realm of empirical testing… hence why in those models, mu is mu, a magical parameter. Models only tell you what parameters are important, they don’t tell you how to achieve those parameters.

To highlight my main point, consider this totally made up statement:

“We switched from 4” hiGrips to 4" stealth wheels, changing nothing else about our shooter. We took 50 shots from 30 feet with each configuration, and found that our point of impact raised 4 inches on average, and the standard deviation decreased by 1.5 inches. Find our dataset attached in .csv format."

This singular statement is more useful than the compound sum of the conjecture-posting that comes around with this topic. If you want to figure out key parameters, you have to boil things down to key parameters, get data, and write it down.

Something to chew on (and maybe an action item for myself): in Formula SAE, tire testing is hard to come by. It’s expensive. But getting tire data is very helpful in informing design decisions. The “tire test consortium” formed, which gave teams access to test data that was performed on expensive machines. Now, in FRC, the limiting factor definitely isn’t fancy equipment… it’s time. Maybe a “flywheel test consortium” would be in order :slight_smile: