OpModes

All three are ordinary Java classes. The annotation decides which name the driver station shows, and it says what the mode is for.

Driver control

@Teleop

Controller bindings and the defaults a driver expects. They exist only while teleop is the selected mode.

Preplanned

@Autonomous

One routine, named on the driver station, scheduled when the mode starts and canceled when it ends.

Pit work

@Utility

Zeroing, characterization, diagnostics. Keeping these out of teleop means a driver cannot trip one in a match.

One routine per class, not one class holding four of them. Four autonomous plans mean four @Autonomous classes and four names on the list.

The commands you wrote on Writing Commands call nothing yet. This is the class that calls them. Project Setup left a generated MyTeleop.java in opmode/, already carrying @Teleop. That is the file you edit. Replace its body with the whole file from the branch, minus the copyright header.

1package first.robot.opmode;
2 
3import first.robot.Robot;
4import org.wpilib.command3.button.CommandNiDsXboxController;
5import org.wpilib.opmode.PeriodicOpMode;
6import org.wpilib.opmode.Teleop;
7 
8/**
9 * The driver's controls. The framework builds this class when "Teleop" is picked on the driver
10 * station. The button bindings made in the constructor belong to this OpMode, and the framework
11 * removes them on a mode switch. No cleanup code needed.
12 *
13 * <p>The buttons here run the arm and flywheel commands.
14 */
15@Teleop(name = "Teleop")
16public class MyTeleop extends PeriodicOpMode {
17  private final CommandNiDsXboxController driver = new CommandNiDsXboxController(0);
18 
19  public MyTeleop(Robot robot) {
20    // Left trigger: push the arm up while held, stop when released.
21    driver.leftTrigger().whileTrue(robot.arm.runFast()).whileFalse(robot.arm.stop());
22 
23    // Right trigger: spin fast while held, drop back to the slow voltage when released.
24    driver.rightTrigger().whileTrue(robot.flywheel.runFast()).whileFalse(robot.flywheel.runSlow());
25 
26    // A: spin fast while held, stop when released.
27    driver.a().whileTrue(robot.flywheel.runFast()).whileFalse(robot.flywheel.stop());
28  }
29}

Building only the armflywheel? Delete the robot.flywheelarm bindings along with them. Same reason as the field: they call commands on a class that does not exist in your project.

Every whileTrue has a whileFalse behind it. whileTrue schedules the command on the press and cancels it on the release.

Most teleop classes need neither method below. Bindings made in the constructor are enough, and the framework removes them when the mode changes. There is no cleanup code to write. Bind in the constructor, but never drive a motor from it: the robot can still be disabled when that code runs.

1@Override
2public void start() {
3  // Called once when this OpMode becomes active.
4}
5 
6@Override
7public void end() {
8  // Called once when this OpMode stops being active.
9}

Autonomous is where the two earn their place. start() schedules the routine and end() cancels it. Pair them every time. Hit disable partway through a run and end() fires, so the routine stops on that loop rather than running on into the next mode.

Utility modes use the same boundary. Begin the calibration in start(), stop it in end(), and the mode is safe to leave at any point.

One question settles most of it. What is the smallest scope where this behavior still works? Put it there.

Run WPILib: Build Robot Code. You should see BUILD SUCCESSFUL. Nothing runs until Hardware Simulation, so the rest of this is a read through your own class.