Hello Robot - Test Bed
One of the most important steps in the engineering design process and the software development lifecycle is testing. When working with code, ensuring that it works without errors and works to the standard decided upon in the planning stage of the process is crucial. In order to ensure that the code is working as intended testing needs to be performed.
Before delving into the introduction to programming sections, Test Bed - Blocks or Test Bed - OnBot Java; its important to understand testing, the benefits of creating a test bed, the components needed for the next sections, and how to use gamepads. Follow through the rest of this section to learn more about testing!
The purpose of testing is to identify, isolate, and correct potential issues in a design before the design is put into use. Testing takes on different forms or provides different metrics for various intents in design. A mechanism, like a shooter for instance, might be tested to confirm that it is running reliably. During the planning phase of the design process you should create various performance, quality, and reliability metrics. When the design is built, or the program is written, these metrics will help you identify whether the mechanism meets the standards you expect it to. If the standards of operation are not met then the problem needs to be isolated.
In order to fix a problem in the design process, you must isolate the source of the issue. To understand how this works consider the following example:
Without more information there is not a good way to discover why the motor is not running. In order to narrow things down the different components have to be tested until the root of the issue is found. Common practice is to start with a code that is known to work, such as one of the sample codes in the SDK. If the motor still doesn't run the next thing the team should check is whether or not the wires are working as intended. One by one the team should go through and test, or troubleshoot, the different potential origins of the problem to see what is working and what isn't.
Once the source of an issue has been isolated, the issue needs to be corrected. The duration of the fix depends on the sources of the problem and how deep it runs. For instance, if an op mode doesn't work as intended the fix may be a simple change, like to the configuration file or the hardwareMap. A larger issue that requires a redesign, like a mechanism not meeting performance metrics, triggers a restart of the engineering design process.
Previously, testing was defined as the process of identifying, isolating, and correcting potential issues during the design process. This differs from troubleshooting which is the process of identifying, isolating, and correcting issues of a mechanism that went through the testing process and worked as intended.
In the troubleshooting section the examples of a cars check engine light was used. In this example, the known indicator of a failure was the cars engine light. The check engine light informs the driver that something is wrong with the car but in order to find the cause of the issue troubleshooting and diagnostic steps must be performed. To maintain that comparison, testing is what the engineers of the car use to establish the metrics of expected engine performance. If those standards are not met then the check engine light turns on to warn the driver of the issue.
One of the fallbacks to testing code in a system of components, like the REV Control System, is that there is not a guarantee that all components are functioning as they should be. For instance, if a motor on the robot isn't working there are several potentials reasons for the failure. The motor, the motor port on the Control Hub, the wire connecting the motor to the port, and the code are all potential causes of motor failure.
If a failure occurs after the Robot is assembled it can be hard to go back and make changes, or troubleshoot without having to disassemble the robot. One of the ways to plan ahead for this circumstance is to create a test bed prior to creating a robot.
A test bed is a testing environment for hardware and software components, commonly used in the engineering world. Test bed applications includes a broad range of different equipment and measurement testing. In some cases a test bed is a piece of equipment for testing a specific product, in other cases it is a system of components that create a testing environment. Regardless, the end goal of a test bed is to ensure a component is working before it is used for its intended purpose.
Creating a test bed eases the process of troubleshooting if there is a failure during code testing. The purpose of this section is to create a test bed to test basic code in the Test Bed - Blocks and Test Bed - OnBot Java sections.
The design of a test bed depends on the use case and available resources. For instance, one of the design requirements for the test bed featured below was accessibility. Notice that the placement of the hardware components on the Extrusion allows for the actuators, sensors, and Control Hub to be removed or swapped out with ease.
Another major design consideration for this test bed was that it include the common components necessary to teach users the basics of programming with the REV Control System. In this case components were chosen from the REV FTC Starter Kit.
- 1.Control Hub
- 2.REV Core Hex Motor
- 3.Smart Robot Servo
- 4.Touch Sensor
- 5.Color Sensor V3
There are other minor, but important, design considerations to make for a test bed. For example, when adding an actuator to a test bed consider the following questions:
- What level of constraint does the actuator need? One of the benefits of creating a test bed for motors, or other actuators, is that the motors can be properly constrained during the testing process. In this case providing basic motion support and constraint is valuable.
- How will you be able to tell the behavior of the actuator? The example test bed uses a wheel with a zip tie to help users visualize the behavior of the motor. Tape or other markers can be used, as well.
For the purpose of this guide a test bed similar to the example one can be built.
The Test Bed sections highlights the necessary robot components needed to learn the basic programming concepts used in the Test Bed - Blocks and Test Bed - OnBot Java sections. However, there are two more components needed to succeed in testing your code: A Driver Hub (or equivalent Driver Station Android Device) and a gamepad.
All buttons on a gamepad can be programmed to a specific task or behavior. Throughout the Hello Robot Guide you will encounter several different places where the gamepad is utilized. Knowing the general naming convention for the gamepads will help you program them correctly. The guide assumes you are using either a Logitech gamepad or a PS4 gamepad, like Etpark Wired Controller for PS4 (REV-39-1865). To understand how to program a gamepad, especially with difference in the way certain buttons are named, please see the following graphic and table, showcasing what the code lines correspond with which button.
Boolean data has two possible values: True and False. These two values can also be represented by On and Off or 1 and 0. Buttons, bumpers, and triggers on the gamepad provide boolean data to your robot. For example, a button that is not pressed will return a value of False and a button that is pressed will return the value True.
Float data is a number that can include decimal places and positive or negative values. On the gamepad, the float data returned will be between 1 and -1 for the joystick's position on each axis. Some examples of possible values are 0.44, 0, -0.29, or -1.