02 / FTC Hardware Essentials

Hardware Map and RobotHardware

Build a reusable hardware class modeled after the attached RobotHardware template.

60 minCoreFTC Hardware Essentials

You will

01Map robot configuration names to Java fields.
02Set directions and zero-power behavior during init.
03Separate hardware setup from OpMode logic.

Why Hardware Map and RobotHardware matters

This lesson connects Java objects to real devices on the robot. The core idea is that configuration names, ports, directions, modes, and safe ranges are part of the code contract. If that contract is sloppy, every later TeleOp, autonomous, and control lesson becomes harder to trust.

Starting point

Configuration names are a contract

The Control Hub configuration and Java code must agree exactly. A central RobotHardware class makes that contract visible and keeps every OpMode from remapping the same devices differently.

Initialize once, then reuse

The attached template shows the right direction: motors, servos, IMU, hub modules, voltage, and subsystems are all initialized in one predictable place. Beginner teams can start with drivetrain only, then add mechanisms as needed.

Build path

Build from one device outward. Prove a motor, then a drivetrain, then a sensor, then a reusable hardware class. Each addition should have a test OpMode or telemetry checkpoint so students can identify whether the problem is code, configuration, wiring, or mechanism design.

For this specific lesson, students should first restate the goal in robot terms, then identify the value or behavior they expect to observe, then run the smallest test that proves the idea. The lesson should feel like a guided lab: predict, run, observe, explain, and only then extend.

RobotHardware.java · Java

public class RobotHardware {
    public DcMotorEx frontLeft, frontRight, backLeft, backRight;
    public List<LynxModule> hubs;

    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");

        frontLeft.setDirection(DcMotor.Direction.REVERSE);
        backLeft.setDirection(DcMotor.Direction.REVERSE);

        for (DcMotorEx motor : List.of(frontLeft, frontRight, backLeft, backRight)) {
            motor.setZeroPowerBehavior(DcMotor.ZeroPowerBehavior.BRAKE);
        }

        hubs = hardwareMap.getAll(LynxModule.class);
        for (LynxModule hub : hubs) {
            hub.setBulkCachingMode(LynxModule.BulkCachingMode.MANUAL);
        }
    }
}

Debugging and failure modes

Hardware bugs often masquerade as programming bugs. A wrong config name looks like bad Java, a reversed motor looks like bad math, and a noisy sensor looks like bad logic. Students should learn to isolate the physical device before changing higher-level robot behavior.

Checks

Every configured drivetrain motor has one matching Java field.
The left/right direction choices make forward power move forward.
Hub bulk caching is enabled for later sensor-heavy code.

Check your understanding

Module check

Why put hardware mapping in a RobotHardware class?

0 of 1 answered

References

FIRST FTC DocsOfficial FTC SDK and robot programming documentation.Game Manual 0Community FTC programming, control, and robot design reference.