Swerve Project Generator

The generator can write a whole project. Only one file comes back with you: src/main/java/frc/robot/generated/TunerConstants.java.

It has thirteen device IDs, kDriveGearRatio, kSteerGearRatio and kWheelRadius. Per module it holds an X and Y offset from the robot's center, which is what kinematics runs on. There is a CANcoder offset per module as well, measured with that wheel straight. steerGains, driveGains, kSlipCurrent and kSpeedAt12Volts are estimates you replace over the next two lessons.

1. Put every device on one CAN bus with a unique ID, and write the IDs down corner by corner. You want thirteen listed, no duplicate-ID warning, no red firmware badge. A missing device is a wiring fault.
2. Open the swerve project generator, under Mechanisms, behind a New Project button. It opens by asking for dimensions rather than for code.
3. Measure the robot and enter four numbers.
   • Wheelbase, labeled FL to BL: front-to-back distance between module centers.
   • Trackwidth, labeled FL to FR: side-to-side distance between module centers.
   • Wheel radius: half the wheel's diameter, measured on a wheel already driven on. The field asks for radius, not diameter.
   • Drive gear ratio: motor rotations per wheel rotation, off the module's spec sheet.

   Take them off the real robot, not the CAD you meant to build. Wheelbase and trackwidth are the pair people swap, and on a square robot that stays hidden until it turns.

4. With the robot on blocks, the wizard drives the modules one at a time. Hold each wheel straight when it asks: that measurement becomes the corner's CANcoder offset. Half a degree of error per module walks the robot sideways over a long drive. If the corner moving is not the one the wizard named, two CAN IDs are swapped.
5. Generate the constants and replace src/main/java/frc/robot/generated/TunerConstants.java with the file it writes. Replace the whole file, since offsets, inversions and IDs all come from the same run. You should see your own CAN IDs and a kCANBus line naming your CANivore.
6. Set your team number in .wpilib/wpilib_preferences.json, which ships as 5712, and deploy to SystemCore. The driver station lists Teleop as a selectable mode. Modules point straight when you enable, and nothing spins on its own.

Hardware Simulation ran your code on the laptop against real motors on the bench. This project also runs with no hardware at all. Phoenix 6 simulates every TalonFX, CANcoder and the Pigeon, and CommandSwerveDrivetrain runs a physics update every 4 ms whenever it finds itself in simulation. The wheels turn, odometry counts them, and the pose moves.

1. Choose Simulate Robot Code from the same toolbar menu, the line above Hardware Sim Robot Code.
2. In the simulation window, drag your controller onto Joystick[0], pick Teleoperated, and select the Teleop OpMode.
3. Open AdvantageScope, connect it to the simulator, and drag Drivetrain/Pose onto a 2D field view.

You should see: the robot drawn on the field, moving when you push the stick and stopping when you let go. The example constants work here unchanged, because nothing goes looking for real devices. Every later swerve page that says "in the simulator" means this.

The drivetrain is three classes. TunerConstants.java is Tuner X's, from your robot: every number about it, hand-edited only when calibration says to. CommandSwerveDrivetrain.java is Tuner X's too, lightly edited. It holds the motors, odometry, the simulation thread, and forward matched to your alliance color.

DriveMechanism.java is the workshop's, written by hand. It implements Mechanism, owns a CommandSwerveDrivetrain as a private field, and is what an OpMode talks to. That keeps the code you write out of the files Tuner X writes. It also narrows the drivetrain's hundreds of methods down to the few the rest of the robot needs.

Both applyRequest(...) and seedFieldCentric() return commands, and setControl(...) sends one request straight through. Two more read the drivetrain back: getPose() and getFieldVelocity(). The camera comes in later, through addVisionMeasurement(...).

A Mechanism has no default command until you give it one, and a canceled command leaves its last request in the motors. The arm gets away with that, because its last request is a position and it holds there. A drivetrain's last request is a speed.

So teleop gives the drivetrain a real default, the only setDefaultCommand call in the workshop code. It sits in TeleopOpMode rather than Robot because it needs that mode's controller.

1public TeleopOpMode(Robot robot) {
2    final DriveMechanism drivetrain = robot.drivetrain;
3 
4    // In WPILib, X points forward and Y points left. The sticks read the other way around, so
5    // each axis below gets a minus sign.
6    drivetrain.setDefaultCommand(
7        drivetrain.applyRequest(
8            () ->
9                drive
10                    .withVelocityX(-driver.getLeftY() * maxSpeed) // left stick up = forward
11                    .withVelocityY(-driver.getLeftX() * maxSpeed) // left stick left = left
12                    .withRotationalRate(
13                        -driver.getRightX() * maxAngularRate))); // right stick left = turn left
14 
15    // Left bumper: make the robot's current facing the new "forward".
16    driver.leftBumper().onTrue(drivetrain.seedFieldCentric());
17  }

applyRequest(...) is built on runRepeatedly, so it re-reads the sticks and sends a fresh request every loop. Let go and the command is still running, asking for zero. Full stick asks for maxSpeed, which comes straight out of TunerConstants.kSpeedAt12Volts.

A default command has to require its own mechanism and no other. Break that and the scheduler throws an IllegalArgumentException at runtime, not a compile error.

The left bumper runs seedFieldCentric(): whatever way the robot faces becomes forward for the sticks. It never says where the robot is on the field. Swerve Calibration sets it beside resetPose(Pose2d), the call that does.

Robot on blocks for the first two checks, then on the floor with room around it. Keep a hand on disable.

1. Select Teleop and enable, hands off the controller. All four wheels stay still and each module holds the angle it had. Creeping means an off-center stick or a wrong deadband.
2. Push the left stick forward: four modules pointing the same way, four wheels turning the same direction. A wheel turning backwards is an inversion; a module facing sideways is a CANcoder offset. Push the right stick sideways and the modules splay into a rotation pattern.
3. On the floor, point the robot away from you and push forward. It drives away in a straight line. Turn it 90 degrees in place, push forward again, and it goes the same direction across the floor. Press the left bumper and forward becomes whatever way it is facing now.
4. Let go of everything. The robot stops and stays stopped, because its default command is asking for zero.

Swerve Calibration is next. It replaces the generator's estimates with numbers measured off your robot.