FTC Launchpad · Programming

Programming walkthrough

Configure first OpModes Driver + robot

This page is run the robot safely: configuration → OpMode → tele-op → debug. Vocabulary (OpMode, autonomous, tele-op, Blocks vs Java) lives in Code + build.
Always have a mentor the first time code runs on hardware.

Terms for this walkthrough

Configuration — device names + ports on the robot; code must match.
OpMode — one runnable program (tele-op, auto, test).
Init vs loop — setup once, then repeat while the OpMode runs.
Telemetry — values on the driver station for debugging.

Step A — Physical setup before code

Battery charged, robot on blocks if needed, Wi‑Fi or USB link per team practice.
In FTC Docs: follow Configure hardware so each device appears in the configuration file with a clear name (e.g. left_drive).

Step B — Blocks path (beginner-friendly)

What to build first

Open the Blocks editor from the programming tools (see FTC Docs).
Create a new OpMode — name it like TeleOp_Basic.
In the loop: read a gamepad stick (e.g. left stick Y).
Map that value to motor power for one side of the drivetrain (power is usually −1.0 to 1.0).
Add telemetry to print the stick value so you can see it change.
Run on the robot with a mentor—wheels should respond slowly at first.

Tip: get one motor turning correctly before wiring up all four.

Full Blocks walkthrough: FTC Docs — Blocks tutorial (also linked from Code + build).

Step C — Java path (OnBot or Android Studio)

Big picture

Your OpMode is a class that extends something like LinearOpMode.
hardwareMap — look up devices by the names from configuration.
runOpMode() — your main method: wait for start, loop in tele-op, etc.

Pseudo-structure (don’t copy blindly—learn with a mentor)

// After hardware is configured with names "left_drive", "right_drive":
// In runOpMode():
//   waitForStart();
//   while (opModeIsActive()) {
//     double drive = -gamepad1.left_stick_y;
//     left_drive.setPower(drive);
//     right_drive.setPower(drive);
//     telemetry.addData("stick", drive);
//     telemetry.update();
//   }

Tutorials: OnBot Java · Android Studio (also on Code + build).

Step D — Autonomous (next skill)

Start with time-based moves (drive 0.5 power for 0.4 seconds) — straightforward to test and a solid foundation.
Later add sensors (encoders, IMU) so the robot corrects itself—follow FTC Docs “sensors” sections.

Step E — Debug like a programmer

One change at a time — if something breaks, undo the last edit.
Telemetry first — print values before guessing.
Ask clearly: “Motor name in config is X, but null pointer in code” — mentors help faster with specifics.

Localization & sensors

Knowing where your robot is on the field makes autonomous reliable. Sensors feed that information to your code.

Common FTC sensors

IMU (Inertial Measurement Unit) — built into the Control Hub. Measures rotation (heading/yaw). Used to drive straight and for field-centric control.
Encoder — built into most FTC motors. Counts shaft rotations so you know exactly how far a wheel or mechanism moved.
Color sensor — detects surface color or reflected light. Used to detect field elements, line-follow, or detect game piece presence.
Distance sensor (ToF) — time-of-flight laser. Measures distance to walls or game elements; useful for alignment.
Camera / AprilTag — FTC uses AprilTag markers on field elements. The SDK has built-in vision processors so you can read tag ID and estimate robot pose without external libraries.

Dead reckoning with encoders

Track (odometry) your position by counting encoder ticks:

Measure your wheel circumference (diameter × π).
Know your encoder ticks-per-revolution (check motor datasheet — often 537.7 PPR for goBILDA 312 RPM).
Distance traveled = (ticks / PPR) × circumference.
Works well on smooth surfaces; accumulates error over time — reset at known field landmarks.

AprilTag localization (FTC SDK)

The FTC SDK (v8.2+) includes AprilTagProcessor — no extra libraries needed.
Returns a AprilTagDetection with ftcPose: x, y, z offsets and bearing to the tag.
Cross-reference tag ID (from Game Manual) with its known field position to get absolute robot position.
Use this to correct accumulated odometry drift when you drive past a tag — the vision measurement resets your position estimate.

IMU-assisted straight drive (code sketch)

// keep robot pointed at target heading while driving
double targetHeading = 0; // degrees
while (opModeIsActive() && !isAtTarget()) {
  double error = targetHeading - imu.getZAngle();
  double correction = error * 0.02; // tune Kp
  leftPower  = DRIVE_SPEED + correction;
  rightPower = DRIVE_SPEED - correction;
  setMotors(leftPower, rightPower);
  telemetry.addData("Heading error", error);
  telemetry.update();
}

This is a simple P-controller. You'll tune Kp by running the robot and observing drift.

Your programming checklist

Configuration on the robot matches names in code.
Ran a tiny OpMode that only does telemetry (no motion).
Ran tele-op that moves one motor safely.
Explained to a mentor what init vs loop does in your program.
Looked up one error message in FTC Docs or asked with a screenshot.

Official references

FTC Docs — programming indexAll tracks GM0 — GamepadButtons & sticks GM0 — TelemetryDebug output

Programming concepts (loops, logic): see Code + build and GM0 fundamentals.

Always follow safety rules — they exist to protect people and equipment.
Your lead programmer / coach approves what runs at competition.

← CAD Programming For parents →