WEBVTT 00:00:00.000 --> 00:00:05.508 Okay, now that we have Android Studio set up and can connect to the Control Hub, we should 00:00:05.508 --> 00:00:12.408 probably talk about what the code we're opening actually does. So in FTC, the programs that appear 00:00:12.408 --> 00:00:17.908 on the Driver Station are called OpModes, and the important thing is that an OpMode 00:00:17.908 --> 00:00:22.888 does not run all of its code at once. Different parts run during init, after start, 00:00:22.888 --> 00:00:33.728 and after stop. So let's map that out first. So before we press anything, the OpMode can be 00:00:33.728 --> 00:00:40.128 selected on the Driver Station right here, but it is not running yet. When we press init, 00:00:41.248 --> 00:00:50.888 the Driver Station calls the OpMode and its runOpMode() method. Everything above waitForStart() 00:00:50.888 --> 00:00:59.228 runs once during this part. This is normally where we prepare the program, and we might get hardware 00:00:59.228 --> 00:01:05.288 from the hardware map. We may set initial values and send a message saying that the robot is ready. 00:01:05.988 --> 00:01:10.728 For the code example later, we are not using robot hardware just for simplistic reasons. 00:01:11.028 --> 00:01:15.768 We are only using telemetry so that we can clearly see what the code is doing. 00:01:15.768 --> 00:01:23.768 But once the program reaches waitForStart(), it pauses there. It has finished its init work, 00:01:24.108 --> 00:01:31.368 but the active part of the program has not started yet. When someone presses the start play button on 00:01:31.368 --> 00:01:39.548 the Driver Station, waitForStart() unpauses and finishes, and the program moves into the active 00:01:39.548 --> 00:01:48.548 section. Most TeleOp code has a loop that says while opModeIsActive(). Everything inside that loop repeats 00:01:48.548 --> 00:01:55.548 over and over for as long as the OpMode remains active. So that's where we repeatedly read the gamepad, 00:01:55.548 --> 00:02:02.548 decide what the robot should do, update the motors or servos, and display telemetry. When someone presses the big stop 00:02:02.548 --> 00:02:10.888 button on the Driver Station, opModeIsActive() becomes false. The loop ends and the program continues 00:02:10.888 --> 00:02:25.348 any cleanup code after it. So the basic model is the setup runs once, waitForStart() pauses, and the active 00:02:25.348 --> 00:02:39.348 loop repeats, and stop ends the loop. So here is the same lifecycle in an actual OpMode. At the top, TeleOp tells the FTC 00:02:39.348 --> 00:02:47.108 system that this program should appear in the TeleOp list on the Driver Station. The name that will appear is 00:02:47.108 --> 00:02:56.868 hello TeleOp. So the runOpMode() method is the main entry point. When we press init, the FTC system begins 00:02:56.868 --> 00:03:04.948 running this method. So everything above here. So this first section is our init code. It creates a loop 00:03:04.948 --> 00:03:11.428 counter, adds some telemetry, and then calls telemetry.update(). Calling telemetry.update() sends the 00:03:11.428 --> 00:03:20.148 information to the Driver Station. If we add telemetry but never update it, then we may not actually see 00:03:20.148 --> 00:03:30.388 this new information. This code only runs once. It does not keep checking the gamepad yet. So the program 00:03:30.388 --> 00:03:35.428 then reaches waitForStart() and pauses. It stays here until the OpMode is started or stopped. 00:03:35.428 --> 00:03:45.348 So after start, the program reaches this loop. Every time the loop repeats, and we increase the loop counter. 00:03:46.548 --> 00:03:51.988 For the sake of this demo, we just display the current phase and the number of times that the loop has run. 00:03:52.548 --> 00:04:00.148 Then we check gamepad1.a. This is checking the button's current state. If the driver is holding A, 00:04:00.148 --> 00:04:09.108 we display, A is held. Otherwise we display, A is not held. The important part is that this check happens 00:04:09.108 --> 00:04:17.028 again every time the loop repeats. So the program is constantly reading the newest gamepad state 00:04:17.028 --> 00:04:24.708 instead of reading it once and getting stuck with an old value. At the bottom, idle() gives the FTC system a 00:04:24.708 --> 00:04:34.308 chance to handle its other work before our loop repeats. And so when stop is pressed, the loop condition, 00:04:34.308 --> 00:04:42.228 opModeIsActive(), becomes false and the program reaches the final section down here. Our example does 00:04:42.228 --> 00:04:49.268 not control hardware there, so there is nothing to shut down really. In a real OpMode, this is where we may 00:04:49.268 --> 00:04:58.948 explicitly stop motors or perform other cleanups. So let's trace a fake match and predict what happens. 00:04:59.508 --> 00:05:08.148 First, we select an OpMode. At this point, it is listed on the Driver Station. So right here, 00:05:08.148 --> 00:05:13.508 that's where we select, but runOpMode() has not started. We should not see any telemetry from our code 00:05:13.508 --> 00:05:23.188 yet. Next, when we press the init button, what should happen? Well, the setup section runs once. So this setup 00:05:23.188 --> 00:05:35.588 should all run. The telemetry displays Phase: INIT and the program pauses at waitForStart(). Now we press the 00:05:35.588 --> 00:05:48.068 start button. The active loop begins and the first loop displays Phase: ACTIVE and Loops: 1. As the program 00:05:48.068 --> 00:05:53.428 keeps running, that number continues increasing. Now imagine that the driver holds the A button, 00:05:55.108 --> 00:06:01.828 then the loop runs again, sees that gamepad1.a is true, and displays A is held. 00:06:01.828 --> 00:06:11.188 It continues displaying that message for as long as the button remains held. Finally, when we press STOP, 00:06:12.868 --> 00:06:19.588 opModeIsActive() becomes false, so the loop ends. We stop receiving new loop 00:06:19.588 --> 00:06:27.428 telemetry and the program moves to its cleanup section down here. So the main thing to remember is that 00:06:27.428 --> 00:06:35.668 code above waitForStart() runs once during init, and waitForStart() pauses until the match actually starts. 00:06:36.308 --> 00:06:42.948 Code inside the active loop repeats until stop, and code after the loop is for cleanup. When you are 00:06:42.948 --> 00:06:49.908 confused about an OpMode, find those three regions first, and once you know which phase a line belongs to, 00:06:49.908 --> 00:06:56.068 it becomes much easier to predict when it will run. Next, we'll look at how the names in the robot 00:06:56.068 --> 00:06:59.268 configuration connect to hardware variables in Java.