Lookup Tables vs Equations for Shooter Tuning
When robot physics is messy, a measured lookup table can beat a beautiful but incomplete equation.

Motion, sensing, control loops, and plans made visible as a field of forces and trajectories.
Interactive model
Setpoint choice and closed-loop response
The curve represents the controller tracking a chosen setpoint. The lookup table chooses that setpoint; PID is responsible for tracking it.
Live HTML simulation · adjust the controls and watch the computed output respond.
Interactive
PID tuning changes speed, overshoot, and settling
This is a simplified teaching model. Its displayed values are computed from the controls; the article explains where the model stops.
Site connection
How to choose, interpolate, validate, and maintain shooter setpoints without confusing calibration with closed-loop control.
The Equation Is Not the Robot
A projectile equation can estimate launch conditions, but a real FRC shooter also reflects wheel compression, battery behavior, spin, mechanism flex, measurement uncertainty, and game-piece variation. A lookup table records settings that were actually tested on that robot.
Definitions: Model, Calibration, and Setpoint
An equation maps inputs to outputs using an explicit model. A lookup table stores measured input-output pairs. For a shooter, distance may be the input and pivot angle plus left/right wheel RPM may be outputs. Interpolation estimates values between tested keys.
Neither method directly controls the hardware. The mapping chooses setpoints; position or velocity controllers then make the pivot and wheels track those setpoints. Keeping selection and control separate makes failures easier to diagnose.
A table is empirical memory, not a suspension of physics. Its advantage is that unmodeled robot-specific effects are folded into measurements inside the tested region.
Why Team 1257 Chose a Table
Team 1257's season notes say the team chose a lookup table instead of a single angle-and-RPM equation because real behavior was nonlinear and dynamic and because individual values would need adjustment. The team wrote Lookup and LookupTuner utilities using logged dashboard numbers and noted WPILib's InterpolatingDoubleTreeMap as a future option.
The same notes are careful about maturity: an early shoot-while-moving command did not yet work in simulation, and later the team reported tuning the table from 3–5 m while close shots still used known fixed setpoints pending more tuning. The page therefore treats full-field accuracy as a goal, not a proven result.
| Method | Best use | Main strength | Main risk |
|---|---|---|---|
| Equation | Initial estimate and sanity check | Compact and explainable | Misses robot-specific effects |
| Lookup table | Reliable settings in a measured range | Easy point-by-point calibration | Weak extrapolation and maintenance burden |
| Hybrid | Physics-seeded calibration | Combines prior knowledge with evidence | More implementation and validation work |
Worked Example: Linear Interpolation
Suppose testing found 3600 RPM at 3.0 m and 4200 RPM at 4.0 m. For a measured distance of 3.4 m, the fraction through the interval is (3.4 - 3.0) / (4.0 - 3.0) = 0.4. Linear interpolation returns 3600 + 0.4 × (4200 - 3600) = 3840 RPM.
Apply the same calculation independently to pivot angle. If the endpoints are 32° and 40°, the interpolated target is 35.2°. These values are illustrative, not Team 1257's recorded calibration. WPILib's InterpolatingDoubleTreeMap performs this kind of linear interpolation for undefined keys between defined points.
Interpolation stays between tested neighbors; extrapolation goes beyond them. A production implementation should clamp, reject, or deliberately handle out-of-range distance rather than silently trusting a distant guess.
Calibration Workflow and Data Quality
Choose repeatable distance bins, verify pose/distance measurement, warm the mechanism, and take multiple shots at each bin. Record more than a single make: include angle, both wheel speeds, battery condition, game-piece condition, and dispersion. Prefer a setting that is repeatable over one spectacular shot.
After filling points, test between them to validate interpolation. Then test boundary distances and the exact out-of-range policy. Version the table with the mechanical configuration because wheel material, compression, gearing, pivot zero, or shooter repairs can invalidate old calibration.
| Observation | Likely layer | First check |
|---|---|---|
| Both mechanisms reach target but shots miss | Setpoint mapping or pose | Distance estimate and table values |
| RPM never reaches table target | Velocity control or hardware | Output saturation, battery, friction, gains |
| Pivot angle is consistently offset | Zeroing or position control | Encoder zero and units |
| Only between-point shots miss | Interpolation assumption | Add measurements or change representation |
Limits, Hybrid Models, and Moving Shots
A one-dimensional distance table assumes distance captures enough of the problem. It may not capture robot velocity, lateral motion, battery voltage, heading error, release delay, or asymmetric wheel behavior. Adding dimensions increases calibration cost and can leave sparse regions.
Equations remain valuable for initial guesses, range checks, simulation, and detecting implausible table entries. Team 1257's moving-shot notes predicted the next-tick pose from current velocity, computed estimated distance, then queried angle and RPM. That was a reasonable architecture to test, but the source explicitly says the early command still needed fixes.
The smallest adequate model is usually safest: add a variable only when logged misses show that the current mapping cannot explain or correct the error.
Common Pitfalls
- Extrapolating far beyond tested distances.
- Forgetting to retune after changing wheels, compression, gearing, or pivot zero.
- Interpolating angles and speeds without validating actual shots between sample points.
- Blaming PID when the table selected the wrong setpoint.
- Calling a single successful shot a calibrated point.
- Claiming shoot-while-moving performance that the source only described as unfinished or simulated.