Use the Systemcore onboard IMU: backup to the Boron on the robot, primary gyro in sim

[nlaverdure]

Goal

Use WPILib 2027's OnboardIMU, the IMU built into the Systemcore, in two ways:

1. On the real robot, as a backup when the Redux Boron (Canandgyro) disconnects.
2. In sim, as the primary gyro, because the Boron cannot be simulated.

Background

• The Boron is the only gyro (GyroIOBoron, sampled at high rate by CanandgyroThread). When it disconnects, Drive estimates heading by integrating module kinematics (Drive.java around line 196) and raises the gyroDisconnected alert. Kinematic heading drifts with wheel slip, which is exactly when a gyro matters.
• The Boron has no simulation support. The ReduxLib 2027.0.0-alpha-7 jar has no simulation classes and no SimDevice references. Redux's only mention of simulation is a 2023 changelog note that says "Proper simulation support is planned."
• So the sim uses new GyroIO() {}, which always reports connected = false. The sim therefore always runs the kinematic fallback, and the connected-gyro path (odometryYawPositions) never runs in sim. The alert is only hidden because Drive skips it in SIM mode.
• OnboardIMU API (checked with javap on the alpha-7 jar):
  • The constructor is OnboardIMU(MountOrientation), where MountOrientation is FLAT, LANDSCAPE, or PORTRAIT.
  • Methods: getRotation2d(), getYawRadians(), resetYaw(), getRotation3d(), and getGyroRateZ(), among others.
  • Simulation: org.wpilib.simulation.OnboardIMUSim offers setYaw, setGyroRateZ, and angle and acceleration setters.

Plan

• Add GyroIOOnboardIMU implements GyroIO. It reports yaw, yaw rate, connected, and one odometry sample per loop.
• Robot backup. Keep the Boron as primary. When it reports disconnected, take yaw from the onboard IMU:
  • No heading jump at the switch. Offset the IMU yaw so it matches the last good Boron yaw at the moment of switching.
  • Decide what happens when the Boron returns: switch back, with a matching offset, or stay on the IMU until the robot is disabled.
  • Log which source is active, and keep logging both yaws so drift can be compared.
• Sim primary. Use GyroIOOnboardIMU in Robot's SIM case.
  • What moves it: something must drive OnboardIMUSim. Until Sim drivetrain with chassis dynamics, so module-force feedforward matters in sim #39 adds chassis dynamics, set it from the heading integrated from module kinematics. That adds no new physics, but it runs the connected-gyro code path in sim for the first time.
  • Later: once Sim drivetrain with chassis dynamics, so module-force feedforward matters in sim #39 exists, drive it from Sim drivetrain with chassis dynamics, so module-force feedforward matters in sim #39's chassis rotation.

Caveats

• Mounting and sign conventions must be verified on the robot: which MountOrientation matches how the Systemcore is mounted, and that yaw is CCW-positive like the Boron.
• Sample rate. The Boron feeds high-frequency odometry through CanandgyroThread. Reading the IMU once per loop is likely fine for a backup, but that's an assumption to measure.
• Drift and vibration. The Systemcore's location may be noisier than the Boron's. Log both gyros through a match and compare before trusting the IMU as a backup.
• Replay. Both go through GyroIO inputs, which AdvantageKit logs, so replay stays consistent. Keep the source-selection logic driven only by logged inputs.

Done when

• On the robot, unplugging the Boron mid-drive switches heading to the IMU without a visible pose jump, and the log shows the source change.
• In sim, Drive runs with a connected gyro, not the kinematic fallback.
• The AutoSimTest tracking assertions still pass.