LinearOpMode Lifecycle

Understand init, start, active loop, and stop behavior.

Module 2: FTC SDK FoundationsCore

In this lesson, you will:

01Trace a LinearOpMode from init to stop.
02Avoid blocking code that ignores stop.
03Use lifecycle telemetry intentionally.

Concept narrative

LinearOpMode lets students write robot code as a readable sequence, but the SDK still controls the lifecycle. Code before waitForStart runs during init, code after waitForStart runs only after start, and every repeated behavior must respect opModeIsActive so the Stop button remains reliable.

This lesson should be read as a robotics lesson first and a programming lesson second. The code matters because it lets the team create repeatable behavior under match pressure. Students should slow down long enough to name the inputs, outputs, assumptions, and safety limits before they touch the robot.

Robot mental model

Imagine the robot waiting at the field wall. During init, it should map hardware, set safe positions, and report readiness. During active control, it should loop quickly. During stop, it should stop commanding motion. A match robot that ignores lifecycle boundaries is stressful and unsafe.

A good mental model gives the team a shared language. When a driver, builder, and programmer can point to the same behavior and use the same words, debugging gets calmer and code review becomes useful instead of personal.

Implementation walkthrough

Write an OpMode with explicit init telemetry, a while loop for opModeInInit if needed, waitForStart, then the active loop. Put hardware setup before start and repeated gamepad/sensor decisions inside the active loop.

Keep the implementation staged. First create the smallest version that compiles. Then add telemetry that proves it is running. Then connect one hardware device or one decision. Finally, repeat the test from a cold init so the team knows it was not a lucky hot reload.

LifecycleDemo.javaJava

telemetry.addLine("Init complete");
telemetry.update();

waitForStart();
int loops = 0;

while (opModeIsActive()) {
    loops++;
    telemetry.addData("loops", loops);
    telemetry.addData("runtime", getRuntime());
    telemetry.update();
}

Common mistakes and debugging

If the robot moves during init, hardware writes are in the wrong place. If Stop is delayed, look for sleep calls or while loops that do not check opModeIsActive. If telemetry appears only once, telemetry.update is probably outside the loop.

Use the five-value debugging habit: input, state, target, measurement, output. If one of those values is missing, add it before rewriting logic. The goal is to make the robot tell the truth about what it thinks is happening.

Checkpoint

Init telemetry appears before Start.
Loop count increases only after Start.
Stop exits promptly.

Reflection check

Check your understanding before moving on.

Why should loops check opModeIsActive?

0 of 1 answered

References

FIRST FTC DocsOfficial SDK, Robot Controller, and programming reference.Learn Java for FTCFTC-focused Java book and exercises by Alan G. Smith.Game Manual 0FTC community reference for programming, controls, and robot design.