Build a Reusable RobotHardware Template

A hardware class that every OpMode can trust.

Hardware EssentialsCore

In this lesson, you will:

Create a drivetrain-only RobotHardware class.
Centralize device directions and modes.
Prepare 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.

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.

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.

RobotHardware.javaJava

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

    public void init(HardwareMap hardwareMap) {
        frontLeft = hardwareMap.get(DcMotorEx.class, "front_left_drive");
        frontRight = hardwareMap.get(DcMotorEx.class, "front_right_drive");
        backLeft = hardwareMap.get(DcMotorEx.class, "back_left_drive");
        backRight = hardwareMap.get(DcMotorEx.class, "back_right_drive");

        // Example only: reverse the side your physical drivetrain test requires.
        frontLeft.setDirection(DcMotorSimple.Direction.REVERSE);
        backLeft.setDirection(DcMotorSimple.Direction.REVERSE);

        for (DcMotorEx motor : Arrays.asList(frontLeft, frontRight, backLeft, backRight)) {
            motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);
            motor.setPower(0.0);
        }
    }

    public void stopDrive() {
        for (DcMotorEx motor : Arrays.asList(frontLeft, frontRight, backLeft, backRight)) {
            motor.setPower(0.0);
        }
    }
}

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.

Practice

Write a RobotHardware class for the drivetrain. Use it from a TeleOp and an autonomous test without duplicating motor lookups.

Checkpoint

Both TeleOp and auto use the same hardware class.
Directions are set in one place.
The robot has a shared stop helper.
The test record includes the setup, prediction, and observed result.
A teammate can repeat the check from the saved evidence without guessing.

Reflection check

Check your understanding before moving on.

What must match for hardwareMap.get(DcMotorEx.class, "front_left_drive") to succeed?

The Java field name.

The motor manufacturer’s printed serial number.

The active Robot Controller configuration name.

How should a team decide which drivetrain motors to reverse?

Use the physical low-power wheel test and document the observed directions.

Reverse the left side on every robot by convention.

Reverse whichever motors have the longest cables.

0 of 2 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.