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!
Section | Goals of Section |
Learn why is one of the most important aspects of Software Development and how it differs from troubleshooting. | |
Why creating a test bed of actuators and sensors can help with programming. This test bed, or something equivalent, will be used in following sections. | |
Understanding the naming conventions for programming a gamepad. |
Keep in mind that this is the introduction to the basic programming guide. Test Best - Blocks and Test Bed - OnBot Java will walk you through the basics of programming with the REV Control System.
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:
A team has recently purchased a Control Hub and a Core Hex Motor. They plug the Core Hex Motor into the Control Hub using the correct wiring, but when they go to run their code the motor doesn't move. What is the most likely reason for this failure:
- 1.The program is the issue
- 2.The motor is the issue
- 3.The wire connecting the motor to the Hub is the issue
- 4.The Hub is the issue.
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.
When testing code do not assume that a failure is due to the mechanism rather than the code. Testing and troubleshooting, while being similar concepts, are fundamentally different. Checking the code or using a known code that works should always occur before troubleshooting components like actuators and sensors.
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
- 6.Battery
Any one of these test beds components can be swapped out for an equivalent component. For instance, if you have an Expansion Hub rather than a Control Hub. However, with an Expansion Hub you may need to consider placement for the Robot Controller Phone.
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.
For information on setting up a Driver Hub and gamepad please visits the Getting Start with Driver Hub guide.
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.
PS4 Controllers | Default (Logitech Gamepad) | Blocks | Java | Data Type |
Cross | a | | gamepad1.a | Boolean |
Circle | b | | gamepad1.b | Boolean |
Triangle | y | | gamepad1.y | Boolean |
Square | x | | gamepad1.x | Boolean |
Dpad Up | Dpad Up | | gamepad1.dpad_up | Boolean |
Dpad Down | Dpad Down | | gamepad1.dpad_down | Boolean |
Dpad Left | Dpad Left | | gamepad1.dpad_left | Boolean |
Dpad Right | Dpad Right | | gamepad1.dpad_right | Boolean |
Left Bumper | Left Bumper | | gamepad1.left_bumper | Boolean |
Right Bumper | Right Bumper | | gamepad1.right_bumper | Boolean |
Left Trigger | Left Trigger | | gamepad1.left_trigger | Float |
Right Trigger | Right Trigger | | gamepad1.right_trigger | Float |
PS | n/a | | gamepad.ps | Boolean |
Options | Start | | gamepad1.start | Boolean |
Share | Back | | gamepad1.back | Boolean |
Left Stick Button | Left Stick Button | | gamepad1.left_stick_button | Boolean |
Left Stick X Axis | Left Stick X Axis | | gamepad1.left_stick_x | Float |
Left Stick Y Axis | Left Stick Y Axis | | gamepad1.left_stick_y | Float |
Right Stick Button | Right Stick Button | gamepad1.right_stick_button | Boolean | |
Right Stick X Axis | Right Stick X Axis | | gamepad1.right_stick_x | Float |
Right Stick Y Axis | Right Stick Y Axis | | gamepad1.right_stick_y | Float |
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.
Last modified 7d ago