Simple Autonomous

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