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 carries 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 on Swerve Calibration.

The copy checked into the workshop project belongs to somebody else's robot: fake IDs, fake gains, and a comment saying so. It describes a square robot with the modules 10 inches out in each direction, 7.36:1 on the drive, and a 2.167-inch wheel radius. Deploy it unchanged and the code looks for motors that are not on your bus.

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 tread width, 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 the way Running Your Code showed. The driver station lists Teleop as a selectable mode. Modules point straight when you enable, and nothing spins on its own.

Every other mechanism you wrote was one class. The drivetrain is three, because of a Java rule from The Java You Need: a class extends only one other class.

CommandSwerveDrivetrainalready extends CTRE's generated swerve class, so it cannot also extend Mechanism. DriveMechanism therefore owns a drivetrain instead of being one, and hands out its commands.

DriveMechanism is the only one of the three you would add to, and its surface is small. 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(...).

Every Mechanism starts out with idle() as its default. Since idle() parks at the lowest priority and sends nothing at all, canceling an arm command leaves the arm pushing. That is what arm.stop() is for. Teleop gives the drivetrain a better default, and it is the only setDefaultCommand call in the workshop code. The call sits in TeleopOpMode rather than Robot because the default 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 an ordinary command factory built on runRepeatedly. It re-reads the sticks and re-sends a fresh request every loop. Let go of the sticks and the command is still running, asking for zero speed. Full stick asks for the top speed the constants claim your robot has: maxSpeed comes straight out of TunerConstants.kSpeedAt12Volts. The request ignores the bottom 10 percent of each stick.

The scheduler checks two things when that line runs. A default command has to require its own mechanism, and it must not require a second one. Break either and you get an IllegalArgumentException at runtime, not a compile error. Commands from applyRequest(...) pass both; a hand-built group that also requires the arm would not.

The other binding is the left bumper, wired to seedFieldCentric(). Press it and whatever way the robot faces becomes the new forward for the sticks. It changes a heading reference and nothing else, so it never says where the robot is on the field. That job belongs to resetPose(Pose2d), which nothing in the workshop code calls yet. Swerve Calibration lines both up next to applyOperatorPerspective().

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 Calibrationis next. It replaces the generator's estimates with numbers measured off your robot.