What Timed Movement Is

A timed autonomous movement is exactly what it sounds like: you command a motor to run at a fixed duty cycle for a fixed number of seconds, then stop. No encoder. No gyro. No closed-loop feedback of any kind. The robot is blind — it has no way to know how far it actually traveled, whether it got bumped off course, or whether the battery voltage changed between your shop test and the competition match.

The code pattern is built around WPILib's Timer class. You start the timer in initialize(), apply a motor output in execute(), and check elapsed time in isFinished(). When the timer passes your threshold, the command ends.

Before looking at code, understand the conceptual model clearly: the robot is making a bet. It bets that "if I drive at 50% output for 1.5 seconds, I'll have traveled approximately 1.2 meters." That bet is correct when the battery is fully charged, the carpet is typical, and nobody bumps the robot. Every deviation from those assumed conditions costs distance accuracy.

Building a Correct Timed Command

A common mistake in timed commands is putting the motor command in initialize() and leaving execute() empty. This appears to work but creates a subtle problem: if the command is interrupted and restarted, initialize() runs again and resets the timer, but the motor was still running from the previous run. Structuring all repeating logic in execute() and timer management in initialize() avoids this.

import edu.wpi.first.wpilibj.Timer;
import edu.wpi.first.wpilibj2.command.Command;

public class DriveForTimeCommand extends Command {

    private final DriveSubsystem m_drive;
    private final double m_speed;      // duty cycle, -1.0 to +1.0
    private final double m_duration;   // seconds
    private final Timer  m_timer = new Timer();

    public DriveForTimeCommand(DriveSubsystem drive, double speed, double seconds) {
        m_drive    = drive;
        m_speed    = speed;
        m_duration = seconds;
        addRequirements(drive);
    }

    @Override
    public void initialize() {
        m_timer.reset();
        m_timer.start();
        // Reset and start here — not in the constructor.
        // The constructor runs once when RobotContainer is built,
        // which may be minutes before autonomous actually runs.
    }

    @Override
    public void execute() {
        m_drive.arcadeDrive(m_speed, 0);
        // Apply output every loop. Even though the output
        // doesn't change, motor controllers may timeout
        // without regular update commands on some configurations.
    }

    @Override
    public boolean isFinished() {
        return m_timer.hasElapsed(m_duration);
    }

    @Override
    public void end(boolean interrupted) {
        m_drive.stop();
        m_timer.stop();
    }
}

A Turn Command

The same pattern applies to any mechanism action. For a timed turn, you pass a rotation speed instead of a forward speed:

public class TurnForTimeCommand extends Command {

    private final DriveSubsystem m_drive;
    private final double m_rotation;   // positive = counterclockwise
    private final double m_duration;
    private final Timer  m_timer = new Timer();

    public TurnForTimeCommand(DriveSubsystem drive, double rotation, double seconds) {
        m_drive    = drive;
        m_rotation = rotation;
        m_duration = seconds;
        addRequirements(drive);
    }

    @Override
    public void initialize() { m_timer.reset(); m_timer.start(); }

    @Override
    public void execute() { m_drive.arcadeDrive(0, m_rotation); }

    @Override
    public boolean isFinished() { return m_timer.hasElapsed(m_duration); }

    @Override
    public void end(boolean interrupted) { m_drive.stop(); m_timer.stop(); }
}

Assembling a Timed Autonomous Routine

These commands become useful when assembled into a sequence in RobotContainer. The readable structure below is the primary educational value of timed commands — it demonstrates command sequencing clearly without the added complexity of sensor math:

public Command getAutonomousCommand() {
    return Commands.sequence(
        // Drive forward at 40% for 1.2 seconds
        new DriveForTimeCommand(m_drive, 0.4, 1.2),

        // Pause 0.1 s to let the robot settle after stopping
        Commands.waitSeconds(0.1),

        // Turn left at 30% for 0.85 seconds (tuned by observation)
        new TurnForTimeCommand(m_drive, 0.3, 0.85),

        // Drive forward again at 40% for 0.8 seconds
        new DriveForTimeCommand(m_drive, 0.4, 0.8)
    );
    // Total budget: about 3 seconds of the 15-second auto period.
    // Notice how the durations are tuned magic numbers — not derived
    // from any measurement of the robot's actual physical travel.
}

Why Timed Routines Fail at Competition

A timed routine is a model of the real world that assumes specific physical conditions. When those conditions change — and they always do — the model is wrong, and the robot goes somewhere it wasn't supposed to. There are three primary failure modes, each grounded in physics your robot has no way to detect or compensate for.

The Drift Simulator: See It Happen

Adjust the sliders below to simulate real-world conditions and run the "same" timed routine under each scenario. The routine is: drive forward 40% for 1.5 seconds. In ideal shop conditions it travels exactly 1.0 m. Watch how each variable shifts the actual landing position.

When Timed Commands Are Acceptable

Timed movement isn't zero-value — it has two legitimate roles in a competition codebase. Outside of these, sensor-based control should always be preferred.

WPILib's Built-In Timed Commands

Before writing a custom timed command, check whether WPILib already provides what you need. These factory methods on the Commands class and subsystem fluent API cover the most common patterns:

• Commands.waitSeconds(double seconds) — waits the specified time with no motor output. Use between commands to let mechanisms settle.
• command.withTimeout(double seconds) — decorates any existing command with a timeout. If the command hasn't finished by the deadline, it's interrupted. Excellent for sensor-based commands that might get stuck: new DriveDistanceCommand(...).withTimeout(3.0).
• Commands.runOnce(() -> subsystem.method()) — runs a lambda once and immediately finishes. Use for single-shot actions like resetting encoders or setting a solenoid state.
• Commands.run(() -> subsystem.method(), subsystem).withTimeout(seconds) — the inline equivalent of a full timed command class. Useful for very simple timed actions that don't warrant their own file.

🔌 System Check

Knowledge Check