Lesson 7.4: Debugging Name Mismatches and Configuration Problems

Technical Context

The string literal used in hardwareMap.get() must match the configuration name on the Hub character-for-character. A single typo, including a capitalization difference such as "LeftMotor" versus "left_motor", causes get() to throw during initialization. If the error is not corrected before Start, the OpMode cannot run.

How to Track Down Mapping Errors Quickly

When the SDK encounters a name mismatch, HardwareMap.get(Class, String) throws an exception; it does not return null. Because the assignment does not finish, a field may retain its earlier value, but the lookup itself failed by throwing. A later NullPointerException is possible only if code catches or bypasses that lookup failure and then dereferences a null variable. HardwareMap.tryGet(...) is the API that returns null for a missing optional device.

A useful approach is to store shared configuration names as static final String constants. If a name changes in the Robot Controller configuration, you update the matching constant instead of searching through every OpMode.

Common mismatch causes to watch for:

Capitalization differences ("Arm" vs "arm")
Spaces vs underscores ("left drive" vs "left_drive")
Trailing spaces that are easy to overlook in the configuration app
Using the Java variable name instead of the Hub config name

Annotated Code

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.hardware.DcMotor;

// A dedicated class storing all hardware configuration names as constants
// This is the single source of truth for every OpMode on the robot
public class RobotConfig {
    public static final String LEFT_DRIVE   = "left_drive";
    public static final String RIGHT_DRIVE  = "right_drive";
    public static final String LIFT_MOTOR   = "lift_motor";
    public static final String LIMIT_SWITCH = "limit_switch";
}

// Inside an OpMode's init() method: using the constants instead of literals
import org.firstinspires.ftc.teamcode.RobotConfig;

leftDrive  = hardwareMap.get(DcMotor.class, RobotConfig.LEFT_DRIVE);
rightDrive = hardwareMap.get(DcMotor.class, RobotConfig.RIGHT_DRIVE);

How a Library Makes Optional Hardware Explicit

The SDK's HardwareMap.get(...) throws when a configured name or type cannot be found. BunyipsLib deliberately catches that failure inside a nullable helper and records the bad name:

var hardwareDevice: T? = null
var ok = false
try {
    if (Storage.memory().hardwareErrors.contains(name)) return null
    hardwareDevice = getAndDynamicCast(name, device)
    if (hardwareDevice == null)
        throw NullPointerException(
            "An error occurred configuring '$name' of type ${device.simpleName}."
        )
    ok = true
} catch (e: Exception) {
    Storage.memory().hardwareErrors.add(name)
    e.localizedMessage?.let { Dbg.error(it) }
}
if (ok)
    onSuccess.accept(hardwareDevice!!)
return hardwareDevice

That null result is behavior created by this wrapper, not by HardwareMap.get(...). In ordinary SDK code, use tryGet(...) when a missing device should return null, or let get(...) fail during initialization for hardware the robot requires. Excerpted from BunyipsLib's RobotConfig.kt at a pinned commit under the MIT License.

Fill-in-the-Blank Practice

Hardware lookup strings in the get() method are __________-sensitive, meaning "Motor" and "motor" are different configuration names.
If HardwareMap.get(...) cannot find the requested device, it throws an __________.
To avoid mismatch errors across multiple files, programmers store configuration names as static final __________ variables in a shared class.

Show answers

case
exception
String

Simulator Challenge

Use the simulator below to track down a name mismatch, then refactor the correct hardware name into a shared constant.

Telemark Unit 7 Simulator

Supports multiple Java files: hover over the tabs and choose + to create a separate mechanism or configuration class, or to import existing code.

Shows mapping errors, type mismatches, direction settings, and missing initialization hints.

Best for practicing `hardwareMap.get()`, device classes, naming consistency, and mapping structure.

Ready to move on?

Only mark complete if you genuinely understand the material. Your progress will be saved in this browser.

Stuck on this lesson?

Ask about anything on this page. It can see which lesson you have open and which part you are reading.

Technical Context​

How to Track Down Mapping Errors Quickly​

Annotated Code​

How a Library Makes Optional Hardware Explicit​

Fill-in-the-Blank Practice​

Simulator Challenge​