Build a Reusable RobotHardware Template

A hardware class that every OpMode can trust.

Module 3: Hardware EssentialsCore

In this lesson, you will:

01Create a drivetrain-only RobotHardware class.
02Centralize device directions and modes.
03Prepare for subsystems without overbuilding.

Concept narrative

RobotHardware is the team’s shared definition of the robot. It should map configured names once, set default hardware behavior once, and expose fields or helpers that other code can use without repeating setup.

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

Think of RobotHardware as the pit checklist in code. If a motor name, servo range, IMU orientation, or hub cache rule belongs to the whole robot, it belongs here rather than in one TeleOp.

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

Start with four drive motors, hub bulk caching, and a stopDrive helper. Add mechanisms only after each one has a test OpMode. Keep subsystem-specific behavior out of the hardware class until there is a clear owner.

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.

RobotHardware.javaJava

public class RobotHardware {
    public DcMotorEx frontLeft, frontRight, backLeft, backRight;

    public void init(HardwareMap hardwareMap) {
        frontLeft = hardwareMap.get(DcMotorEx.class, "front_left");
        frontRight = hardwareMap.get(DcMotorEx.class, "front_right");
        backLeft = hardwareMap.get(DcMotorEx.class, "back_left");
        backRight = hardwareMap.get(DcMotorEx.class, "back_right");
        for (DcMotorEx motor : List.of(frontLeft, frontRight, backLeft, backRight)) {
            motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);
        }
    }
}

Common mistakes and debugging

If one OpMode drives correctly and another does not, hardware setup is duplicated. If init fails in every OpMode, the shared contract is wrong. If one mechanism needs special rules, move those rules into a subsystem rather than bloating RobotHardware.

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

Both TeleOp and auto use the same hardware class.
Directions are set in one place.
The robot has a shared stop helper.

Reflection check

Check your understanding before moving on.

What is the most important habit in Build a Reusable RobotHardware Template?

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.