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

This section will walk through building a test bed and the basics of testing.

Section

Goals of Section

Test Bed

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.

Testing Basics

Learn why is one of the most important aspects of Software Development and how it differs from troubleshooting.

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.

Test Bed

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.

Creating a Test Bed

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.

Testing Basics

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. However, the issue may be larger like a mechanism or code that does not meet the performance metrics. Once the core of a larger issue has been found you may need to go back through the engineering design process to address it.

Testing vs. Troubleshooting

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.