OpMode vs LinearOpMode

As you have discovered in the previous section, you have a choice between extending from OpMode and extending from LinearOpMode in each new OpMode that you intend to create. These options represent two different paradigms of execution flow. Whereas OpMode is inherently iterative, LinearOpMode is inherently sequential. There is no distinct advantage in either option over the other—the choice depends on how you wish to model your program.

Info

It is a wildly popular belief that OpMode corresponds with TeleOp and LinearOpMode corresponds with Autonomous. While this is the most popular method of association, it is by no means enforced. Some of the best teams in the world break this association by having their autonomous OpMode be nonlinear.

The LinearOpMode

When you first learned to code, you were probably told that a program is like a to-do list for the computer to follow step-by-step. Indeed, the public static void main method is executed in this manner. The LinearOpMode follows this pattern—much like the main method, the runOpMode method is called whenever the current OpMode is initialized from the Driver Station by pressing the INIT button. Therefore, you can treat runOpMode as the entry point of your program. The typical structure for the body of runOpMode is as follows:

1. Initialize all references to hardware
2. Wait for the Play (▶) button to be pressed on the Driver Station by calling waitForStart()
3. Run the operations of the current OpMode

The club has plenty of examples from historic code that use this LinearOpMode paradigm.

Aborting LinearOpModes

We can theoretically stop any OpMode at any time by pressing the Stop (◼) button, but how is it able to stop a blocking operation in a LinearOpMode immediately? If your code only waits for a motor to reach a specific position, it would not care whether the OpMode has stopped, and the Robot Controller app would have to forcefully abort your OpMode, causing an Emergency Stop and requiring the robot to be restarted. This issue is addressed in Stopping LinearOpModes.

The (Iterative) OpMode

Unlike the LinearOpMode, the (iterative) OpMode executes a specific method named loop repeatedly when the OpMode is running. When declaring an OpMode, you may override the following methods, shown in the order of execution in a typical OpMode lifecycle:

Function Signature	When It's Executed	Required?
public abstract void init()	Executed once immediately after a user presses INIT on the Driver Station	Yes
public void init_loop()	Executed repeatedly after a user presses INIT but before a user presses Play (▶) on the Driver Station	No
public void start()	Executed once immediately after a user presses Play (▶) on the Driver Station	No
public abstract void loop()	Executed repeatedly after a user presses Play (▶) but before a user presses Stop (◼) on the Driver Station	Yes
public void stop()	Executed once immediately after a user presses Stop (◼) on the Driver Station	No

If it makes more sense to you, you can imagine an OpMode as a LinearOpMode with the following definition of runOpMode():

public void runOpMode() {
  init();

  while (!isStarted())
    init_loop();

  start();

  while (!isStopRequested())
    loop();

  stop();
}

For conventional TeleOp, we initialize our references to hardware devices in the init() method, and we send the received gamepad values to the output devices in the loop() method. FIRST's example is an excellent reference for this paradigm.

Check your Understanding

1. How is an Iterative OpMode different from a Linear OpMode?
2. True or False: Not all autonomous OpModes have to be linear.
3. How many standard methods are in a typical Iterative OpMode?