What Autonomous Actually Is in Command-Based

If you think of autonomous as a completely different mode requiring different code, you've made a very common conceptual mistake. In Command-Based, the architecture doesn't change at all between teleop and autonomous. The same subsystems exist. The same commands exist. The same Command Scheduler runs every 20 milliseconds.

What changes in autonomous is simpler than that: the source of commands changes. During teleop, commands are triggered by driver button presses on controllers. During autonomous, a single pre-assembled command (or command group) is scheduled once at the start of the 15-second period, and the scheduler runs it to completion — or until the period ends, whichever comes first.

That's the entire difference. Everything else — subsystem requirements, the execute() loop, isFinished() checks, interruption handling — works identically to what you built in Unit 6. Autonomous is just Command-Based with a pre-scheduled command instead of a human driving.

The Autonomous Call Chain: From Enable to First Motion

When the Driver Station enables autonomous, a specific sequence of calls flows through your code. Understanding this chain prevents the two most common autonomous wiring bugs. Click each step to see what's happening and why it matters.

The Three Files and What Each One Owns

Every autonomous routine in a Command-Based project touches the same three files. Their responsibilities are strictly divided — blurring those responsibilities is the source of most structural bugs.

Robot.java: The Minimal Autonomous Wiring

The modern WPILib template for Robot.java in a Command-Based project is intentionally minimal. Here is what a correctly wired autonomous looks like, annotated for every line that matters.

public class Robot extends TimedRobot {

    private RobotContainer m_robotContainer;

    @Override
    public void robotInit() {
        m_robotContainer = new RobotContainer();
        // RobotContainer constructor creates all subsystems and wires all bindings.
    }

    @Override
    public void robotPeriodic() {
        CommandScheduler.getInstance().run();
        // Runs every 20 ms regardless of mode — keeps the scheduler ticking.
    }

    @Override
    public void autonomousInit() {
        m_autoCommand = m_robotContainer.getAutonomousCommand();
        // Ask RobotContainer for the selected auto command.

        if (m_autoCommand != null) {
            m_autoCommand.schedule();
            // Hand the command to the scheduler. It runs in robotPeriodic() above.
        }
    }

    @Override
    public void autonomousPeriodic() {
        // Nothing here — robotPeriodic() already runs the scheduler every loop.
        // Putting motor commands directly in autonomousPeriodic() bypasses the
        // entire Command-Based framework and is one of the most common mistakes.
    }

    @Override
    public void teleopInit() {
        if (m_autoCommand != null) {
            m_autoCommand.cancel();
            // Cancel the auto command when teleop starts.
            // Without this, a still-running auto command will compete
            // with your teleop commands for subsystem ownership.
        }
    }

    private Command m_autoCommand;
}

RobotContainer.java: Building and Returning the Auto Command

The getAutonomousCommand() method in RobotContainer is where your autonomous strategy is actually written. At its simplest, it assembles a command group from your individual commands and returns it. At its most sophisticated, it returns whichever command a SendableChooser selected on the dashboard. Both patterns are valid — they share the same structural contract: build the command here, return it, and let the scheduler execute it.

public class RobotContainer {

    // Subsystems — created once, shared with commands via constructor injection
    private final DriveSubsystem  m_drive  = new DriveSubsystem();
    private final IntakeSubsystem m_intake = new IntakeSubsystem();
    private final ArmSubsystem    m_arm    = new ArmSubsystem();

    // ── Pattern A: hardcoded single routine ────────────────────────────────
    // Fine for a robot with only one auto strategy. Simple and clear.
    public Command getAutonomousCommand() {
        return Commands.sequence(
            new DriveDistanceCommand(m_drive, 2.0),   // drive 2 meters forward
            new IntakeUntilSensorCommand(m_intake),    // grab game piece
            new MoveArmToAngleCommand(m_arm, 90),      // raise arm to score
            new ShootCommand(m_arm, m_intake)         // score
        );
    }

    // ── Pattern B: SendableChooser (Unit 9, Lesson 5 covers this fully) ────
    // Used when you have multiple strategies to select pre-match.
    // m_autoChooser is populated in the constructor with addOption() calls.
    public Command getAutonomousCommand() {
        return m_autoChooser.getSelected();
        // Returns whichever Command the drive team selected on SmartDashboard.
    }
}

What the Scheduler Does With Your Auto Command

Once schedule() is called on the auto command in autonomousInit(), the Command Scheduler takes over. Click each lifecycle phase to understand what the scheduler is doing during those 15 seconds and what your command code is responsible for.

Subsystem Requirements During Autonomous

Every command that uses a physical mechanism must declare that subsystem as a requirement by calling addRequirements(subsystem) in the constructor. This is how the scheduler prevents two commands from fighting over the same hardware simultaneously.

During autonomous this matters just as much as during teleop — possibly more, because command groups often run parallel branches. If a parallel group has two child commands that both require the drivetrain, the scheduler will throw a runtime error and cancel one of them. Understanding requirements prevents that class of bug before it happens at a match.

public class DriveDistanceCommand extends Command {

    private final DriveSubsystem m_drive;
    private final double m_distanceMeters;

    public DriveDistanceCommand(DriveSubsystem drive, double meters) {
        m_drive = drive;
        m_distanceMeters = meters;
        addRequirements(drive);
        // ↑ This line is mandatory. Without it:
        //   - Default commands (like DriveWithJoystick) can preempt this command mid-auto.
        //   - Parallel branches in command groups can run conflicting drive commands.
        //   - The scheduler has no way to enforce hardware ownership.
    }

    @Override
    public void initialize() {
        m_drive.resetEncoders();
    }

    @Override
    public void execute() {
        m_drive.arcadeDrive(0.5, 0);   // 50% forward, no rotation
    }

    @Override
    public boolean isFinished() {
        return m_drive.getAverageDistanceMeters() >= m_distanceMeters;
    }

    @Override
    public void end(boolean interrupted) {
        m_drive.stop();
        // Always stop motors in end() — whether the command finished
        // normally or was interrupted. If you skip this, the motors
        // keep running at whatever speed execute() last set them to.
    }
}

How the 15-Second Period Actually Ends

You don't write any code to handle the end of the autonomous period. When the FMS transitions from autonomous to teleop, the Driver Station sends a mode change packet. WPILib receives it and calls teleopInit() in Robot.java. Your teleopInit() should call m_autoCommand.cancel(), which tells the scheduler to interrupt all running commands and call their end(true) methods.

From that point, the scheduler continues running — it just no longer has the auto command active. Teleop button bindings take over. Default commands resume on any subsystem that was being held by the auto command.

If your auto command finishes on its own before the 15 seconds are up (all commands in the sequence have completed), the scheduler simply has nothing more to run. The robot will coast or hold its last state until teleop begins — whichever motor commands were left active in the final command's end() method will remain in effect. This is why stopping motors in end() matters even when your auto finishes cleanly.

🔌 System Check

Knowledge Check