What an OpMode Does

Okay, now that we have Android Studio set up and can connect to the Control Hub, we should probably talk about what the code we're opening actually does. So in FTC, the programs that appear on the Driver Station are called OpModes, and the important thing to understand is that an OpMode does not run all of its code at once. Different parts run during INIT, after START, and after STOP. So let's map that out first. So before we press anything, the OpMode can be selected on the Driver Station right here, but it is not running yet. When we press INIT, the Driver Station calls the OpMode and its runOpMode() method. Everything above waitForStart() runs once during this part. This is normally where we prepare the program, and we might get hardware from the hardware map. We may set initial values and send a message saying that the robot is ready. For the code example later, we are not using robot hardware just for simplistic reasons. We are only using telemetry so that we can clearly see what the code is doing. But once the program reaches waitForStart(), it pauses there. It has finished its INIT work, but the active part of the program has not started yet. When someone presses the START play button on the Driver Station, waitForStart() unpauses and finishes, and the program moves into the active section. Most TeleOp code has a loop that says while opModeIsActive(). Everything inside that loop repeats over and over for as long as the OpMode remains active. So that's where we repeatedly read the gamepad, decide what the robot should do, update the motors or servos, and display telemetry. When someone presses the big STOP button on the Driver Station, opModeIsActive() becomes false. The loop ends and the program continues any cleanup code after it. So the basic model is the setup runs once, waitForStart() pauses, the active loop repeats, and STOP ends the loop. So here is the same lifecycle in an actual OpMode. At the top, TeleOp tells the FTC system that this program should appear in the TeleOp list on the Driver Station. The name that will appear is Hello TeleOp. The runOpMode() method is the main entry point. When we press INIT, the FTC system begins running this method. This first section is our INIT code. It creates a loop counter, adds some telemetry, and then calls telemetry.update(). Calling telemetry.update() sends the information to the Driver Station. If we add telemetry but never update it, then we may not actually see this new information. This code only runs once. It does not keep checking the gamepad yet. The program then reaches waitForStart() and pauses. It stays here until the OpMode is started or stopped. After START, the program reaches this loop. Every time the loop repeats, we increase the loop counter. For the sake of this demo, we just display the current phase and the number of times that the loop has run. Then we check gamepad1.a. This is checking the button's current state. If the driver is holding A, we display A is held. Otherwise we display A is not held. The important part is that this check happens again every time the loop repeats. So the program is constantly reading the newest gamepad state instead of reading it once and getting stuck with an old value. At the bottom, idle() gives the FTC system a chance to handle its other work before our loop repeats. When STOP is pressed, the loop condition, opModeIsActive(), becomes false and the program reaches the final section. Our example does not control hardware there, so there is nothing to shut down. In a real OpMode, this is where we may explicitly stop motors or perform other cleanup. So let's trace a fake match and predict what happens. First, we select an OpMode. At this point, it is listed on the Driver Station, but runOpMode() has not started. We should not see any telemetry from our code yet. Next, when we press the INIT button, the setup section runs once. The telemetry displays Phase: INIT and the program pauses at waitForStart(). Now we press the START button. The active loop begins and the first loop displays Phase: ACTIVE and Loops: 1. As the program keeps running, that number continues increasing. Now imagine that the driver holds the A button. The loop runs again, sees that gamepad1.a is true, and displays A is held. It continues displaying that message for as long as the button remains held. Finally, when we press STOP, opModeIsActive() becomes false, so the loop ends. We stop receiving new loop telemetry and the program moves to its cleanup section. So the main thing to remember is that code above waitForStart() runs once during INIT, waitForStart() pauses until the match actually starts, code inside the active loop repeats until STOP, and code after the loop is for cleanup. When you are confused about an OpMode, find those three regions first. Once you know which phase a line belongs to, it becomes much easier to predict when it will run. Next, we'll look at how the names in the robot configuration connect to hardware variables in Java.