There have been a lot of successful implementations of shooter state optimization using physics, like 1690’s Shoot-on-the-Move System and calcmogul’s shooter trajectory optimization using Sleipnir. This kind of system involves building a mathematical model for the gravity and air dynamics of the projectiles and finding the best trajectory.
These are, without a doubt, awesome and cool projects.
Interpolation
On the other hand, most teams use simple aiming mechanisms that have also worked fine. For example, we find the most optimized shooter state from different distances by trial and error, then do a linear interpolation. If the robot is moving, we also approximate the flight time using linear interpolation and aim at a “ghost target” about 0.3~0.8 seconds ahead.
Disadvantages of physics-based
Although more accurate, there are a few disadvantages to using physics-based. Including:
There is no way to validate your model. Think about system identification, it knows all the data relevant to its mechanism model (voltage, position, velocity, acceleration…) and validates the model using goodness-of-fit-metrics.
But for an air-dynamics model of the projectile, you never know whether your model is correct, nor do you know that your constants are accurate. Because you don’t have something like this in your workshop.
It’s hard to tune. We all have the experience, where a system that works perfectly fine on your practice field happens to not work in the competition field, or something that works last match happens to not work in the next match. In these “unhappy situations”, I would rather be tuning this:
From a mid-tire team, I’m so glad that we stuck with simple linear interpolation Saved us so much time and effort.
(Also our shooter can’t really shoot far and did subwoofer most games lol)
I personally think it greatly depend on the team’s ability and resource, and make smart decisions to get best outcome in shortest amount of time
IMO, don’t bother with physics-based shooting. Most of a shooter’s performance is purely mechanical (stiffness, energy transfer, backdrivability), and you aren’t gonna get a whole lotta perofrmace with a physics model you can develop in an FRC build season. In the time it would take to write and validate a physics model, you could’ve already tuned a lerp solution and consistently nail the goal. Unlike physics-based models for controls, air drag for shooting is extremely hard to model and matters for shots and can only be solved using expensive numerical methods like the shooting method, which you really don’t want to be running on your robot.
Being able to adjust shooter values mid-comp is also extremely important, whether it be from gamepiece variability (FRC 2024, FTC 2021), air pressure (FRC 2022), or game piece wear (many, most notably FRC 2020)
I agree with all of your post except this. The roboRIO v1 can solve this shooter trajopt problem in 85 ms with Sleipnir (3.7 ms on my laptop, which is 23x faster than a roboRIO v1 in general). That doesn’t seem prohibitively expensive.
I think this is a false dichotomy; interpolation still relies on the physics of the system to work (it wouldn’t perform well if the dynamics weren’t smooth enough).
Perhaps a better way to frame this would be: how parametric is your shooter control? Note that this isn’t black-and-white; it’s a gradient.
I’m not a native speaker and I guess I’m bad at expressing myself, I was trying to say “Physics-Model-Based vs Interpolation”. Anyway, thanks for the correction.
My point is that even a “physics model” is in some sense an interpolation, because you have to make a simplifying assumption somewhere to make the model tractable.
When you populate a lookup table, in some sense you are building a model of your system. It’s what we’d typically call a “nonparametric” model, which is a bit of a misnomer because in reality it has many more parameters (each entry in the lookup table…) than a “parametric” model. In nonparametric models, it is generally difficult to interpret the individual parameters - but in no sense are they nonphysical.
Unless your attempting to shoot on the fly there will most likely be no noticeable difference between empirically building a lookup table vs starting with something based on a physical model.
The largest advantage to the physics based parameterization is it lets you model in your drivetrain velocity and will (probably) yield you a much more correct shots at high speeds, where air resistance added from the drivetrain is non negligible.
That being said, in most cases there will be a 80% solution that takes 20% the work. This could involve simply introducing some extra parameters on top of your empirically tuned shooter map to account for the increased air resistance when shooting on the fly.
I would start with the simplest possible solution and iterate your approach as you notice room for improvement.
This reminds me of a really effective alignment algorithm 973 used for a while. They would just set their setpoint equal to the error and it would lock on pretty instantly. Doesn’t get much simpler than that!
| 
Saved us so much time and effort.