Trajectory Analysis: How to Choose the Best Shot

I got myself thinking about an interesting problem last week. After a few attempts at it, I think I have something workable that people might find interesting. Pardon the long post and the “stream of consciousness” style write-up.

Crux of the Problem

For any given shot that you need a robot to take during a launching game, there are an infinite number of trajectories that you can choose from. What is the “best” trajectory?

How I Got Here

First Attempt

Given a static target position, for any launch angle there is one (and exactly one) launch speed that will hit the target dead center. Using Stronghold as an example (high goal, shooting from the outer works) that graph looks like this:

Each of those points on the line represents one of these trajectories:

These two graphs show some cool stuff. As the launch angle approaches 90, and the “straight line” shot, the required launch velocity approaches infinity. The line between those is a CSC(θ) function. Directly between those two is the shot requiring the minimum possible velocity. If you have less velocity then that, the shot can’t go in.

Or can it?

Second Attempt

The big problems with the first analysis are:

  • The game piece is always smaller than the goal, which means there is a margin of error on where you can hit the target and still score points. In effect, that CSC(θ) line has some thickness to it.
  • A launcher doesn’t always fire at exactly the same speed and angle.

So, factoring in the size of the game piece and target turns that linear graph into something more like this:

Where a shot on the green goes in cleanly, orange and yellow represent the lower and upper rims respectively, and red represents a miss.

Factoring in that a launcher is never totally accurate, you can put a bounding box around an area of this graph that represents any shot that your robot can make, and this is where the data gets more interesting.

The next logical conclusion was to make a plot of:

  1. The shot you’re aiming for, along with all of the worst case scenario shots, given your level of accuracy.

  2. The accuracy of every shot that you can take, given a fixed geometry and error in angle and velocity.

Analyzing a Shot

Once I had my spreadsheet made up, I was able to do some interesting digging. The first thing I did is to make the spreadsheet automatically tell me what my highest percentage shot is. With a robot of the same capability as the example above, you can aim for this flatter, faster shot instead, improving the accuracy from 81% to 92%:

The best shot that you can take is dependent on your launcher’s capability. If you can control the exit velocity tightly but struggle to get the angle dialed in, you can take a slower, higher angle shot and still nail it almost every time.

I also took the liberty of trying out some parameters from other FRC games.

Rebound Rumble: High goals, shooting from the key

The trick here was tightly controlling your velocity, and taking the slower, higher shot. It’s why 16 won.

Aerial Assist: Autonomous shot from the truss

A large game piece and a relatively small goal means lost of opportunity to hit the rims.

Steamworks: Autonomous shot from the hopper

This just shows what everyone knows already: Fuel was hard.

Here is my spreadsheet. Please ignore the horrible mess of tables that this thing runs on.
2019TrajectoryCalculator.xlsm (226.1 KB)
Updated 10/22/19 to fix an error with shots entering the goal at a steep angle

There is a macro in here to auto-scale the graphs. Disable it if you want, but the charts will look uglier.

So, has anyone else done an analysis like this? Does anyone have suggestions on what I could do better?

Assumptions Taken

  • Shots fall on a parabolic arc.
  • No wind resistance or magnus effect.
  • Shots that hit the rim have a fixed likelihood of going in.
  • Shots are evenly distributed over the available angles and speeds, instead of being normally distributed.
  • I have a hard speed limit put in here, and I have no idea how realistic or unrealistic it is.
  • Probably others that I forgot about.

Also, if any teams have data sitting around from 2016 or 2017 about the angle, velocity, and accuracy of their shooters, I’d love to see it.

We didn’t track angle or velocity in the classic sense described here, but calibrated testing at home put us at ~95% in 2017. We were less accurate, but not appreciably so, in match conditions.

I don’t believe the difficulty is in the analysis you’ve done here (although it’s definitely a useful reference to steer design efforts), but rather in making a shoot that can control your exit variables accurately enough (especially with varying game piece properties).


Can someone make this a Google product? Microsoft is banned from schools.

Do we actually live in a world where the Google suite is replacing Microsoft Office? That’s, uh, interesting.


I have a half-functioning Google Sheets version of this, but the accuracy vs. angle graph requires Excel’s “data table” function which doesn’t exist in Sheets, and the combo scatter/stacked area graph is tricky as well. I can give it a go tomorrow, but I can’t make any promises.

Edit: also, what kind of school bans Microsoft Office? It’s the base foundation of the entire professional world.


I guess one of the questions I was looking to answer here is “what is accurate enough?” To what degree do you need to be able to control things like velocity and exit angle, and at what point are you chasing accuracy gains that are essentially non-existent?

95% makes sense though. Every “reasonable” guess I put in about what kind of accuracy was attainable within FRC spit out a number around 95%.

2012 (and 2014) are interesting cases not exactly covered by your spreadsheet which is better suited to a goal like Stronghold (2016?). Since it was arguably better to just put tons of backspin and hit the ball at high velocity at the backboard in 2012 and similarly backspin and hitting the top rim (a la 254) was fairly accurate in 2014 too.

I wonder how you would go about calculating optimal stats for those kind of shots. Is it as simple as, get the flattest arc possible so that you can reach the “backboard” height from as many distances as possible? That’s what 33 went for and its clear from their 2014 reveal video.

I definitely meant to mention that the real target in 2012 was the backboard. The link I posted was for the “nothing but net” shot that nobody took because it was freaking impossible.

2014 is an interesting case as well. I wasn’t active in FRC at the time, so I was making my best estimate on some of the parameters there. However, in the sheet I have weights where you can specify the accuracy of a shot that hits the top rim and a shot that hits the bottom rim. If you set the bottom to 0 and the top to 100, you should be able to dial in a trajectory from there. The “suggested angle” and “suggested velocity” graphs won’t be totally accurate though, because they always suggest shots that fall on the “nominal” line.

I want to say that back in ‘06 a number of teams did something similar. 12 m/s muzzle velocity maximum, target center at something like 10’ up and slightly sloped towards the field.

Off the top of my head, there wasn’t anything other than physics preventing shots on goal from farther than mid-field, but physics does a pretty good job when you’ve got speed limits.

Oh, and… THE CHAINS! That’s a variable to account for. You can hit the target, but does your shot have enough to drop down in with the chains in the way? ('06, '16, and I think '10 all had chains in the shot opening, as did '13 which has different analysis because frisbees.)

Would be interesting to run the analysis again.

Aerial Assist had a clutch trajectory you haven’t mapped, and it highlights an important factor: Where can you get to reliably, and how much does defense affect your shot?

There was one speed and angle which would score from against the low goal and against a robot against a low goal. I know because we spent hours tuning that shot at comp when I was on 4039, but it was worth it - it was pretty near unblockable. Teams like 254 and 1918 also used it to great effect.

Very cool spreadsheet! I’ve been thinking about how to do something similar based on @camcage’s suggestion for my design calculator. I may need to take a look at how you did your calculations and borrow some stuff.

That being said, the spreadsheet didn’t work properly for me. Whenever I changed an input (even by 1" or 1°) the sheet freaked out and started giving errors. Then changing the inputs back doesn’t fix the problem. Not sure if I’m doing something wrong or if there’s a bug in the sheet.

The other thing I’m not so sure about is the assumption that angle/velocity errors are distributed uniformly over a certain range. I would imagine (without actually having any testing to back this up) that they are normally distributed. You would think the speed/angle you dial in for your shot (aka mean value) would be more likely to occur than one at the edge of your tolerance range. The further off you get from your desired speed/angle, the less likely it should be to occur. There may then be some superficially imposed limits where if the error is greater than some other fixed value the driver decides not to shoot and lets the system adjust. Not sure if/how this would affect your calculations.

I work with a multi billion dollar a year client who has completely switched to Google Docs and Sheets. I did not think I would ever see that.

Mine apparently. None of our teachers use it, it is blocked on student computers (the ones in the tech room, library, and computer labs).

1 Like

“Yes, it’s a good idea to force kids to do mandatory assignments wherein they sometimes include their immature opinions, thoughts and ideals into documents that are accessible to a giant machine that is well known to index and archive the writings of the people it tracks.”… said no one, ever.


I use Sheets instead of Excel in all of my physics labs because the school won’t spring for Excel’s license fees, despite the fact that Sheets is terrible and flakes out for no reason all the time, while Excel just works.

This analysis looks good! We did some similar work with frisbee math for Ultimate Ascent, and it gave us our most reliable shooter to date.

As I recall from 2016, high velocity shots had a propensity to bounce back out of the goal and not score. Did you take this into consideration in your data?
Example: During autonomous mode. 1747 clearly blasts the boulder into the target, but they do not get the score.

Are you using Excel 2016? It’s possible that I’m relying on some 2016 features here without my being aware. I just downloaded it onto a new computer and it was working fine (other than a problem I just noticed in the way I’m calculating entrance angle to the goal.)

Oh, I’m 95% certain that those shots are actually normally distributed. I just didn’t know how to model that here. This does some fairly dumb math to get percentages. It sums the areas of the orange, green, and yellow regions inside the bounding box, multiplies the orange and yellow by a weighting factor, and then divides by the total area of the box. The result is that the accuracy listed here is probably pessimistic.

I genuinely like Google Sheets quite a bit, but it’s missing some functionality from Excel that I’m using here.

Hmm. Not sure how I’d model that here in a “general use” solver. I think that would be up to testing and prototyping to find those kinds of issues. However, I was basing my upper estimates on velocity on 971’s 2016 robot, which was firing pretty hard from my memory.

That must be the problem. I was using Excel 2010. Just tried it on a different computer with 2016 and it seems to be working. Now I get to spend a few hours trying to figure out how it works :smile:

Some of the formulas are kind of awful. I can help decode some of it in a bit.