LinearOpMode - MI-FTC

Navigation
Go Home	This page's OpMode counterpart	Springboard	MI-FTC Tutorials Index

LinearOpMode is a subclass of OpMode, meaning that LinearOpMode is actually implemented in terms of OpMode. This is explored more in the OpModeEquivalent sample program, but mentioning this fact right now is mostly just an excuse to link to both classes in the JavaDoc. They can both do all the same things, but many people find that their different structures cater to different use cases. Keep that in mind - don't get caught up in one! Look at both and determine which is the easiest for you to understand or, if you feel a little more brave, which is the best to use for each program.

Here is the barebones structure of a LinearOpMode (with Android Studio colorization based on site theme):


package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;

//or @Autonomous
//Change these arguments to change the appearance in the Driver Station
@TeleOp(name="", group="")
public class BoilerPlate_LinearOpMode extends LinearOpMode {

    //Declare variables (more specifically class members) here

    @Override
    public void runOpMode() {
	
        //Initialize things here
		
        waitForStart();
		
        //Code here will run only once when Start is pressed

        while (opModeIsActive()) {
		
            //Put any code here which should loop until Stop is pressed
			
            idle(); //Give the system more time to do background tasks
            //This shouldn't be necessary and isn't in the boilerplate template,
            //but try adding it if your program crashes at random just in case.
            
            telemetry.update(); //OpMode does this for you
        }
		
        //Put anything here that needs to run once when Stop is pressed
		
    }
}

That might tell you everything you need to know, but if it doesn't, we're going to walk through it.

LinearOpMode does a bit less for you than OpMode does. You may want to try calling idle() in your loop - some sources say it is needed for LinearOpModes but not for OpModes. This doesn't make sense because LinearOpModes should run in their own thread, but you can try it if you have otherwise inexplicable problems. Also, the telemetry is not automatically updated here - make sure to call telemetry.update() in your loop.

package org.firstinspires.ftc.teamcode;

This line tells the compiler that this class is part of the TeamCode package. This is important becuase only TeamCode gets built onto the device, so we need to be in that package to have our program appear on the robot controller.

import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;

These lines import the class we are going to extend, LinearOpMode, and the annotation we are going to apply above it, @TeleOp, from the parent package "opmode".

We do not have to generate these import statements ourselves. When we create the next two lines, Studio will ask us if we want it to generate the import lines for us. Press Alt+Enter to accept its help.

@TeleOp(name="", group="")

This is where the first import statement above becomes important. Notice that this line does not end with a semicolon. This is not a normal line of code. Rather, it is a directive to the compiler, telling it to handle this class in a special way (in this case, to add it to the registry of user-accessible TeleOps). Both fields are optional. If the name is omitted, the name of the class is used.

@TeleOp creates a TeleOp, while @Autonomous creates an autonomous OpMode. You can also add @Disabled below this to prevent the OpMode from being accessible on the Driver Station.

public class BoilerPlate_LinearOpMode extends LinearOpMode {

The name of the class must exactly match the name of the file you created (case-sensitive!) to not generate a build error. We are creating the class which contains our OpMode, and it extends the LinearOpMode class in the SDK so we can use or override its functions.

//Put your early stage initialization code here

This is the place to initialize all the variables you will use, notably references to hardware devices. (If you're not familiar with object-oriented programming, it looks like you're storing a hardware device, which is an object, in a variable, but really you're storing a reference to it. When later code looks at that variable, the variable tells it where the device it wants to interact with is located.)

@Override
public void runOpMode() {

We are overriding a method (a.k.a. function) contained within the LinearOpMode class. When you click the Init button to start a LinearOpMode, the robot controller calls the runOpMode() method. By default, runOpMode() just throws an InterruptedException, so we need to override it to tell the robot controller that the method actually contains this code instead.

waitForStart();

This method tells the robot controller to wait until we have pressed the Start button before running the rest of the code. Everything before this method is called runs after the Init button is pressed, and everything after it runs after the Start button is pressed.

Before you call waitForStart(), get your hardware devices from the hardwareMap and set any of their options that you need, such as motor directions.

while (opModeIsActive()) {

You do not necessarily need this loop. Especially in an autonomous OpMode, you may only want your code to run once. In that case, just put it under the waitForStart(); method, and it will run once before stopping. In a TeleOp, however, you usually want to continually poll the controllers and sensors and continue running until the Stop button is pressed. opModeIsActive() returns true from the time when the Start button is pressed until the OpMode is stopped (either because the Stop button was pressed or there was a fatal error), so any code inside this loop will run continuously until the OpMode is stopped.

idle();

The OpMode is running on its own thread, and this method causes the thread to idle for a bit to allow the system and SDK to carry out other background tasks. If you don't call this at the end of each loop, the SDK might not have enough time to do its own things, and it may crash randomly. Android should take care of this for you, but some sources suggest that it might not do a great job of it sometimes and calling this can help.

Follow the comments in the example above (also downloadable as a boilerplate template) to determine where to place the various sections of your code.

Sample Programs:

Example Mecanum TeleOp (same tab) - Provides an example of how a "mecanum" driving arrangement could be controlled
OpMode Equivalent (same tab) - Explains how the various stages of a LinearOpMode are equivalent to the various functions provided by OpMode