[jaxley]

Problem

The Three Wheel and Three Wheel + IMU tuners prompt for custom odometry encoder names, but localizer() in both procedures looks up the drive motors to float by the hardcoded defaults lf, lr, rf, rr:

for (String name : new String[]{"lf", "lr", "rf", "rr"}) {
    DcMotorEx motor = map.get(DcMotorEx.class, name);   // throws if absent
    motor.setPower(0);
    motor.setDirection(name.equals("lf") || name.equals("lr")
            ? DcMotorSimple.Direction.REVERSE : DcMotorSimple.Direction.FORWARD);
    motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.FLOAT);
}

Two consequences:

1. Robots with custom drive motor names crash the moment tuning starts. HardwareMap.get throws for missing names, killing the procedure on the default names — which looks exactly like "the tuner only uses the default names." The Mecanum tuner does not have this problem because it spins exactly the motors you enter.
2. setDirection() silently perturbs measured encoder polarity. Encoder.getMultiplier() folds in the motor's direction, so forcing REVERSE on the lf/lr ports flips the sign of any encoder sharing that port mid-procedure — baking a reversal into the tuned config that does not exist in the robot's real setup.

The generated ThreeWheelConfig/ThreeWheelIMUConfig encoder names themselves are applied correctly (the input plumbing is fine); the bug is this hardcoded float loop.

Fix

In both ThreeWheelTuner and ThreeWheelIMUTuner:

• Add four drive motor name inputs to the setup screen (defaults lf, lr, rf, rr), mirroring the existing encoder-name fields.
• Use the entered names in the float loop via HardwareMap.tryGet, skipping motors that are not present instead of crashing the procedure.
• Drop the setDirection() call — power 0 + FLOAT is all the measurements need.

Affected tuners

• ThreeWheelTuner — fixed
• ThreeWheelIMUTuner — fixed (identical loop)
• TwoWheelTuner, PinpointTuner, OTOSTuner, OctoQuadTuner, MecanumTuner — audited, clean (no hardcoded device lookups)

Both changed files compile cleanly against the published artifacts (com.pedropathing:core/revhub 3.0.1, tuning 1.0.1, FTC RobotCore/Hardware), and HardwareMap.tryGet is confirmed present in the SDK.