TimedRobot and the Robot Lifecycle

The base class: TimedRobot

Every FRC robot program inherits from a base Robot class. The recommended one is TimedRobot, which calls your code on a fixed schedule — by default every 20 ms (50 Hz).

Robot modes

The Driver Station puts the robot into one of these states, and TimedRobot calls matching methods:

• Disabled — robot is safe; no actuators move.
• Autonomous — the robot runs on its own for the first ~15 seconds of a match.
• Teleop — drivers control the robot.
• Test — for testing/diagnostics.

The lifecycle methods

For each mode there is an *Init method (runs once when entering the mode) and a *Periodic method (runs every loop while in that mode):

• robotInit() — runs once at startup. Construct subsystems here (or in the RobotContainer constructor for command-based projects).
• robotPeriodic() — runs every loop in every mode. Great place to run the command scheduler and update dashboards.
• autonomousInit() / autonomousPeriodic()
• teleopInit() / teleopPeriodic()
• disabledInit() / disabledPeriodic()
• testInit() / testPeriodic()
• simulationInit() / simulationPeriodic() — only when running in simulation.

The 20 ms loop

Because periodic methods run 50 times per second, time-based math is easy: a value that should change by 1 unit per second changes by 1 * 0.02 each loop. You can change the period via the TimedRobot constructor, but going faster risks loop overruns — when your code takes longer than the period to run, which the Driver Station will warn about. Keep periodic methods fast.

A minimal example (Java)

public class Robot extends TimedRobot {
  private final Spark m_motor = new Spark(0); // PWM port 0
  private final XboxController m_driver = new XboxController(0);

  @Override
  public void teleopPeriodic() {
    // Drive the motor with the left stick Y axis, 50x per second
    m_motor.set(-m_driver.getLeftY());
  }
}

This is the entire mental model of "old-style" FRC code: read inputs and set outputs, every 20 ms, in the right mode's periodic method.

Why move beyond raw TimedRobot?

Raw TimedRobot works, but as a robot grows (drivetrain + arm + intake + shooter), giant teleopPeriodic methods become tangled and hard to debug. That's exactly the problem the command-based framework solves — and it's built on top of TimedRobot, so everything here still applies. We turn to it next.