Autonomous

The class is the part you cannot test without a driver station. Keep everything else out of it. A command that reads a controller, checks the match clock, or names a mode has taken on the class's job.

Lifecycle

The @Autonomous class

The name on the driver station, the Robot handed to its constructor, and the schedule and cancel calls at the mode boundary.

Behavior

The routine command

Which way to drive, for how long, and how it stops. The same command can run from a button or from another routine unchanged.

A command built on the drivetrain requires the drivetrain, so a second drivetrain command cannot run beside it. Arm and flywheel commands can. That is the same resource rule the scheduler has enforced since Workshop 2.

The PathPlanner plan does not become code yet. Its published Java examples target Commands v2, and pasting them into this project will not compile. What carries over is the geometry: where the robot starts, which way the first segment runs, and roughly how far.

Everything gets built in the constructor, which runs the moment somebody picks the mode. The routine lives in a field because end() needs a reference to the command it cancels. Building a command sends no output, so the constructor is safe to run while the robot is still disabled.

1package frc.robot.opmodes;
2 
3import static org.wpilib.units.Units.Seconds;
4 
5import com.ctre.phoenix6.swerve.SwerveRequest;
6import frc.robot.Robot;
7import org.wpilib.command3.Command;
8import org.wpilib.command3.Scheduler;
9import org.wpilib.opmode.Autonomous;
10import org.wpilib.opmode.PeriodicOpMode;
11 
12@Autonomous(name = "Leave Start")
13public class LeaveStartAuto extends PeriodicOpMode {
14  private final Command routine;
15 
16  public LeaveStartAuto(Robot robot) {
17    Command drive =
18        robot.drivetrain
19            .applyRequest(
20                () ->
21                    new SwerveRequest.RobotCentric()
22                        .withVelocityX(1.0)
23                        .withVelocityY(0.0)
24                        .withRotationalRate(0.0))
25            .withTimeout(Seconds.of(1.5));
26 
27    Command stop =
28        robot.drivetrain
29            .applyRequest(() -> new SwerveRequest.RobotCentric())
30            .withTimeout(Seconds.of(0.1));
31 
32    routine = Command.sequence(drive, stop).named("Leave Start");
33  }
34 
35  @Override
36  public void start() {
37    Scheduler.getDefault().schedule(routine);
38  }
39 
40  @Override
41  public void end() {
42    Scheduler.getDefault().cancel(routine);
43  }
44}

A timeout is the only finish line available here. DriveMechanism reports its pose, but nothing on it answers am I there yet the way arm.isAtTarget() did on Finish Conditions. Workshop 4 adds a command that measures against a field pose and finishes when it arrives.

Two names go into this file and they do different jobs. The one in the annotation is what the driver station lists, so it is the one a driver reads under pressure. The one in .named(...) is what the command is called in the log.

The robot's field position is never set in this project, so the starting pose you wrote down in PathPlanner appears nowhere in the code. Drivetrain/Pose starts wherever odometry left off. Restart the robot code before a measured run and it reads near zero, which makes the distance easy to read straight off the log.

Each pass answers one question, and each one can fail on its own. Run them in order. A routine that fails the second pass has nothing to prove in the third.

1. On blocks. Deploy, pick Leave Start off the mode list, and enable. All four modules drive forward together for about a second and a half. Then they stop, and they stay stopped while the mode runs.
2. On the floor, once. Put the robot on its tape mark with clear floor ahead of it and run the same routine. It leaves in the direction its front bumper points, because RobotCentricX is the robot's forward and not the field's. The starting heading sets the direction.
3. Measured, three times. Tape the floor at the front edge before and after each run, starting from the same mark every time. The taped distance and the end of Drivetrain/Pose in the log should agree within a few centimeters. The three runs should land inside about ten.
4. Disabled partway. Hit disable about a second into the drive. The wheels stop at once. Re-select the mode from the list before running again: picking a mode builds the OpMode fresh, and a fresh routine with it.

A second and a half is a small slice of an autonomous period. A robot that sits still for the rest of it has not failed. That is the stop step doing its job.

A routine fails quietly. Nothing throws, nothing logs a complaint, and the robot does something you did not ask for. Almost all of it looks like one of these three.

Nothing moves

Stuck on a step

Selected, enabled, sitting still. A step with no ending holds the sequence there forever. Look for a request with no .withTimeout(...) on it.

Never stops

A latched request

The timeout expires and the robot keeps rolling. Nothing zeroes the drivetrain, so the last request stays applied. The zero-speed step is the fix.

Wrong place

Heading or voltage

It moves, and not where you drew it. Robot-centric X follows the starting heading, and a tired battery shortens a timed step by a surprising amount.

A mode missing from the driver station list is a different problem. Take it back to OpModes: a class that is not public, an annotation with no name, or a constructor that does not take Robot.

Read the log before guessing. Drivetrain/Pose at the end of a run separates a robot that went the wrong way from one that never went anywhere.

Run the routine three times from the same tape mark, on the floor, with logging on. You are done when the three runs land on top of each other.

Write down the distance the tape measured, the end pose out of the log, and the timeout that produced them. Workshop 4 replaces that timeout with a field pose the command can steer to. These three numbers are what you will hold the new routine against.

A second routine is a second file. Copy this one, change the annotation name and the numbers, and it turns up on the list beside the first. Nothing registers it, and nothing in Robot.java chooses between the two.