WEBVTT 00:00:00.070 --> 00:00:05.044 So, you already know how the drivetrain turns joystick inputs into four wheel commands. 00:00:05.044 --> 00:00:12.150 Let's reuse those same commands to build the smallest auto that is actually useful: driving forward, pausing, turning, and stopping. 00:00:12.150 --> 00:00:19.050 So, if we look here, this routine has five visible steps. 00:00:19.050 --> 00:00:25.980 So after it starts, it drives forward for at most one second, it commands the drive motors to zero, 00:00:25.980 --> 00:00:32.910 waits for three tenths of a second, turns for at most half a second, and commands zero again. 00:00:32.910 --> 00:00:37.777 So the power and time values on this slide are only teaching example values. 00:00:37.777 --> 00:00:44.730 They make the sequence easy to read, but they do not tell us how far your robot will actually move. 00:00:44.730 --> 00:00:51.431 So, battery voltage, uh, weight, wheels, and the floor all change the physical result. 00:00:51.431 --> 00:00:56.218 And the important part is the shape of the routine. 00:00:56.218 --> 00:01:06.270 Every movement is short, every step has a name and command, and zero output appears between movements and at the end. 00:01:07.950 --> 00:01:13.170 So to show a bit more of the code side, here's the same sequence in Java. 00:01:13.170 --> 00:01:22.203 The four names at the top are placeholders for this example, not names you have already established on the robot. 00:01:22.203 --> 00:01:29.430 And before anyone enables the file, replace them with your actual configuration names and motor directions. 00:01:29.430 --> 00:01:34.290 Also check your power values and test setup. 00:01:34.290 --> 00:01:43.530 But yeah, so after our waitForStart, we return immediately if a stop was requested on the driver controller. 00:01:43.530 --> 00:01:55.290 So, we then have a try block, and try basically just runs the forward step, the pause, and the turn step in order. 00:01:55.290 --> 00:02:02.795 And then between those steps, we have a check to see if the OpMode is still active before continuing. 00:02:02.795 --> 00:02:09.510 And the helper receives a step name, four wheel commands, and a maximum time, as seen here. 00:02:09.630 --> 00:02:20.370 So, while the OpMode is active and time remains, it sends those commands and publishes the current step and elapsed time to telemetry. 00:02:20.790 --> 00:02:31.710 So when either condition up here becomes false, the helper exits immediately, and then moves down a line and calls stopDrive. 00:02:31.710 --> 00:02:40.230 That means the one-second value is a maximum, not a promise to keep driving after STOP. 00:02:40.230 --> 00:02:43.794 And the outer finally block calls stopDrive one more time. 00:02:43.794 --> 00:02:51.990 That gives the complete routine one obvious final cleanup path, even if the driver presses STOP or a later edit throws an error. 00:02:51.990 --> 00:03:01.590 So, COMPLETE is only published after every step with the, uh, while the OpMode is still active. 00:03:02.190 --> 00:03:07.350 Follow basically one moving step around this loop at a time. 00:03:07.350 --> 00:03:11.392 First, you should just ask whether the OpMode is still active. 00:03:11.392 --> 00:03:13.230 That's the most important condition. 00:03:13.230 --> 00:03:15.133 Basically in FTC LinearOpModes. 00:03:15.133 --> 00:03:19.890 And then ask whether the step still has time remaining. 00:03:19.890 --> 00:03:27.630 So only when both of those answers are yes do we command power and repeat the whole loop. 00:03:27.630 --> 00:03:35.310 Um, if the driver presses STOP, or if the timer reaches its limit, then the next command is zero. 00:03:35.310 --> 00:03:39.870 The two exits have different reasons, but neither of them leaves the drivetrain running. 00:03:39.870 --> 00:03:47.430 Telemetry shows the current step, um, and the routine runs and reports COMPLETE only at the normal end. 00:03:47.430 --> 00:03:54.210 And if the run stops early, then the last visible step tells us whether it was driving forward, waiting, or turning. 00:03:54.690 --> 00:03:59.117 So when testing a timed auto like this, um, it's a baseline. 00:03:59.117 --> 00:04:01.699 It's not precision control by any means. 00:04:01.699 --> 00:04:04.650 So we want to test it three times. 00:04:04.650 --> 00:04:09.810 We just need to start from the same mark and run it three times, 00:04:09.810 --> 00:04:14.970 record starting voltage, the last reported step, and whether the robot finished. 00:04:14.970 --> 00:04:20.730 We also want to record whether the final command returned to zero. 00:04:20.730 --> 00:04:28.590 If the three endpoints spread too far apart for the task, increasing the time is not a real fix. 00:04:28.590 --> 00:04:36.450 Keep the sequence correct, but move that movement toward encoder or Road Runner feedback when the team is ready. 00:04:36.450 --> 00:04:42.450 This whole setup is just a means to get you guys off the ground. 00:04:42.450 --> 00:04:46.042 Um, time-based is not precision control in any form. 00:04:46.042 --> 00:04:51.630 It is just a way to control your bot that is very, very simple. 00:04:51.630 --> 00:04:55.890 And so this is what you should ideally start out with. 00:04:55.890 --> 00:05:00.335 And then once you find other paths that are down the road, they're going to be more precise. 00:05:00.335 --> 00:05:02.310 And so you can migrate away from this.