# 9 - Robot Program Structure

## We're finally getting into Robot Programming?
Yes! We had to get through some of the basics before we get into the robots. With that being said, we're going to start off easy and escalate and build out from here. Which means, we need to talk about the general structure of a Robot Program. Starting with the different modes that a robot can be in. 

## What are the different Robot Modes?
There are 3 modes that we're going to concern ourselves with. 

- Disabled - This is your robot's default state when it first starts up. Disabled just means, well, what the name implies. The robot is disabled, which means no motors, no pneumatics, basically nothing that moves is going to work. LEDs, sensors, and other non-motile systems still can run in the background though.
- Teleoperated - This is the mode your Robot is in where you (or your Drive Team) get's to move the robot with controllers. This is the meat and potatoes of a match at the competition. Most of the match is spent in this mode. 
- Autonomous - This is the mode where you're given the opportunity as a programmer to show your stuff. You make the robot automatically complete some aspect or series of aspects of the game that we are playing that year. An Autonomous program can be very simple, or wildly complex, it depends heavily on two things, your proficiency with programming, and how much time you are given with the robot to develop, test, and rework your autonomous program. No human interaction is allowed when the robot is running autonomous, no driver control at all, which means you'll need to use time, sensors, or both to figure out where you are on the field, and complete whatever tasks are laid out before you. 

Each mode has two methods, an init method and a periodic method. The init method is called (or used) once when your robot enters a mode. So teleopInit() would get called when Teleoperated starts, autonomousInit() would get called when Autonomous starts, and so on. The periodic method is called (or used) every 20ms (roughly 50 times a second) once the robot has run the associated init method for the mode your robot is in. 

There are some special methods that aren't technically a mode. These are the robotInit() and robotPeriodic() methods. The robotInit() method is where you do the setup for your robot. It's kind of like the __init__ method we've seen previously. All of your general setup should happen in robotInit() as it gets called once when your robot first boots up, before it enters any mode. As for robotPeriodic(), this method runs every 20ms (roughly 50 times a second) regardless of what mode your robot is in. You can put code here you want to have run all the time, like LED code, or sensor management code. 

## Every 20ms, that seems like a really small amount of time...
It is, you need to ensure that your code fits in this 20ms time period to make sure you don't experience problems controlling your robot. If your code in the periodic methods takes longer than 20ms too many times, something called the watchdog gets mad. When the watchdog doesn't get fed, for safety reasons, it will shut your motors down. Not ideal. Don't worry though, unless your doing something completely insane, it's unlikely normal beginner to intermediate level robot code shouldn't cause any issues. 

## So, is this example how all robot programs will start?
Yes...for now. There are other forms of writing robot code that change this up a little bit. But we are nowhere near talking about that. For all of the examples we'll see up through and including example 19 will use this structure as a base.