Lesson 2.6: Choosing Your OpMode Type

Why This Choice Matters

By this point, you have seen the FTC lifecycle methods and how the SDK manages them. The next step is choosing the right class for the kind of program you are writing. This distinction matters throughout the rest of the curriculum, because the wrong OpMode type makes the code harder to control, harder to debug, and easier to misread.

Choosing Your OpMode Type

OpMode is the base class. It has init(), init_loop(), start(), loop(), and stop() lifecycle methods that are called by the SDK. You never write your own outer control loop in this model. The SDK handles the timing and repeatedly calls loop() for you.

LinearOpMode extends OpMode and gives you a single runOpMode() method. Inside runOpMode(), you control execution flow yourself using waitForStart() and while (!isStopRequested()) style logic.

The golden rule is simple:

TeleOp always uses OpMode.
Autonomous always uses LinearOpMode.

Why this rule works:

TeleOp needs the SDK's loop timing so gamepad input is refreshed correctly.
Autonomous needs sequential control flow: do this, then that, then this.

Side-by-Side Comparison

Category	`OpMode`	`LinearOpMode`
Used for	TeleOp	Autonomous
Main method	`loop()`	`runOpMode()`
Flow control	SDK handles it	You write it
Gamepad input	✅ Yes	❌ Never
Sequential steps	Awkward	Natural

Common OpMode Mistakes

Using LinearOpMode for TeleOp. This creates gamepad timing problems and usually leads to awkward control code.
Using OpMode for Autonomous. You can make it work, but writing clear step-by-step logic becomes much harder than it needs to be.
Calling gamepad1 inside a LinearOpMode autonomous program. In autonomous, the gamepad values stay at zero.
Forgetting waitForStart() in LinearOpMode. The robot can begin moving before the match officially starts.
Forgetting telemetry.update() in LinearOpMode. The Driver Station never receives the telemetry lines you added.
Putting hardwareMap.get() inside loop() or inside the body of a runOpMode() loop instead of before waitForStart(). Hardware should be mapped once, not repeatedly.

Quick Reference Card

TeleOp skeleton

@TeleOp(name="MyTeleOp")
public class MyTeleOp extends OpMode {
    DcMotor motor;

    @Override
    public void init() {
        motor = hardwareMap.get(DcMotor.class, "motor");
    }

    @Override
    public void loop() {
        motor.setPower(-gamepad1.left_stick_y);
        telemetry.addData("Power", -gamepad1.left_stick_y);
        telemetry.update();
    }
}

Autonomous skeleton

@Autonomous(name="MyAuto")
public class MyAuto extends LinearOpMode {
    DcMotor motor;

    @Override
    public void runOpMode() {
        motor = hardwareMap.get(DcMotor.class, "motor");

        waitForStart();

        // Step 1: drive forward
        motor.setPower(0.5);
        sleep(2000);

        // Step 2: stop
        motor.setPower(0.0);
    }
}

Keep this page in mind as you move into motor control, sensors, and autonomous. When a program is driver-controlled, think OpMode. When the robot is following a sequence on its own, think LinearOpMode.

Ready to move on?

Why This Choice Matters​

Choosing Your OpMode Type​

Side-by-Side Comparison​

Common OpMode Mistakes​

Quick Reference Card​

TeleOp skeleton​

Autonomous skeleton​