the video version
The same lesson as a narrated video. Watch it on YouTube
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–20 seconds of a match (the exact length is set by that season's game manual — it's 20 seconds for the 2026 REBUILT season, after being 15 seconds in several prior seasons).
- 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 theRobotContainerconstructor 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.
the part worth keeping
Key takeaways
- TimedRobot is the recommended base class; it runs your code every 20 ms (50 Hz).
- Each mode (Autonomous, Teleop, Disabled, Test) has *Init (once) and *Periodic (every loop) methods.
- robotPeriodic() runs in all modes — ideal for the command scheduler and dashboards.
- Keep periodic methods fast to avoid loop overruns.
- Command-based programming is built on top of TimedRobot.
Programming, Controls & SensorsThe Robot Program: Lifecycle and Command-Based Architecturelesson 1 of 4
Keep going
Take the quiz+10 XP with an accountMore in The Robot Program: Lifecycle and Command-Based Architecture
where this came from
Sources and corrections
This lesson is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
sources and further reading
- docs.wpilib.orgCreating a Robot Program
- github.wpilib.orgTimedRobot API (Java)
clipped to this lesson
Articles that go further on this
The lesson gets you through the topic. These go wider on it, and they read in one sitting.
- 7 min readFRC "Loop Time of 0.02s Overrun" & Watchdog Not Fed: Causes and FixesWhat "Loop time of 0.02s overrun" and watchdog-not-fed warnings actually mean in FRC, how to read WPILib's epoch dump, and the usual causes./blogread it
- 13 min readFRC Code Structure Best Practices: Command-Based Project ArchitectureHow to structure an FRC command-based robot project the right way — subsystems, commands, RobotContainer, and Constants — verified against official WPILib docs./blogread it
- 9 min readFRC Command-Based Programming: Subsystems, Commands, and the SchedulerA beginner-friendly guide to WPILib command-based programming in Java: subsystems, commands, the CommandScheduler, triggers, and composing commands./blogread it
answer sheet
Lesson quiz
All 3 right completes the lesson. Miss one and only that question comes back, anything you already answered correctly stays banked.
0 of 3 answered
01By default, how often does TimedRobot call its periodic methods (e.g. teleopPeriodic, robotPeriodic)?
02What is the difference between an *Init method (like autonomousInit) and a *Periodic method (like autonomousPeriodic) in the robot lifecycle?
03Which method is intended to run during every mode of the robot and is the recommended place to call CommandScheduler.run()?
Answer every question to submit.
All 51 lessons in Programming, Controls & Sensorsopenclose
01 / prerequisites
02 / foundations-tools-and-first-program
03 / robot-program-and-command-based
04 / motors-and-control
05 / autonomous-trajectories-simulation
06 / sensing-fundamentals
07 / encoders
08 / gyros-imus-orientation
09 / closed-loop-control
10 / vision-pose-estimation
11 / worked-examples-mini-projects
- Not read yet:Mini-Project: A Closed-Loop Elevator with Motion Magic
- Not read yet:Mini-Project: A Velocity-Controlled Shooter on REVLib
- Not read yet:Mini-Project: A Teleop Swerve Drive Subsystem
- Not read yet:Mini-Project: An Autonomous Routine with PathPlanner
- Not read yet:Mini-Project: Vision-Aligned Scoring with Limelight
12 / common-mistakes-troubleshooting
13 / advanced-techniques-case-studies
- Not read yet:State-Space Control and Kalman Filtering
- Not read yet:Log Replay Architecture with AdvantageKit
- Not read yet:Advanced Pose Estimation: Multi-Tag Fusion and Standard Deviations
- Not read yet:Robot Coordination, Alerts, and Operator Feedback
- Not read yet:Case Study: Hardening Software Before an Event