Hardware Map and Motors
Connect configuration names to Java objects safely.
FTC SDK FoundationsCore
Connect configuration names to Java objects safely.
In this lesson, you will:
The Robot Controller app stores names for motors, servos, and sensors. Java code asks the hardware map for those names, then controls the returned objects.
If the config says frontLeft but the code asks for leftFront, the robot will not initialize. Keep names boring, consistent, and written down.
Motors on opposite sides of many drivetrains are mounted as mirror images, so the same positive power can spin their wheels in opposite robot-relative directions. Reverse whichever side your physical build requires, then verify it on blocks. The goal is simple: positive power should mean robot-forward on every drive motor.
Record each code name, hub port, physical wheel, and direction in one small table. Update the table whenever wiring or configuration changes. That artifact lets the next programmer distinguish a naming mistake from a wiring mistake without guessing.
You already know that the hardware map connects a name in the robot configuration to a device in Java. Let's trace one motor through that whole chain and see exactly what fails when the names don't match. On the Driver Station, open the menu and choose Configure Robot. Open the correct hub, in this case the Expansion Hub, choose Motors, and select the port where the motor is connected. This is where the configuration name is entered. The actual configuration name we are using in this example is motorTest. These official screenshots on the slide are only showing where the menus and name fields are. The examples may look different, and the interface can change between SDK versions. Now follow the chain from left to right. We start with the physical test motor. Its wire reaches a numbered hub port. That port has a configuration name, motorTest. Java asks the hardware map for a DcMotor with that exact name. The returned object is stored in the Java variable testMotor. Now, motorTest and testMotor are related, but they are not the same name. motorTest, inside the quotation marks, must match the Robot Controller configuration name. testMotor, without the quotation marks, is only the variable name used inside Java. To look at a code example, we want to read this line on the right, starting with the right side and then going to the left. We ask hardwareMap for a DcMotor named motorTest, and we store the result in testMotor. Just to give you an idea of what one mistake looks like, we can change the quoted name from motorTest to motor_test. We can leave the type and the Java variable alone, and the code can still compile because motor_test is still a valid text name. But if we were to actually run this code on a robot, initialization would fail because the active configuration does not contain that exact name. This slide puts the mismatch side by side. The Robot Controller configuration contains motorTest, while Java is requesting motor_test. Those strings are not equal, and the useful evidence is the first error identifying the missing device name. Fix the one mismatched string instead of renaming unrelated variables and rewriting the motor code. We can do that pretty quickly by switching back to Android Studio and renaming this to motorTest. You can see this still compiles, but we've restored the quoted name to motorTest, so everything there should work now. A correct lookup proves only that Java found a configured device with the requested name and type. It does not prove which physical motor is connected, which port its wire reaches, or even which direction that motor should turn. Those require a physical check. We can use the symptom to choose the first layer to inspect. If initialization fails, compare the requested name and type with the configuration name and type. If the wrong device moves, inspect the port and wiring. If the correct device moves the wrong way, look at its mounting and direction. When you start wiring and programming the season robot, make a map like this for every device. The goal is to record the Java variable, exact configuration name, hub and port, physical device, and expected direction. Keep it updated whenever the wiring or configuration changes. Then, when something fails, you can inspect the first broken layer instead of guessing across all of them.
DriveHardware.javaJava
DcMotor frontLeft = hardwareMap.get(DcMotor.class, "front_left_drive");
DcMotor frontRight = hardwareMap.get(DcMotor.class, "front_right_drive");
DcMotor backLeft = hardwareMap.get(DcMotor.class, "back_left_drive");
DcMotor backRight = hardwareMap.get(DcMotor.class, "back_right_drive");
frontLeft.setDirection(DcMotor.Direction.REVERSE);
backLeft.setDirection(DcMotor.Direction.REVERSE);
waitForStart();
// Robot on blocks: test one wheel, then guarantee zero output.
try {
if (opModeIsActive()) {
frontLeft.setPower(0.2);
sleep(500);
}
} finally {
frontLeft.setPower(0.0);
}Create a table with code name, Robot Controller name, hub port, wheel position, and direction for all four drive motors. Put the robot securely on blocks, then pulse one motor at a time at 20 percent power for half a second and return it to zero before testing the next motor. Record the observed wheel beside the prediction.
Check your understanding before moving on.
0 of 2 answered