Write a Full Command-Based TeleOp

Capstone TeleOp that composes drive, mechanisms, and safety.

TeleOp and Driver ControlCapstone

In this lesson, you will:

Combine drivetrain and mechanism controls.
Schedule reusable commands.
Keep the loop readable.

Concept narrative

A full TeleOp should be boring to read. The main loop updates gamepad snapshots, runs the scheduler, handles drive, schedules mechanism commands, updates subsystems, and reports only useful telemetry.

Robot mental model

The robot is now a set of capabilities rather than scattered motor writes. Drive code owns movement, subsystems own mechanisms, commands request behavior, and safe state coordinates recovery.

Implementation walkthrough

Start from the working robot-centric or field-centric drive. Add command scheduler, then one mechanism command, then safe state, then driver telemetry. Do not add every mechanism at once.

MainTeleOp.javaJava

public void run() {
    previous.copy(current);
    current.copy(gamepad2);
    CommandScheduler.getInstance().run();
    driveWithGamepad(gamepad1);
    if (current.a && !previous.a) scheduler.schedule(new ArmToScore());
    robot.periodic();
    telemetry.addData("state", robot.summary());
    telemetry.update();
}

Common mistakes and debugging

If commands fight, inspect subsystem ownership. If the loop becomes unreadable, extract helpers. If telemetry is noisy, separate programmer telemetry from driver telemetry.

Practice

Build a TeleOp skeleton for your current robot with drive, one mechanism, safe state, loop rate, and command scheduling.

Checkpoint

The scheduler, drive update, mechanism update, and telemetry each run once per loop.
Released controls command zero and no long wait blocks driver input.
Drive and mechanism behavior can be tested independently before integration.
The safe-state control stops every mechanism from each named operating state.
A cold-init test record captures inputs, states, commands, outputs, and any mismatch.

Reflection check

Check your understanding before moving on.

In a command-style team architecture, what must run every TeleOp loop so scheduled commands progress?

A new HardwareMap instance.

The FTC SDK installer.

The team’s command scheduler.

Why should driveWithGamepad remain separate from an arm command’s internal logic?

It keeps concurrent subsystem responsibilities visible and testable.

The FTC SDK prohibits an OpMode from reading two gamepads.

It makes motor direction configuration unnecessary.

0 of 2 answered

References

FIRST FTC DocsOfficial SDK, Robot Controller, and programming reference.Game Manual 0FTC community reference for programming, controls, and robot design.

Write a Full Command-Based TeleOp

Capstone TeleOp that composes drive, mechanisms, and safety.

TeleOp and Driver ControlCapstone

In this lesson, you will:

Combine drivetrain and mechanism controls.
Schedule reusable commands.
Keep the loop readable.

Concept narrative

Robot mental model

The robot is now a set of capabilities rather than scattered motor writes. Drive code owns movement, subsystems own mechanisms, commands request behavior, and safe state coordinates recovery.

Implementation walkthrough

Start from the working robot-centric or field-centric drive. Add command scheduler, then one mechanism command, then safe state, then driver telemetry. Do not add every mechanism at once.

MainTeleOp.javaJava

public void run() {
    previous.copy(current);
    current.copy(gamepad2);
    CommandScheduler.getInstance().run();
    driveWithGamepad(gamepad1);
    if (current.a && !previous.a) scheduler.schedule(new ArmToScore());
    robot.periodic();
    telemetry.addData("state", robot.summary());
    telemetry.update();
}

Common mistakes and debugging

If commands fight, inspect subsystem ownership. If the loop becomes unreadable, extract helpers. If telemetry is noisy, separate programmer telemetry from driver telemetry.

Practice

Build a TeleOp skeleton for your current robot with drive, one mechanism, safe state, loop rate, and command scheduling.

Checkpoint

The scheduler, drive update, mechanism update, and telemetry each run once per loop.
Released controls command zero and no long wait blocks driver input.
Drive and mechanism behavior can be tested independently before integration.
The safe-state control stops every mechanism from each named operating state.
A cold-init test record captures inputs, states, commands, outputs, and any mismatch.

Reflection check

Check your understanding before moving on.

In a command-style team architecture, what must run every TeleOp loop so scheduled commands progress?

A new HardwareMap instance.

The FTC SDK installer.

The team’s command scheduler.

Why should driveWithGamepad remain separate from an arm command’s internal logic?

It keeps concurrent subsystem responsibilities visible and testable.

The FTC SDK prohibits an OpMode from reading two gamepads.

It makes motor direction configuration unnecessary.

0 of 2 answered

References

FIRST FTC DocsOfficial SDK, Robot Controller, and programming reference.Game Manual 0FTC community reference for programming, controls, and robot design.