Gamepad Input and Edge Detection

Read sticks, triggers, and buttons without repeated accidental actions.

Module 2: FTC SDK FoundationsCore

In this lesson, you will:

01Read analog and digital gamepad inputs.
02Use edge detection for one-shot actions.
03Design controls around driver intent.

Concept narrative

Gamepad sticks and triggers are continuous values, while buttons are booleans sampled many times per second. A held button may be true for dozens of loops, so the code must decide whether it represents a held command or a single press event.

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

Drivers think in actions: hold intake, tap score, reset heading, slow mode. Code should match that intention. Some controls should run while held; others should fire once when the button changes from false to true.

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

Copy current and previous gamepad states at the top of each loop. Use current.a && !previous.a for one-shot actions. Use current.left_bumper directly for held modes such as slow drive.

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.

EdgeDetection.javaJava

previousGamepad2.copy(currentGamepad2);
currentGamepad2.copy(gamepad2);

if (currentGamepad2.a && !previousGamepad2.a) {
    arm.goToDeposit();
}

boolean slowMode = currentGamepad2.left_bumper;

Common mistakes and debugging

Repeated scheduling, double toggles, and flickering states usually mean a one-shot action is being run as a held action. Print current, previous, and detected edge to prove the control behavior.

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

One-shot buttons schedule once per press.
Held controls behave continuously.
Telemetry can show current/previous state while testing.

Reflection check

Check your understanding before moving on.

Why keep previous gamepad state?

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.