opmode
We recommend using LinearOpMode as your default choice for writing robot programs because of its straightforward, sequential execution flow and its consistent usage across community resources. Game Manual 0 notes that choosing between LinearOpMode and an iterative OpMode is ultimately a matter of personal preference, but the guide itself uses LinearOpMode throughout its documentation to maintain consistency. If a team prefers a structured, event-driven approach with distinct lifecycle phases, they might choose the iterative OpMode instead .
According to the official FTC Docs, an "OpMode" (short for operational mode) is a custom computer program that defines how a competition robot behaves to complete tasks and score points during a match. These programs are loaded onto the Robot Controller and selected by the drive team using the Driver Station. Teams can write these programs using a variety of tools, including the visual Blocks Programming Tool, OnBot Java, or Android Studio. Additional introductory information on what an OpMode is can be found in the REV Robotics DUO Control System documentation for Blocks (https://docs.revrobotics.com/duo-control/hello-robot-blocks/where-to-program/what-is-an-opmode) and Java (https://docs.revrobotics.com/duo-control/hello-robot-java/where-to-program/what-is-an-opmode) .
The FTC SDK provides two primary base classes for creating these programs: LinearOpMode and OpMode. The standard OpMode class is the base for iterative, event-driven programs where the robot controller repeatedly runs a loop. The LinearOpMode class also derives from the base OpMode class but is designed for a linear, sequential flow where you cannot override the standard iterative methods directly .
When using the iterative OpMode class, the program is structured around specific methods that run at different times during the match. Game Manual 0 explains that the init() method runs once when the driver presses the initialize button, followed by init_loop() which runs repeatedly until the match starts. When the driver presses start, start() runs once, and then loop() executes continuously to control the robot until the stop button is pressed, which triggers a final single run of the stop() method. Game Manual 0 also notes that since SDK version 8.1, the delay between loop() calls is a negligible one millisecond, making its performance comparable to a linear program .
In contrast, a LinearOpMode runs sequentially within a single main method. As described in the FTC Docs, the program executes its setup steps and then must call waitForStart() to pause the robot's actions until the driver presses the start button on the Driver Station. Once started, the program typically enters a loop that continues to run as long as opModeIsActive() returns true, updating telemetry and controlling the robot until the driver presses the stop button .
When working with Blocks-based OpModes, the FTC Docs emphasize that programs edited in a web browser or the REV Hardware Client only exist temporarily in the browser's memory. To prevent losing work, programmers must actively use the save button to write the program to a permanent file on the Control Hub or robot controller phone. Once saved, these files can be selected on the Driver Station or downloaded to a computer for backup and sharing. Step-by-step guides for creating these programs are also available in the REV Robotics DUO Control System documentation for Blocks (https://docs.revrobotics.com/duo-control/hello-robot-blocks/part-1/test-bed-blocks) and OnBot Java (https://docs.revrobotics.com/duo-control/hello-robot-java/part-1/test-bed-onbot-java) .