Before you build: checklist from the rules

• Starts inside an 18 × 18 × 18 in cube (pre-loaded Pollen may stick out) — R102.
• Never grows beyond 18 × 24 in and 29 in tall, and the limit must be mechanical, not software — R105.
• Can't hold more than 4 pieces — add guards so a 5th can't get stuck on top — G407.
• Handles both 2.8 in Pollen and 3.6 in Nectar, which aren't perfectly round.
• Has a guarded top so pieces falling out of a tipped Hive don't land on it — G409.
• Rejects the other alliance's Nectar — G408.

These sketches are ideas to start your brainstorm, not official designs. For real, buildable robots with photos and CAD, see the official StarterBots below.

Why Java?

Every FTC robot runs its code on an Android-based Robot Controller, and the FTC SDK is written in Java. If your team codes in OnBot Java or Android Studio, you're writing real Java. Blocks (the drag-and-drop option) uses the exact same ideas, just as puzzle pieces instead of typed text — so everything below applies either way.

This page covers the handful of Java concepts that show up in almost every FTC program, then walks through a real, complete example. For a fuller Java course, see Learn Java Basics in the menu.

Variables — boxes that hold values

A variable has a type (what kind of value it holds) and a name you choose. FTC code uses these four constantly:

Making decisions and repeating

if / else runs code only when something is true — like keeping motor power from ever going over 1.0:

if (power > 1.0) {
    power = 1.0;
} else if (power < -1.0) {
    power = -1.0;
}

while repeats code as long as something stays true — this is how a whole OpMode keeps running:

while (opModeIsActive()) {
    // this code repeats, over and over, until the match ends
}

Methods — mini programs inside your program

A method is a named block of code you can run whenever you need it. FTC code calls methods constantly — setPower(0.5) and waitForStart() are both methods someone else wrote for you. You can write your own too:

void stopAllMotors() {
    leftDrive.setPower(0);
    rightDrive.setPower(0);
}

Call it later just by writing stopAllMotors(); — no need to retype those two lines every time.

Anatomy of an FTC OpMode

An OpMode is one robot program — a driving mode, an autonomous routine, a test. Almost every one you'll write follows this same shape:

Put it together: a simple driving program

This is a complete, working TeleOp — it reads the gamepad and drives two motors. Every FTC program you write will look a lot like this one.

Important: the names in quotes below ("left_motor", "right_motor") must exactly match the hardware configuration on the Driver Hub — rename them in your code (or rename the config) so the two agree.

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;
import com.qualcomm.robotcore.eventloop.opmode.TeleOp;
import com.qualcomm.robotcore.hardware.DcMotor;

@TeleOp(name = "TechnoBlades: Basic Drive")
public class BasicDrive extends LinearOpMode {

    private DcMotor leftDrive;
    private DcMotor rightDrive;

    @Override
    public void runOpMode() {
        // These names must match the active hardware configuration exactly
        leftDrive  = hardwareMap.get(DcMotor.class, "left_motor");
        rightDrive = hardwareMap.get(DcMotor.class, "right_motor");

        // One side of the robot is mounted backwards, so reverse it
        rightDrive.setDirection(DcMotor.Direction.REVERSE);

        telemetry.addData("Status", "Initialized");
        telemetry.update();

        waitForStart(); // wait for the "Play" button

        while (opModeIsActive()) {
            double drive = -gamepad1.left_stick_y;  // forward / back
            double turn  =  gamepad1.right_stick_x; // left / right

            leftDrive.setPower(drive + turn);
            rightDrive.setPower(drive - turn);

            telemetry.addData("Left Power", leftDrive.getPower());
            telemetry.addData("Right Power", rightDrive.getPower());
            telemetry.update();
        }
    }
}

Try changing left_stick_y to right_stick_y, or swapping drive + turn for drive - turn, and see what changes on the robot. Breaking things on purpose is one of the fastest ways to learn.

Glossary

Tips that save teams a lot of headaches

• Pull → code → commit → push, in that order, every session. Skipping the first pull is the #1 cause of conflicts.
• Only edit files inside TeamCode. Other modules are shared library code — changing them can break the build for the whole team.
• Planning something big or experimental? Ask a mentor about working in a separate branch so the code everyone else relies on keeps working.
• Check the team chat before editing a file someone else is already working on — two people editing the same OpMode at once is how conflicts happen.
• Commit and push before you pack up, even if a feature isn't finished — a small work-in-progress commit beats losing a laptop's worth of work.
• Never force-add files Android Studio generates automatically (build/, .gradle/, .idea/) — the repo's .gitignore already keeps these out of commits; if Git is trying to add them anyway, ask a mentor.
• Read the actual error message before asking for help — "it doesn't work" is much harder to debug than the red text Android Studio already gave you.
• Stuck on the same error for more than ~15 minutes? Ask for help. That's exactly what mentors and teammates are there for.
• Keep your laptop charged and bring your charger to every build session — nothing kills momentum like a dead battery mid-commit.

What is FIRST Tech Challenge?

FIRST Tech Challenge (FTC) is a robotics competition where student teams design, build and program a robot to play a brand-new game each season. At events, teams play in alliances with other teams, and they're also judged on teamwork, outreach and their engineering process, not just their robot.

This season's game is BIOBUZZ, where robots launch Pollen and Nectar into a tipping Hive and race to fill Flowers. See This Year's Challenge →

Our goals for our rookie season

• Learn the engineering design process: brainstorm, prototype, test and improve.
• Build a robot that works reliably in every match.
• Write our own autonomous code in Java.
• Keep an engineering portfolio of everything we try and learn.
• Compete at our first qualifying event and have fun doing it.
• Practice Gracious Professionalism: compete hard, help other teams, and treat everyone with respect.