WEBVTT 00:00.000 --> 00:06.000 You already know that the hardware map connects a name in the robot configuration to a device in Java. 00:06.000 --> 00:12.000 Let's trace one motor through that whole chain and see exactly what fails when the names don't match. 00:12.000 --> 00:17.000 On the Driver Station, open the menu and choose Configure Robot. 00:17.000 --> 00:24.000 Open the correct hub, in this case the Expansion Hub, choose Motors, and select the port where the motor is connected. 00:24.000 --> 00:28.000 This is where the configuration name is entered. 00:28.000 --> 00:32.000 The actual configuration name we are using in this example is `motorTest`. 00:32.000 --> 00:38.000 These official screenshots on the slide are only showing where the menus and name fields are. 00:38.000 --> 00:44.000 The examples may look different, and the interface can change between SDK versions. 00:46.000 --> 00:49.000 Now follow the chain from left to right. 00:49.000 --> 00:52.000 We start with the physical test motor. 00:52.000 --> 00:55.000 Its wire reaches a numbered hub port. 00:55.000 --> 00:59.000 That port has a configuration name, `motorTest`. 00:59.000 --> 01:06.000 Java asks the hardware map for a `DcMotor` with that exact name. 01:06.000 --> 01:11.000 The returned object is stored in the Java variable `testMotor`. 01:11.000 --> 01:16.000 Now, `motorTest` and `testMotor` are related, but they are not the same name. 01:16.000 --> 01:24.000 `motorTest`, inside the quotation marks, must match the Robot Controller configuration name. 01:24.000 --> 01:31.000 `testMotor`, without the quotation marks, is only the variable name used inside Java. 01:31.000 --> 01:42.000 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. 01:42.000 --> 01:51.000 We ask `hardwareMap` for a `DcMotor` named `motorTest`, and we store the result in `testMotor`. 01:52.000 --> 02:04.000 To see one mistake, we can change the quoted name from `motorTest` to `motor_test`. 02:04.000 --> 02:12.000 We can leave the type and the Java variable alone, and the code can still compile. 02:13.000 --> 02:21.000 `motor_test` is still a valid text name, but if we were to actually run this code on a robot, 02:21.000 --> 02:26.000 initialization would fail because the active configuration does not contain that exact name. 02:30.000 --> 02:36.000 This slide puts the mismatch side by side. 02:36.000 --> 02:44.000 The Robot Controller configuration contains `motorTest`, while Java is requesting `motor_test`. 02:44.000 --> 02:53.000 Those strings are not equal, and the useful evidence is the first error identifying the missing device name. 02:53.000 --> 03:01.000 Fix the one mismatched string instead of renaming unrelated variables and rewriting the motor code. 03:02.000 --> 03:11.000 We can do that quickly by switching back to Android Studio and renaming this to `motorTest`. 03:11.000 --> 03:27.000 You can see this still compiles, but we've restored the quoted name to `motorTest`, so everything there should work now. 03:28.000 --> 03:37.000 A correct lookup proves only that Java found a configured device with the requested name and type. 03:37.000 --> 03:47.000 It does not prove which physical motor is connected, which port its wire reaches, or which direction that motor should turn. 03:47.000 --> 03:50.000 Those require a physical check. 03:50.000 --> 03:55.000 We can use the symptom to choose the first layer to inspect. 03:56.000 --> 04:03.000 If initialization fails, compare the requested name and type with the configuration name and type. 04:03.000 --> 04:07.000 If the wrong device moves, inspect the port and wiring. 04:07.000 --> 04:15.000 If the correct device moves the wrong way, look at its mounting and direction. 04:15.000 --> 04:24.000 When you start wiring and programming the season robot, make a map like this for every device. 04:25.000 --> 04:37.000 Record the Java variable, exact configuration name, hub and port, physical device, and expected direction. 04:37.000 --> 04:41.000 Keep it updated whenever the wiring or configuration changes. 04:41.000 --> 04:48.000 Then you can inspect the first broken layer instead of guessing across all of them.