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.

Both base classes work with either @TeleOp or @Autonomous. A useful starting convention is:

• Use iterative OpMode when several subsystems benefit from explicit init(), start(), and loop() callbacks.
• Use LinearOpMode when a sequential-looking runOpMode() is clearer, while still keeping its active loop responsive.

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
Often used for	TeleOp and state-machine autonomous	Autonomous and TeleOp
Main method	loop()	runOpMode()
Flow control	SDK handles it	You write it
Gamepad input	Available	Available
Sequential steps	Awkward	Natural

---

Common OpMode Mistakes

1. Using a blocking loop or long sleep() in either style, which delays other subsystem updates.
2. Choosing LinearOpMode but forgetting to create a responsive active loop for continuous TeleOp controls.
3. Choosing iterative OpMode for autonomous without a state machine to represent sequential actions.
4. Forgetting waitForStart() in LinearOpMode. The robot can begin moving before the match officially starts.
5. Forgetting telemetry.update() in LinearOpMode. The Driver Station never receives the telemetry lines you added.
6. 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?

Only mark complete if you genuinely understand the material. Your progress will be saved in this browser.

Stuck on this lesson?

Ask about anything on this page. It can see which lesson you have open and which part you are reading.