RoboticsIntermediate

Lookup Tables vs Equations for Shooter Tuning

When robot physics is messy, a measured lookup table can beat a beautiful but incomplete equation.

FRCShooterLookup tableCalibration
Robotic drive chassis with velocity vectors, a planned trajectory, and fiducial field landmarks
Generated visual worldRobotics & planning

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.

MeasureTest shots at known distances.
StoreRecord angle and RPM that score reliably.
InterpolateBlend between nearby distances.
RetuneUpdate values after mechanical changes.

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.

Reference table for this concept
MethodBest useMain strengthMain risk
EquationInitial estimate and sanity checkCompact and explainableMisses robot-specific effects
Lookup tableReliable settings in a measured rangeEasy point-by-point calibrationWeak extrapolation and maintenance burden
HybridPhysics-seeded calibrationCombines prior knowledge with evidenceMore 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.

Reference table for this concept
ObservationLikely layerFirst check
Both mechanisms reach target but shots missSetpoint mapping or poseDistance estimate and table values
RPM never reaches table targetVelocity control or hardwareOutput saturation, battery, friction, gains
Pivot angle is consistently offsetZeroing or position controlEncoder zero and units
Only between-point shots missInterpolation assumptionAdd 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.

Sources and Further Reading

Related Explainers