Design Process: 2012 Shooters

Originally posted here:

As most people know, I was not involved in FIRST this year. I went to FRC Championship in St Louis, and to IRI.

One of the things that interested me most about this season was the wide variety of robot shooter systems. This seemed to be one of the more difficult design challenges of the year, as most teams were unable to produce shooters capable of high accuracy and high precision shots. I was surprised by how hard it seemed to be to repeatably hit 3-point shots from the key.

I know there were a number of factors that caused this to be a difficult design challenge; one requiring significant tuning to ensure performance.

I was inspired by this thread:

I’m curious not just where teams ended up, but their journey there.

Which brings us to my question:
What details can you provide about the design process for your shooter subsystem?

I am hoping that some teams out there will have documented their process a bit and can provide in-depth answers…

  • What iterations did you go through?
  • What features did you tune in during the evolution of your design?
  • Which system variables were most important to performance?
  • What did you prototype? How detailed were your prototypes?
  • What did you start with? Why – what inspired this baseline?

The process that goes into the engineering of these robots is as interesting to me as the robots themselves (or maybe more so).

Obviously I’m interested more in the successful systems, but welcome any responses.
So let’s hear it!

For our shooter this year we made a one axle, two wheel shooter. One major change we made between a regional and championships was we changed from one large wheel to two smaller wheels, which seemed to provide more accuracy. We used a CIM motor to power the wheels. We also used PVC wood to make a compression guide, which was basically two curved pieces that the ball would go through. One problem we had was the ball would shoot before the shooter wheels were up to full speed, so we put on a vex kit wheel to stop the ball before it got to the shooter wheels. During matches the balls would picked up and be stopped at the top by the VEX wheel, which was very effective. I’ll try to find a picture to add to this post later.

Do you have any more details on the engineering process that went into its creation? Did you use any formal process?

You mentioned two iterations (change in wheel type / qty, and addition of a feeder wheel) – were there any others?

Early Design Process

The first thing that we did (on Sunday after kickoff) was to determine a high-level game strategy, completely independent of any thought about mechanisms or implementation details. From our game simulation and subsequent discussion, we determined that we wanted our robot to have the following capabilities (I am summarizing the results; in actuality these were determined from weighted objective tables on a more continuous reward scale than “Required” or “Desired”):

Requirement - Accurate shooting from any part of the key
Desired - Accurate shooting from beyond the key up to the Coopertition Bridge
Requirement - Able to shoot 3 balls in under 6 seconds (speed and volume are key!)
Requirement - Able to shoot first ball in under 2 seconds from start of Hybrid Mode (we recognized on Day 1 that we wanted to be able to shoot 4+ balls in hybrid)
Desired - Completely, 100% autonomous shooting. We want to be able to have the same accuracy regardless of who is driving, whether or not they are nervous, etc.

After establishing these baseline criteria, we began to talk about big-picture mechanical design. The discussion of pitching wheel vs. catapult vs. other shooting methods was one of the first things we decided. Based on our experience with our 2006 Aim High shooter (which had a shot grouping of less than 2" on average), and our completion of more weighted objective tables, it was decided fairly unanimously that a wheeled shooter would be our “Plan A”.

Two questions immediately cropped up:

  1. Do we need a turret?
  2. Do we need an articulated hood or other launch angle controls, or is wheel speed control enough?

A great discussion ensued, and most of the team (but not all) adopted the belief that because of the protection of the key, a turret was a luxury and not a requirement. The dissenting team members did agree that we should first build a non-turreted shooter, and could probably add a turret (as weight and time allows) at a later time if we are unsatisfied. As it turned out, neither weight nor time allowed, and we were pretty satisfied with the non-turreted shooter.

On the topic of hood/launch angle articulation, we again erred on the side of simplicity. Those of us (mentors and college students) who remembered 2006 knew that shooters were generally highly sensitive to variation in ANYTHING (angle, compression, ball entry, ball type, wheel spacing, vibration, etc). A simple shooter is one that is easier to tune, usually more robust, and less likely to get “out of tune”. We again decided to first aim for a non-articulated hood, with the option of adding complexity if we felt it was necessary.

At this point, it was time to go into detailed design and prototyping, and as a team we decided that the shooter system was the single highest priority for the team - the intake, barrier and bridge crossing, balancing, and ball sorting mechanisms were secondary to being able to shoot (only the drive was more important, but this was low risk for us and required no prototyping).

Detailed Design and Prototyping

In choosing a starting point and prototyping configurations, one interesting point of discussion cropped up:

  • Those of us who haven’t played a lot of basketball insisted that shooting for “nothing but net” was the smartest bet - you have more area to hit on the downward arc of a lob shot!
  • Those of us who had a strong basketball background believed that “the backboard is your friend”, and that it is the best bet to make shots!

Two things convinced us that the latter group was “right”:

  1. We found this article:
  2. We found that with our 2006 Aim High robot, backboard shots were a lot more reliable - the ball had traveled less distance than with a high lob, so angular errors were less significant. That, and the robot put a lot more backspin on the ball than a human shooter could, which seemed to help significantly.

At this point, we enumerated the variables at our disposal in the design of a shooter system:

  1. Single or Dual axle shooter
  2. Wheel size
  3. of wheels per axle (1 or 2)

  4. Wheel tread/material
  5. Wheel speed
  6. Motor allocation
  7. Launch angle
  8. Compression
  9. Hood/Top axle profile and material
  10. Ball entry force/speed

Obviously, there is an enormous number of combinations here. So we decided to start from a point that represented our best intuitive and scientific understanding of what we thought would shoot best (along with options that were favorable from a weight and complexity standpoint, with the logic that a good, simple shooter is decidedly better than a good, complex shooter).

Our initial prototypes were designed as follows:

  1. Single axle (simpler/lighter, and we saw plenty of effective single axle shooters in 06 and 09)
  2. Fairly small wheels (6" diameter) (smaller wheels are lighter, more compact, and spin up more quickly than larger wheels)
  3. 2 wheels on our single axle (we believed that having two contact points helps to center the ball)
  4. Wheels were rubber Skyway wheels from a past KOP (They are very light, cheap, and abundant in our shop)
  5. Wheel speed was an independent variable tested with a hand drill (initial calculations suggested ~4000 rpm was a good target for mid-key shooting, which was pretty close to what it ended up being)
  6. Our initial thought was to devote 2 0673 Fisher Price motors to the shooter, since it let us keep CIMs in the drivetrain while devoting a ton of power to shooter acceleration.
  7. Launch angle was another independent variable. Our prototypes were simply adjusted to aim higher or lower as necessary.
  8. We initially tried about 1" of ball compression as a guess based on 2006 poof balls. Our later prototypes let us adjust the hood to test different amounts of compression.
  9. Initially, we tried a flat hood made out of bent lexan that kept constant compression on the ball.
  10. Ball entry for initial prototypes was by hand, so we could test and observe the effect of different entry velocities (but struggled to feed the ball consistently).

We build about 20 different variations of prototypes (most of which were simply adjustments to a single prototype) using mostly wood and hand tools. Very early, it was clear that our 6" wheels, single hood, and ~4000-5000 rpm shooting parameters could hit our distance and arc targets from the front of the key (but weren’t consistently getting the necessary distance from the back of the key and beyond). However, we figured that we would get +20% more distance from a finished, well-toleranced shooter.

Our initial prototypes:

Accuracy and consistency of our initial prototypes were mediocre. We were making 60% of our shots from the key by the end of week 2, which was still quite poor by our expectations (we wanted 90%+). At this point, we completely re-built the prototype shooter to be more robust, and our numbers started climbing higher.

There are too many things we tweaked to enumerate them all, but here are some of them:

  • We tried different wheels (but found that roughtop and KOP wheels shredded balls), but kept coming back to Skyways
  • We found that hood design was HUGELY important to consistency. Early hoods were very flimsy and would deflect with each shot. We added ribs to attempt to stiffen them, and these helped somewhat, but you could still see the deflection with a naked eye quite easily.
  • Compression and wheel spacing between our two shooting wheels were both varied quite a bit. Eventually we settled on ~2" of compression (between the nearest points of our shooter wheels and the hood).
  • We also experimented with contact time/angle and found that the longer the ball was in contact with the wheel, the more energy would be transferred. But we were still pretty happy with the distance we were getting with ~45 degrees of wrap.

Lastly, near the end of our prototyping time we saw this video on youtube, and then started to think about “guides” in our hood to help keep the ball centered:

We thought that was a great idea, and decided it would be something to try with our first attempt at a “final” mechanism.

First Design Candidate

We all knew from prototyping that tolerances and rigidness were extremely important in our shooter. Our team has a limited number of ways of hitting these design goals. One of them is the benchtop laser engraver/cutter at my work, which can cut most plastics but not metals. We designed a pair of sideplates and two “rails” for our shooter (inspired by 1726) to be cut out of .25" black Delrin.

The next day I brought the finished parts in to the school and we quickly mounted them to the tower (using that Hex extrusion that comes in the KOP as part of the Kitbot for standoffs). Initial accuracy was pretty good. We took the guide rails and ground them down on a belt sander until the launch angle was just right, and haven’t looked back since. Compression, the hood, and wheel configuration have not changed since week 4 of build.

The last two weeks of build consisted of a lot of vision system tuning and control system design for good speed control of the shooter wheel. Intuitively, we decided that using a Jaguar speed controller and 200Hz PID loop (the max Jaguar update speed) would give us the best results for our feedback control. Since we knew we were going to be running a 200Hz loop, we wanted accurate, stable speed feedback at least once every 1/200 of a second. Using a banner sensor and timing the duration between pulses (with two pulses - reflective strips - per shooter revolution), we achieved roughly this level of accuracy. The speed loop itself was very quick to write - it is simple PID with a very high proportional gain (pretty close to a “bang-bang” controller). Note that we discovered a need to power our Banner sensor from a 24V solenoid output at this time, since it would sometimes brown out otherwise.

First Competition

Week 1, Hatboro-Horsham District Competition (the very first MAR event)

On Thursday night before the event began, we had an opportunity to go out on the practice field for several rounds. It was immediately obvious that we were overshooting every ball (right over the backboard!) - apparently the balls directly from Gopher (that we were using for testing) are SIGNIFICANTLY softer than the FIRST-logo balls. Luckily, we were able to tune the speed setpoints pretty easily in our SmartDashboard software, and by Friday morning we were ready to go. We went 17-0-1 and won the competition.

Boston Regional

In Week 2 at Chestnut Hill, we duplicated our Week 1 effort and again won the event with a record of 16-2-0. However, at our next event at the Boston Regional, things started to go downhill.

All of sudden, we were undershooting the majority (but not all) of our balls. I tried turning up our speed setpoints, but it wasn’t helping. At the same time, we noticed our rate of fire (software controlled - it will not shoot until the wheel is back up to speed) had increased. After a few rounds of terrible shooting accuracy, it dawned on us (it should have been obvious earlier!): we were experiencing wheel slip issues. Our Skyway wheels had been worn by so many shots already that they had become slippery. Luckily our pit neighbors, The Pink Team, had some silicone-based grip tape that they lent us. After applying to our shooter wheels, our accuracy was better than ever, and we went on to win the event (with 233!).

On to the Championship and Beyond

At MAR Championship, our new and improved shooter continued to be a workhorse, and it carried us to the #1 seed and the win for the fourth time of the season. At the World Championship, we likewise shot well for most of the competition. There was one qualification round where our “tower” motor (that runs the elevator that feeds into the shooter) had stalled for several seconds in hybrid mode due to a ball jam, and after that we were undershooting significantly. We swapped out the motor and were good to go.

However, in eliminations, we noticed that we were again not shooting well. I believe that the balls used in eliminations at the Championship felt different than any others we had used all season long, even if they were from the same “batch”. We were not the only team to complain of this. Additionally, we found that our silicone tape had started to wear down and was no longer gripping the balls as well as before. I misplaced our timeout ticket (and am still kicking myself for it), so we weren’t able to do the repair completely and lost all of the tape in the Finals. We knew our margin for error against a superb 233-987-207 alliance would be slim, and they made us pay!

At IRI, we had replaced the tape and shot well all day, coming in #1 seed and ending up with an OPR 11 points higher than anyone else (!). But once again, a combination of machine problems (mostly with other parts of the robot), bad luck balancing, and unforgiving opponents knocked us out. But we can hang our heads high!

Takeaways and Conclusions

We “guessed right” on many aspects of our shooter this year, which meant it took fewer iterations to get to an acceptable solution than it could have otherwise, and our acceptable solution was very simple and fairly light weight. That was huge. Study of past robots and past FRC games was instrumental to our success.

When prototyping, it is sometimes difficult to figure out if deficiencies of a particular design are limitations to the design, or problems caused by the implementation (in this case a flimsy prototype). Knowing the difference takes experience, targeted experimentation, and, sometimes, building better prototypes.

Lastly, winning (especially at Championships and IRI) has as much to do with “who’s left” as it does “who’s the best”. Designing certain parts of our robot for easier repair would have been very useful. You are VERY rushed during eliminations at both the Championship and IRI!


I was hoping someone from 341 would take my bait.

Thanks for the detailed description of your process. I’m sure most people (at least those who aren’t dumb) would rank your team’s shooter near the top of the list this season, and I’m equally sure many will benefit from hearing about your journey.

Thanks again for sharing!

We decided that we needed to be able to shoot from the key to eliminate any defense while in the process of shooting.

We quickly re-assembled our lunacy shooter which we were able to use for testing with little modifications. It became quickly apparent to us that because of the variability in ball density that we were not going to be able to achieve the accuracy we desired by using a wheeled shooter. We started doing different prototypes of ways to shoot the ball. My favorite was what we called pop-the -collar where we wound up a bolt of fabric on a pulley attached to a drill to shoot the ball, this idea was quickly discarded. We actually found that just using a flat stick was a very effective way to accurately throw the ball. We started prototyping ways of doing it when………
I was doing seasonal work at AndyMark and I was having daily discussions about the problem with Mark. Team 3940 had come to the same conclusion as us by doing their own testing. Mark came up with the idea of putting the flat stick on a carriage and running it around a track like a roller coaster and the fling-a-pult was born.

3940 gave us the drawings for their plans and we set off to work. After seeing the initial testing of 3940’s shooter we made a couple modifications but these were mostly to aid in our manufacturing process and to try and lighten the shooter a bit. The mechanism worked so well that the tuning required was minimal. We actually made the first shots we tried with the assembled test robot.

What separated our robot from the other fling-a-pults was how we fed the balls into the shooter and where the shooter was located. We originally planned for a turret but scrapped the idea to save time and complexity, because of that we decided that we wanted the shooter to be in the center of the robot. This would allow us to turn the robot to aim the shooter while keeping the shooter and camera rotating on the same axis while turning. We also decided to load ours from behind the shooter instead of from the side to make feeding the balls easier without having to make the balls change direction while being moved inside the robot.

The only feature of the shooter that had much iteration were the actual shooter fingers themselves. We tried many types that mostly varied in how they cradled the ball and how long the fingers were to change the amount of spin imparted on the ball.

Our original robot design had three different positions for the shooter angle to give us different shot types. During testing we decided that this wasn’t necessary and settled on two positions, one for the key and one from shooting from the bridge. I don’t believe we ever used the long shot position in actual competition to make a shot but it was handy in helping with ball miss feeds.

I’ll try and post a few picks and videos later.

W pretty much just used a lot of trial and error, by trying to find the right combination of variable (i.e. length of guides, shooter wheel speed, etc.) and came out with our final design after our second regional.

Here is a video of one of our prototypes,, and there is also a thread posted by Flak-bait here on CD which has more discussion on our shooter.

Like most teams this season, we spent a majority of our build season developing and iterating our shooter. After weighing the pros/cons of catapults, shooter wheels, slingshots, etc.; we made a firm decision to go with a shooter wheel for scoring.

Concept/Initial Design:

We leveraged experience from 2006 to know we did not want a 2 wheeled shooter (meaning oppositely driven wheels on either side of a ball). We felt it would be mechanically simpler to go with a single wheeled system and could potentially provide a more repeatable system. One of the large benefits of a 2 wheeled system is the ability to get a lot of distance on a shot. For us, our strategy did not revolve around being able to score from a large distance away (ie: half field +). That helped nullify some of the benefits of a 2 wheel.

Right away we began prototyping. Our 2009 robot utilized a single wheeled, hooded shooter on a turret- how convenient. That was the first prototype we used. The lunacy balls were larger in diameter, and required very little compression because we did not fire them all that far. After a few tweaks, we had our first shots out of the 2009 robot and learned a lot instantly:
- Balls fed at different rates into the shooter went different distances.
- We needed a considerable amount more compression than initially thought (first guess was approximately 20% of the ball’s diameter).
- Our 2009 shooter wheel (6" in diameter) was spinning far too slow to get the distance we required.

Our game strategy set our design goal for shooter distance to be approximately 3 feet past the outer diameter of the key. So if you drew an offset arc 3 feet away from the edge of the key, we wanted to make shots within that arc. With that metric, we were able to start solidifying design criteria for the design team.

We jumped right into our next shooter prototype. This time we wanted to start nailing down some specifics:
- Compression of the ball.
- Diameter versus rotational speed of the shooter wheel.
- A rough guess on angle for both fender shots and key shots

This next prototype allowed us to insert different shooter wheels, change the compression in the hood in 1/4" increments and of course adjust the speed the wheel spun at. We tried wheels varying in size from 4" up to 10". Using a variety of motorized devices ranging from a CIM motor, to a corded drill we varied the speed with each wheel size and compression number. We measured wheel speed using a strobe tachometer. The “money zone” seemed to be following combination:
- 2.0" ball compression
- 6.0" diameter shooter wheel - with a concave to center the ball as it came through the shooter
- 4000 RPM

We also came to the conclusion that backspin was key. It allowed shots to bank off the backboard and drive into the hoop. This was something our 2009 robot prototype proved quite well.

With these fundamental specs laid out, the design team took off and got down to work. The prototyping team continued to work and iron out some more of the specs, but the initial concept was secured.

Design Phase I - Hardware/Mechanical

Based on a team philosophy, we like to overdesign fundamental subsystems. We knew our CIM motors were going to be utilized in the drive system as usual. We also had sworn off the use of Banebot 775 motors in the off-season after incredibly devastating results using them in the 2011 season. This left us with only a few motor choices. The 0673 Fisher Price motors, or the RS 550s. Conveniently, these have very similar free speeds, and identical form factors, so we could begin designing the gearbox knowing it would be one of those two choices in the final design.

We geared our shooter to peak efficiency of the FP motor curve (our leading choice because it was a higher power motor). We ended up with a clean 4:1 gear ratio in the gearbox. Knowing we may want to dial that down or up as the season went on and we refined our shooter, the last set of reduction was done with a belt/pulley. This was able to be tweaked to finely dial in our shooter speed after the gearbox was assembled. Doing this also let us put our gearbox in front of the shooter wheel to help slim down the shooter.

As the detailed design progressed on the shooter, the prototype team continued. We tried to answer a few more questions:
- Weight of the shooter wheel vs. ball shot consistency
- Width of the shooter wheel vs. ball shot consistency
- Material of the shooter wheel
- Material of the shooter “hood”

We found that a heavier wheel did provide a noticeable increase in consistency. With this came the tradeoff of a longer spinup time. We felt the spin up time was a tradeoff that could be handled and decided to go for a shooter in the 3 lb. neighborhood.

We also noticed that a wider shooter wheel wasn’t necessarily better than a skinnier one. However, making a wider shooter wheel with a concave in it, did improve consistency. The thought is that the ball tends to be more centered on the wheel for each shot, thus reducing left/right inconsistency.

We had experience selection shooter wheel treads in our 2009 robot. We had a lot of issues picking the right material for that shooter wheel. Critical issues involved:
- The “right” amount of grip with the ball
- Adhesion of the tread to the quickly rotating wheel
- Lifetime of the tread material

Like most engineering problems, there was a tradeoff in these materials as well. The softer materials tended to not last as long, and because they gripped the ball better, also tended to pull off the wheel more.

Our 2009 robot utilized banebots wheels because of their urethane tread. While we would not use it for a drive application, the grip those wheels have on game pieces seems to be very good. We decided to step outside the box a bit, and make a 100% custom shooter wheel.

After trying several materials in the shooter hood, we decided upon an aluminum hood, mainly for its rigidity over polycarbonate in similar thicknesses.

Design Phase II - Finalized Detailed Design/Software Development

The ground work for the shooter was laid out already. We had our gearbox. We had found more 0673 FP motors. We just needed to fill in a few of the blanks.
- Adjustment of the secondary hood
- How to make our shooter wheel

We knew we wanted adjustment in our hood because we knew our initial game strategy called for making shots from both the fender and the key. While we did find an angle that worked for both shots universally, we felt it was impractical and inefficient for key shots. We also saw that an adjustable hood could allow us to focus on controlling just a single speed on the shooter, while adjusting the angle. Initially our software team thought the hood angle would be easier to control than a precise shooter speed. So with that, we decided to make an infinitely adjustable hood driven by a leadscrew. This turned out to be a poor decision (see below).

We knew the diameter, width, weight and approximate profile we wanted our shooter wheel to have. Nothing like it existed off the shelf, so we went ahead and set out for a custom design. We wanted the weight to be on rim of the wheel for more rotational inertia. Our prototypes had proven this lead to more consistent shots. We used a thick walled aluminum cylinder for the bulk of the wheel. We machined plastic endcaps from solid PVC stock. The final piece was the tread. For this we leaned on our experience with urethane molding. I 3D printed a mold (complete with ‘125’ logos in it) at work. The mold was in 3 pieces so we could pull the wheel out of the mold without an issue. The issue was the large concave in the wheel created a massive undercut around the entire diameter. If we id not make the mold separable, the wheel would probably be permanently stuck inside the mold.

As all of this happened- our software team began laying out the framework for their solution to controlling a spinning wheel. The used prototypes and old robots we had to come up with a plan. I do not want to misspeak, so I will bug our software lead to come on and post about the software development. As we all know, this was a huge part of the battle.

Design Refinement- Iteration/Software Development

We put the entire robot together in time for us to attend a scrimmage event in Suffield, CT. The robot performed well for the small amount of runtime and software development it had. As we do every year, we also learned a ton from the scrimmage.

The most critical from a mechanical point of view was that we had overestimated our need for a secondary hood adjustment. We were only shooting from 2 locations, and did not have a need for this large amount of adjustability. The leadscrew adjusting the hood was also a weak point in the design team’s mind. Too many things could go wrong with it, so we decided to move to a 2 position, pneumatic hood.

With the shooter fully built and the time to really work on refining it, we wanted to ensure our shooter speed was tuned; both in a top speed mechanical sense, and from a software point of view.

The fully built shooter was highly efficient compared to it’s less ideal prototype cousins. This meant, the shooter wheel speeds we initially geared for were actually too fast for our game strategy. Fender shots were only utilizing ~10% of the top speed, while key shots were in the ~50% range. We knew if we bumped that up to about 90%, we would gain a much wider range of adjustment and make our software team’s lives easier.

Building in the functionality to change the final gear ratio with a belt was awesome. We made the swap with minimal impact to the timeline, or overall design, and we didn’t look back all season. This is something we will most likely incorporate in fundamental subsystems moving forward.

An issue we experienced in the eliminations of the Boston Regional was slippage in our encoder we used for wheel speed feedback. The disc would consistently skip ticks which would result in the shooter pegging itself to max speed and us sending balls over the backboard.

For championships, we switched to an enclosed encoder which rode on an internal ball bearing. It was bullet proof, and we will use this style encoder in essential systems moving foward.

The software team developed a strong PID control system for our shooter wheel that provided consistent results throughout our competitions. We withheld our shooter system after ship to continue refining the control software. In the end, we had quite a bit of success with our shooter. It is extremely consistent, and resulted in very few mechanical issues over the season. The main reason being we ironed many of them out through prototyping, iteration and testing.


At the beginning of the build season, we (4183) decided that we wanted to build a robot that scored in the high basket from the key. To do so, we quickly decided to build a turreted one-wheeled shooter, since we believed it to be easier to tune and to have more backspin than a two-wheeled design. Also, some of our mentors had successfully used a similar shooter in 2009. We built a plywood prototype using a 4" PVC roller covered with a material similar to sandpaper, but with an adhesive backing. We used bent steel conduit as the hood. This shooter demonstrated that our general idea worked, but was not sufficiently powerful. Here’s a video of a test of the prototype:

We designed a shooter in Autodesk Inventor that used 8" wheels from the 2010 KoP. Since we weren’t sure what the best launch angle, we designed the shooter to allow conduit ball-guides of any shape. It is powered by 2 FP motors. Here is a (rather ugly) render:
We made two changes to this design. We cut off the tall triangular section at the top to reduce height and weight, and we eliminated most of the holes along the top and side, since they would take an obscenely large time to laser-cut. We did not finish our shooter during build season, so decided to keep it and attach it at the Utah Regional. We built a wood stand to mount it for testing. After watching videos from some early regionals, we decided that fender shooting would be much easier than key shooting, particularly because we were unable to develop computer vision. Fortunately, we were easily able to modify our shooter for a higher launch angle. We were surprised to find that we could still shoot from the key with the higher launch angle, a fact which we took advantage of in autonomous. Video of us testing shooter from “fender”:

Image of shooter:
Image of turret:
Few hardware modifications were made to the shooter during competition season. The shooter worked as expected, scoring ~75% from the fender in teleoperated and ~50% from the key in autonomous. Our lack of a good aiming system probably contributed to most of our misses.

We used a process very similar to what Jared described for 341 and came to very similar conclusions on the style of shooter. Single axle, double wheel, non-turretted, and fixed angle.

Because we were concerned with building too much complexity into our shooting system (ala 2006), we quickly decided that if we could shoot from the key, then we would not need an adjustable hood or a turrett.

Our decision point between key / fender shooting was determining how possible it was to shoot from the key. If we could achieve 90% or greater, the protection of the key was well worth it. If not, we would have to risk being defended getting to the fender.

We did not specifically determine any set requirements for how quickly we could shoot. Although, we obviously wanted to shoot as quickly and accurately as possible.

Prototype / Development:

I don’t have any pictures of our prototype available right now. Our website is down…hopefully I can link to them in the future. We quickly designed a sheet metal single axle prototype shooter to test our shooting accuracy. We didn’t really do any testing with double axle shooters. Just playing with the balls and knowing we wanted backspin pointed us towards a single axle shooter. We had a pretty decent approximation of a shooter for a prototype. It was mounted on a piece of plywood, so shooter testing could be conducted independantly of the rest of the robot development. It was powered by a CIM hooked up to a power source, so we could regulate the speed. It had 6" KOP wheels and was adjustable for the amount of compression we wanted. I believe we started with 1" of compression, but that resulted in quite a bit of slip when shooting at the speeds required for a key shot.

Using our prototype shooter, we tested for accuracy at different positions on the key, backboard v. “swish”, as well as different shooting angles. We found that at 45 degrees banking off the backboard, we had a rather large sweet spot on the key. Meaning we could be positioned within a couple of feet and still shoot a high percentage. We ended up proving that at ~4000 RPM, 45 degree shoot angle, and ~ 2" of compression, we could shoot at or above 90%. This gave us confidence that we were going down the right path.

One of the major findings we saw from our prototype shooter was that it was very sensitive to how the ball was feed/presented to the shooter wheels. Fed quickly, it would shoot too far. Fed slowly or if there was any resistance holding the ball, it would shoot short. Using this information, we were planning to design a paddle feed system (similar to FRC25-2006), but we could not get it to package without a significant amount of complexity. To design around the variation in the balls and allow for a consistent feeding method, we added in a short section of “gravity feed” between when the feed rollers release the ball and when the ball contact the shooter wheels. I believe that this was the key to our shooter being able to consistently shoot a high percentage.

Competition Shooter:

To develop the competition shooter, we needed to ensure that we could switch from the CIM on the prototype, to the FP or AndyMark motors that we had available from the kit. We wanted to use the FP673 motors, but we did not have enough to build two robots w/spares. So we opted for the AM-0912 motors. Based on the information from our prototype shooter, we selected a 2.52:1 gear ratio that resulted in the quickest spin up rate to 4000RPM and also gave us enough of a top speed RPM to shoot from the top of the key. We briefly discussed changing to a 4" wheel for packaging, but we decided against it based on too much change, complexity, and unknowns with a wheel that small.

The competition shooter used the provided 6" KOP wheels, with the nubs turned down, to eliminate ball damage. There was no real testing or decision making process for selecting these wheels. We had them, they were available, and they worked.

Outside of the gearing, we designed the shooter with as much shooter engagement as possible given the packaging space we had. The shooter mounting was incorporated into the frame to provide a rigid base. There wasn’t lot of iteration to the competition shooter design. We were pretty much stuck trying to fit the shooter in the space available between the hopper and the arm.

Competition Learnings / Results:

We made no changes to the shooter throughout the competition season. Between Waterford and Northville, we briefly talked about switching to a different KOP wheel and played around with shooting at a slightly higher angle. Our testing between competitions showed no improvement with a different wheel or the change in angle, so we made no changes to the competition robot.

At Waterford we shot 58% in Hybrid and 71% during Teleop.
At Northville we shot 69% in Hybrid and 79% during Telop.
At Troy we shot 71% in Hybrid and 82% during Teleop.

Unfortunately, I can’t find any data for MSC or Champs. I believe we leveled out around 80-85% for both Hybrid and Teleop shooting percentages.

We had on the fly speed adjustment for any ball variation or changes. But we did not make very many adjustments at all throughout the season for Teleop. Majority of the shooter speed changes were made for Hybrid. But once we moved from the top of key to the bottom/middle, our Hybrid performance became much more consistant.

We ditched camera aiming about 1/3 of the way through the Troy event. 217 loaded on some crosshairs for us, we gave control to the driver to line up, and off we went. Prior to this change it really felt like there was un-tapped potential left in the machine. I couldn’t figure out why we were not shooting more balls. Then we removed the camera aim. That significantly increased the volume of balls we could shoot (2-3 balls/match). Basically, camera aiming was taking to long to line up, was not providing any increase in shooting percentage, and not allowing us to interact with more balls.

Overall I am happy with our shooter performance for this season. It was a simple solution to a complex problem and allowed our team to play the game exactly how we wanted too.

I’ll reply later with 973’s version (it’s actually pretty embarrassing), but for know I’ll say best thread on chief all year.

I’m a design junkie, and love seeing team’s thoughts on their own process ; especially when their designs and methods are tailored to efficient use of their specific resources.

Keep posting guys!

2815’s process pales in comparison to all of the above.

Like everyone else, we looked at the game at Kickoff and said “Okay, so we’re building a 6WD turreted shooter. Done.” Smaller elements like whether we wanted to be able to slot-load were discussed and contemplated.

It was midway through Week 3 where some showstopping CAD delays caused us to reassess our plans. The question was now “What will get us out of this funk?”

We thought of fender campers, but a moment’s inspiration led to our dual-headed shooter, carefully measured so that it would in line with the hoops as long as our back bumper touched the player station wall (because what are you going to do, push us more into the wall?). We figured that even if the idea was crap, we could pull it off and put on a forward- or rearward-facing shooter.

At first, our attempts at prototyping the shooter centered around going up a straight 45-degree angle; we prototyped this with square tubing and corrugated plastic from some scrapped signs at work. We realized that we needed something with a little more curve to the surface to make the ball travel better, which led us to Lexan…and what holding it? A run to Ace led me to 1/2" EMT electrical conduit. At $2 for 10 feet, I figured we had nothing to lose. (I was frequently sent on parts runs, since I didn’t have to supervise the kids and was willing to float some money and get reimbursed.)

Sure enough, the EMT bends nicely, is easy to work with, and is dirt cheap. (Expect to see more of it on future Los Pollos Locos machines.) We used flat aluminum strips to fine-tune the amount of squish the ramps gave us–we would bow the ramps out more, and the lexan pulled the aluminum back in to about right.

The early shots were promising, even giving us hope for threes. We weren’t at a level of sophistication (let alone time) to go into a custom gearbox, so it was a F-P motor in an AM Planetary, through a CIMple Box (good looking out, 1398), then sped back up to the shooter with a chain run. It was bootleg, but it shot!

At Peachtree, we swapped out the wedgetop for a wide piece of roughtop (black, of course) that covered both wheels as a tandem. The extra contact patch seemed to improve our shots, and we did respectably. By Palmetto, parts had arrived to let us add a second AM Planetary (this one running their 9015 motor). The extra oomph made us even more reliable, to the point of hanging a banner when combined with some luck from the backup line.

By Championship, we attempted to speed it up even more through changing the sprocket on the gearbox to be bigger (there wasn’t much room to go smaller on the axle). We hit a three on the practice field, but not with enough reliability to go with it. That we didn’t make elims was a disappointment (when isn’t it?), but understandable.

We do intend to redo the gearbox before SCRIW, and we may yet improve on it. Some next steps for this shooter could include:

-Switching to bearings on the shooter axle for less friction (we used bronze bushings out of familiarity, cost, and space reasons)
-Building a custom gearbox to accommodate more motors and faster gearing (we could add an ungodly number of motors under the rules–one more F-P, one more AndyMark, two or three more BaneBots, and even the Denso motors if we got fancy).
-Some method of rangefinding to enable us to dial in shots from further away than the fender (all of ours were within an inch or so of touching it). We experimented briefly with ultrasonic sensors, but couldn’t find a way to get a clean reading with the bumpers.

I just wanted to put in a process that I believe in as I live and breath it for many cycles (both personally and professionally) here:

This is how it is for us in software… there is no reset button… it’s ongoing and a bit scary actually to the parallel idea behind the original movie Tron “Everything you do or learn will be imprinted on this disk”… the code base is always present, maintained, modified in a never ending cycle. Good code goes through to be tested and used and if robust enough it never dies!

(As proof of concept, there is code written in 1998 that is still used professionally to this day… and that code is still not perfect as it still has bugs in it and still gets maintained).

So there are many stories of success, but I will write of a story of mild failure. Failure is subjective in its nature, so perhaps some may not agree with my assessment of things.


We started out the season knowing that we would have to do a shooter, and we were facing a task that no one on the team had any experience with. Our initial goals were simply consistency and distance. Although some of us recognized factors such as spin-up, speed loss, and physical space, we never formally declared any expectations for those.

Now, in our region, the turrented-hood shooter of 1771 are a thing of legend, so in the back of my mind, I know that we would be going down that route. However, we never imposed any assumptions and wanted to go through the full development cycle.


Our first proposed idea was the two-axled shooter. The development and prototypting of this stage took roughly two weeks, but we learned a lot about ball compression, compression vs. distance shot, and variance in the shot vs. how the ball was fed in.

This is when the imaginary feces hit the figurative fan. After playing around with the design for two weeks, the team was ready to move on.

However, moving on proved a little bit more tasking than initially thought. Student leaders had prepared for and were ready to create a hood design. They had rough dimensions that would help them prototype a design, but this proved time intensive. On the other hand, a smaller team consisting of one mentor and a couple of students created a prototype of their own. This prototype used one 8" wheel, went through roughly 150 degrees of compression, and the compression was roughly 4" at its most compressed.

The latter design proved popular among most of the team, due to the fact that it worked. It appeared to achieve our initial goals which appealed to the mentors, however, a handful of students were still adamant on testing their single axle shooter.

Final Result

As week 4ish was wrapping up and work on the other systems was wrapping up, we were forced to make a decision, and the decision was made to scrap the momentum-less hood design and assume the larger shooter as our primary shooter.

Our final product was similiar however, we made some swaps to help with consistency.

  • We swapped to an eight inch colson wheel to help with slow down after shots.
  • We used aluminum ball guides and tracks to make sure they were consistent and light.
  • ~4" of compression.
  • ~150 degrees of carry.

Further testing and prototyping revealed that the secondary shooter characteristics which we considered non-critical ended up being our achilles heel. The shooter ended up too big, took too long to spin up, and slowed down too much between shots. At the end of the day, even our consistency was shotty as we saw variation in almost every direction.

All in all, our shooter was a major choke-hold in our robot (among other things). We wanted to go through each option and prototype each design, but that ultimately fell apart. A smarter allocation of resources and man power would have helped this. Also, a more head-strong approach to assemble proven designs (single axle shooters) would’ve also helped.

In the end, we ended up doing ok. While we were reduced to two point shots at the Peachtree Regional, we managed to pull off a win with a lot of luck and a lot of help.

  • Sunny G.

It be cool to see all these robots and manipualtors on FRCdesign so many can see close ups of each of the robots

Our team (1296) and our other school district team (3310) got together for the 3rd year in a row to our parallel design meeting. We decided to go with a wheel-ed shooter instead of an air cannon/puncher/catapult alternative, though all 4 methods were brought up in the meeting. We made this decision because we thought it would be the easiest to produce, easiest to control distance, and quick to fire.
After that, we decided we wanted to have our turret pivot 360 degrees so we could shoot from all robot orientations. This was suggested by 3310 as they had already chosen a tank drivetrain and we had selected mechanum again. This infulenced our decision to not have a variable-angle hood due to complexity with wiring and weight. We opted out of the 360 degrees rotation and settled on 120 degrees because of the agility of the mechanum.
We did some prototyping of our shooter ideas with 4X4 and 2X4 wood (excellent for making strong prototypes) and some spare motors we had. We tested 3 models, one with 2 wheels on top and bottom, one with 2 wheels on left and right, and one with one wheel on the bottom with a curved hood. We ultimately decided upon the latter of the three designs. After several configurations and designs we finally had a CAD of our current shooter.
To get the speeds right, we spent several hours on our practice field testing distance-from-goal:speed-of shooter ratios until we formulated an algorithm to calculate the necissary speed automatically.
We originally had 2 Fisher price (the part # eludes me) motors and 2 gearboxless andymark motors working in tandum to power the shooter. (They were mounted on opposite sides of the wheel with different gearings so they each produced the same output speed into the wheel even though they have different Max RPMs) After the Bayou Regional, we did some further testing of the shooter and determined the andymark motors were actually Impeding the fisherprice’s speed.

So thats how we got what we got

I think #2 and #4 are worth noting.

#2 is to evaluate and agree that you want to score basketballs. Even though this seems really obvious, it is important to review the game and all of the scoring and confirm this is something you want to do.

#4 is to focus on the “what”, not the “how”. The intent was to get a ball through the hoop. As soon as you begin to say “shoot the balls”, then you start eliminating other ways of getting the ball through the hoop and start thinking about shooters.

Step 1. Understand the game and how to win the match and the event.

Step 2. Determine if we want to score basketballs.

Step 3. Evaluate the benefits and challenges and risks of 1, 2 and 3 point scoring.

Step 4. Brainstorm ideas on general “ball scoring” ideas.
(We avoided using the word “shooting” as long as possible, since we determined we wanted to score the balls but shooting was just a way to do that.)

Step 5. Sketches and rough prototypes of scoring options.
• Conveyors – could we make something like a farm conveyor to take the balls up to the goals?
o This is most suited for 1 or 2 point goals, more of a challenge for 3 point goals.
• Launch tubes – could we make a tube to raise up, rolls the balls off into the goal?
o This is most suited for 1 or 2 point goals, more of a challenge for 3 point goals.
• Push Shooter – could we push balls through a tube (pneumatics, springs, etc).
• Wheeled shooter – motor driven wheels to shoot, similar to many from “Aim High”.

Step 6. We determined a wheeled shooting system was the best option for versatility and the ability to score from many places on the field.

Step 7. Research shooters. Reviewed baseball and football machines. Reviewed “Behind the Design” ideas. Evaluated our baseball pitching robot from the summer of 2011. Evaluated one and two axle (ball between the wheels) designs.

Step 8. Based on reviews of other designs and our experiences, we determined that a single wheel shooter was our preference.

Step 9. Prototype. We made a basic design in Inventor, and then made our first assembly from Plywood and Lexan and wheels we had from previous kits and robots.
• Questions to be answered included –
o Speed required to shoot from the fender, the key, the bridge, the sides by the alliance bridge.
o Exit angle to required.
o Could we run a single speed and vary the exit angle and be accurate.
o Could we run a variable speed and have a set exit angle and be accurate.
o What squeeze was required to minimize the ball size and density effects.
o How critical was “the load” process and location on exit speed, motor drain, etc.
o What size wheel was optimal.
o What wheel material worked best with the game pieces.
o What was the best way to “aim” the shooter and what accuracy / tolerance was acceptable.
 Options – Lazy Susan rotation, Simple single point pin with worm drive movement, No rotation and only driver adjustments of robot
• Several iterations of speeds, exit angles and ball squeeze were tested and recorded.
• Based on test results for a surface speed of the wheel and the motor / gearbox capabilities, we determined a wheel size.

Step 10. System integration and implementing prototype results into a design.
• Decisions made
o Variable speed wheel.
o Fixed exit angle.
o Approximately 50 degrees of wheel / ball contact.
o Bottom load, top exit.
o 2 – 3” Squeeze.
• System Integration
o Shooter as low as possible to keep CG low and increase robot stability.
o Shooter high enough that a shot ball would clear a 60” robot that was sitting directly in front of us.
o Simple ball collection and management.
 Balls collected and held in a single row inside the robot.
 Balls loaded / sequenced into bottom of shooter.
 Balls managed to prevent “jamming” in the collector or shooter.

Step 11. Continued development of shooter.
• Improved shooter design created to incorporate mounting provisions, supports for left / right rotation, motor and gearbox mounting and adjustments for ball squeeze.
• Motor decisions
o Initial Prototype used 2 CIMs, 1:1 drive
o CIMs required for drive to provide speed and power required for the field
o Determined 2 FP and 2 AM motors with similar output speeds into CIM-sim gearbox was best option
 Power and durability of FP’s was known. AM’s assumed to be durable.
o Direct Drive mount of CIM-sim to shooter wheel shaft for a durable and simple drive.
 One set each side
 No additional gearing, chain or sprockets required.

Step 12. Shooter, Production Version 1.
• Higher quality shooter built to match new design.
• Continued prototype activity with wide and narrow wheels, wheel tread surfaces, single wheel and “double wheel” (two narrow width wheels with space between) and ball squeeze.
• Shooter mounted on robot frame to begin determining accuracy, speed requirements, optimal exit angle, etc.

Step 13. Integration to Prototype Robot (R1)
• The prototype robot (R1) was built while the shooter system was being tested and modified and optimized.
• The shooter system was mounted to R1. Integration, testing and modifications continued.

Step 14. Shooter, Production Version 2.
• Changes and improvements from continued work on the prototype were incorporated into the design of the shooter, ball collector and loading systems. Weight reductions were made, the design was optimized.
• Production Version 2 was completed and installed on the Prototype Robot (R1) while the competition robot was being constructed.

Our process wasn’t a formal process so much as a cobbling together of visions that had to be simplified into the greatest common denominator in order to come in under weight and on schedule. At the beginning we toyed with the idea of being a great box on wheels, yet we knew that we would be selling ourselves short if we didn’t attempt to design to the edge of our known capabilities. So we knew that some sort of shooter would work. No one on the team had a vision for a feasible catapult-like mechanism, so we went solely for spinning-wheel shooters. Research for anecdotes showed that more teams historically had greater success (so they felt) with vertical single-wheel shooters than any other type – so that was our starting point on Day 2. I’ll also say that our Day-0 primary goal was to be GREAT at autonomous – we felt that 12 points in autonomous, combined with balancing, would win us the majority of worst-case matches (matches with no partners).

1.) We did a feasibility exercise on shooting from anywhere on the court, including determining the exit velocities, aiming accuracy (2 dimensions, in degrees). This was finished after 4 days. Results: given our past results we didn’t feel that we could meet the consistent precision needed to shoot from the bump, bridge, or anywhere that was beyond the Key.

2.) We made an Excel spreadsheet showing all of the velocities and margins for error. This gave us a rough estimate of the power requirements for the motors, so we checked our motor/gearbox inventory and ordered parts as necessary.

3.) We then determined a range for the starting ball height as it left the shooter, given our preferred exit velocity and angle.

4.) A group built a 30-lb flywheel prototype from a cart wheel and some plywood, powered by a plugged-in 15,000 RPM Dewalt drill. It hit some very consistent 30-ft shots in the high goal. We had it at the end of Week 1 (we had a relatively light build schedule due to restrictions on being at the school).

5.) A week of “discussion” ensued about the simplicity of that design (and oversimplification of the environment) and why we couldn’t just use what we built. Why can’t we put a 15-lb wheel at 45" off the ground? We’ll be fine, right? At this point we were toying with the idea of an adjustable angle so we could also shoot from the fender. Eventually that got knocked out as too time consuming for our build capabilities.

6.) I CAD’ed up a compromise that used an IFI wheel with water-jet cut removable plates to act as adjustable flywheel weights. I posed a design challenge to the team to come up with simpler designs using lower-cost materials. We slapped all of the weights on and never got around to adjusting it because the re-calibration would take too long.

7.) We built the thing and moved on. This was the end of Week 3.

8.) The rest of the bot was built, losing 2 meetings in a row due to various things – so essentially Week 4 turned into Week 5 without anyone noticing. The bot was completed by the end of Week 6 though, so the final weekend was all testing and tweaking with no over-nighter’s (woo!).

9.) At competition we calibrated the distance of the shot with the wheel speed. I came to find out at champs that the programmers never integrated the encoder that was mounted and wired; they instead were setting it to a constant output power %, and used a stepper scale to ramp the power up (instead of a PID). After much discussion and “requesting”, they got all of that in and we went 17 for 18 shots in autonomous after the first match (our primary goal on Day 0).

Karthik’s talk about a team ‘reinventing itself to stand out’ hit home – I had an epiphany about the precise location for a stationary shooting robot in autonomous, which combined with a sighting mechanism to lead us to the one thing that made us stand out (adjustable-timing highly accurate autonomous). We were then going to feed for the most part, yet that never really came to fruition since we had to be the primary scorer in most of the qual matches and the captain of our champs alliance was primarily a feeder bot.

10.) Along the way we integrated the camera onto the driver’s display, and the drivers used tape to calibrate a set distance for the shots. How many shots we made was all dependent upon how ‘in the zone’ the driver was. Should we have made a turret to alleviate his stress? Considering a couple of students and I had a feasible detailed design in CAD for one ready in Week 2, we probably could have – yet considering we had to use all available weight on our overlooked bridge lowering device, it would have been a bad idea.

Thoughts for next year: for the last 3 years we seem to have overlooked a critical element of the game – the students and mentors get distracted by the glitz and glamour of the primary goal (ours is always “get on an alliance by scoring consistently in autonomous”). The focusing solely on the endgame led to great success (relative for us) in 2007, so I think we’ll come up with a design approach in 2013 that focuses on autonomous and endgame, leaving teleop open for the ‘powerhouse’ teams. This year’s element was the bridge lowering device.

What iterations did you go through?

I’m afraid to count. In the 6 weeks of time we did a very detailed build resulting in a great shooter/robot.

What features did you tune in during the evolution of your design?

  • Control loop for wheel speed shooting multiple balls
  • proto different motors and gearing to test motor power
  • ball path (How the ball is released to the wheel and how much distance the wheel is in contact with ball)
  • release angle for fender and key shot
  • wheel type (grip slip behavior of different materials vs wheel speed)
  • ball compression
  • camera targeting ( auto vs aimed, photo vs live feed)

Which system variables were most important to performance?

  • Control loop for wheel speed
  • Wheel contact area to impart the wheel rotational force to the ball
  • Type of material the wheel was made from
  • Ball release mechanism
  • Aiming and release angle

What did you prototype? How detailed were your prototypes?

  • CAD design ball path drawing
  • 8020 mock up
  • simple sheet metal proto
  • Final shooter using lightweight tube glued and riveted together
  • Used high speed camera and slow motion analysis

What did you start with? Why – what inspired this baseline?

We started with a single axle shooter with hood and no turret
We looked at many shooters from previous games took the elements we thought we could expand on.

Take a media trip of our 2012 build. The photos and video show the progress and our build capabilities and how much fun we had.

971 2012 Build Season

Roy’s 2012 Photos

Shooter Prototype Testing

Final Assembly and Testing

Practice at the Poof’s Lab

That article was written by the dynamics professor I had this spring. Coincidentally or not he actually went over how to shoot a basketball during the first week of class which gave me a good feel for my team’s shooter.

I’m not to delve into 2059’s design process cause that would require me to think and I don’t feel like doing that right now. But you can find specs of our robot as well as some design thoughts on my blog: Nothing on Purpose: Day 45: Introducing Benjy