Configuration is one of the most commonly misunderstood, or forgotten, steps required for programming a robot. This section sets out to explain the importance of configuration and common misconceptions of configuration by answering the following questions:

1. ​What is configuration?​

2. ​How do you configure hardware elements?​

3. ​What are common issues that are caused by a problem with the configuration file?​

The Importance of Configuration

While every REV Control Hub is the same, not every robot being controlled by a Control Hub is the same. Each Control Hub has the same number of motor ports, servo ports, digital ports, and the like, but how these ports are utilized by the individual user varies from system to system. For instance, a Color Sensor V3 may be plugged in to I2C Bus 1 on one users Hub, but another user might use the same bus to host a 2m Distance Sensor.

The Control Hub knows that there is an I2C device attached to the port. But it doesn't naturally have the information needed to translate that information to an Op Mode or tell the op mode which drivers need to be accessed in order to use this sensor. A user needs to provide additional information, so that the internal software in the Hub can take information from the Op Mode and apply it to a corresponding external hardware port and vice versa. This process is known as hardware mapping. Hardware mapping is a two step process that includes: the creation of a readable file known as a configuration file and calls to the hardware map within an Op Mode.

The Configuration File

The configuration file is a readable file created by the user through the Driver Station Application. When creating a configuration file users are required to assign the device to a port, select the type of device it is from options provided by the SDK, and give it a unique name.

Once a configuration file is saved or activated the robot will restart. This restart is so the SDK can read the file, determine what hardware is present, and add the devices to the hardwareMap class.

The Hardware Map

On the user-created-program side of the fence is the hardwareMap class. This class is where the information created in the configuration is stored for use in Blocks, OnBot Java, or Android Studio code.

The level of access or interaction a user has with they hardwareMap class depends on which programming tool they are using. Since Blocks is a collection of predetermined code snippets, it creates references to the hardwareMap whenever a variable code snippet, corresponding to an external hardware, is first referenced. However, with Onbot Java and Android Studio the reference to the hardwareMap requires that a variable be created and assigned to an external hardware unit within the hardwareMap

Configuring Common Hardware Devices

Accessing the Configuration Pages

Configuring Hardware

The following section will show how to configure components that will be used in the Test Bed. The hardware type and names have been chosen in consideration for the Hello World lesson plan. Users should heed notes within the steps to consider when creating configuration files for other instances.

Saving the Configuration File

Common Errors in Hardware Mapping

Within the programming and software world errors come in many different forms and types. When hardware mapping there are two major errors that you may run into. Both errors fall into common categories of software errors:

• ​Interface Errors - are errors between how an interface should work and how it actually behaves

• ​Runtime Errors - are errors that occur when a program is being executed

Interface Errors

Interface errors occur in the SDK when the parameters of the SDK interface are not met. In the hardware mapping process the most common interface error occurs with the Blocks Programming Tool. As mentioned in the ​Introduction to Programming section, Blocks hides complexities of the SDK library from the users. One way it does this is by automatically creating references to the hardwareMap when code snippets for an external hardware unit are used.

In order to automate the hardwareMap calls the Blocks interface reads the configuration file and creates hardware variables based off of the information it finds. For this reason it is important to create a configuration file before trying to code.

The image below shows two different interface versions of Blocks. In the version with no configuration file there are no drop down menus to access code snippets specific to actuators or sensors. In the version of the interface with a configuration file the drop down menus are present and the motor-specific code snippets are access

Runtime Errors

Within the SDK runtime errors occur during initialization or run. One of the most common runtime errors within the REV Control System is exhibited in the image below.

This error is indicative of an inconsistency between how a hardware device is called within the code and how that compares against the name used in the configuration file. There are two different ways this error can occur.

The first occurrence of this error is when there is no configuration file found. This can mean that a configuration file has not been created, a file has been created but is not active, or the wrong file is being used. When any of these instances happen the hardware map is unable to route the code to the configuration file and the error displays with the first hardware device that is called in the code.

An incorrect reference to the hardwareMap can also cause this error to occur. Unlike Blocks, OnBot Java and Android Studio require that a programmer hard code the hardwareMap call. If the reference name in the call does not correspond with the name of the device in the configuration file (it is case sensitive) the code will build without failure but the runtime error will occur. Lets use the configuration file from the previous section as an example; where there is a touch sensor named "test_touch" and a motor name "test_motor."

public class HR_test extends LinearOpMode{
    private DigitalChannel test_touch;
    private DcMotor test_motor;
    
    @Override
        public void runOpMode(){
        //get the touch sensor and motor from hardwareMap 
        test_touch = hardwareMap.get(DigitalChannel.class, "test_touch");
        test_motor = hardwareMap.get(DcMotor.class, "test_moto");
        
    }
}

Notice in the example lines of code that the hardwareMap.get() for test_motor is written as "test_moto" rather than "test_motor." When the code builds onto the robot, it does not check that the string in the get method corresponds with a valid string within the hardware. This check is done when code is run on the robot. When the communication to the hardwareMap is initiated it looks for "test_moto" and when it can not find it, it creates the runtime error referenced above.

​