The Robot Class
What makes your programs work in the first place.
Welcome to the backbone of the robot— the Robot class! Without this class, your robot literally can't do anything. This is a problem if you want to win your matches.
If you look at it for a bit, you might notice that it's packed with methods. You might also notice that their names end in either Init() or Periodic(). You might also notice that they all have some state in front of them, like Autonomous or Teleop.
If you know a little bit about FRC/FTC competitions, you might know about the different stages of the game— Autonomous, Teleoperated, and Endgame. You also might notice how some of these methods begin with these words. All of these methods can run depending on the state of the robot.
Methods that end with Init() run only when the robot just switched to that state (for example, when a robot switches from auto to teleop, TeleopInit() will be called)
Method names that end with Periodic() run while that robot is still in that state (ex, during Teleop, TeleopPeriodic() will be run)
Here is a list of states that you will need to know.
Robot— runs while the robot is powered.
Auto— runs during the Autonomous period of a match
Teleop— runs during the TeleOperated period of a match
Disabled— runs when the robot is disabled (safety stop and stuff)
Test + Simulation— run when Test and Simulation modes are run
If you're wondering what Test and Simulation are for, they're just extra modes you can turn on through WPILIB's Command Palette (basically just a list of cool commands you can do).
When do you put code in the Robot class?
Generally, in a command-based coding structure we try to avoid putting code in the Robot class. We also like to schedule autonomous commands in the AutonomousInit() method, but otherwise we usually put code here to brute-force our way through problems as a last resort.
Last updated