Now that we have our Control System all set up and ready to program it's time to get a full robot running, right?

While we will be getting motors moving and sensors sensing during this section, it's important that we first start small. In this section, we'll be working with a simple test bed as we breakdown how to program some of the components that can be connected to the Control Hub.

By tackling these components individually we'll be able to explore more of their capabilities, common uses, and discuss errors that may occur while working with a full robot.

Quick Check!

As mentioned, during this section we will be focus first on the concept of testing. Why do you think testing might be important in robotics?

Building a Test Bed

One of the best practices to get into the routine of is testing all your components individually when they are first received. That's where out test bed comes into play. For our test bed we will be sticking to the basics with our components connected directly to our Control Hub rather than something like a Servo Power Module or Expansion Hub. If desired, we could add some mechanical parts, such as a servo horn or wheel, to aid with visualizing our testing, but this is not required.

in this tutorial we'll be using our test bed to learn about programming basics, however it is highly encourage to maintain a test bed for future testing.

To create our test bed for this tutorial you will need the following. The names we used in our configuration are included:

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 here 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.

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.

The time has come to create our first OpMode. We want to make sure to choose a clear and unique name each time we make a program. This will help us to find it again later or to communicate with teammates who may also be driving the robot.

In the programming world, there are common naming conventions that have been established to denote variables, classes, functions, etc. OpModes share some similarities to classes, a program-code-template. Thus the naming convention for OpModes tends to follow the naming convention for classes, which has the first letter of every word is capitalized.

To start, in the REV Hardware Client, select the "Program and Manage" menu tab. In the upper left-hand corner of there is a "Create New OpMode" button, click it:

Clicking the "Create New OpMode" button will open a new window to name and, if applicable, select a sample template for a program. For this guide use the default "BasicOpMode" sample and name the OpMode HelloRobot_TeleOp as shown in the image below.

Telemetry is the process of collecting and transmitting data. In robotics ,telemetry is used to output internal data from the actuators and sensors to the Driver Hub. It is a way for the robot to communicate back to you the programmer what the robot thinks its doing or seeing. This information can then be used to improve your code, make adjustments to a mechanism, or to strategize when driving around the field if competing.

Telemetry blocks in Blocks can be found under the Utilities dropdown menu:

The most useful telemetry from the servo is the position of the servo along its 270° range.

From the telemetry menu, select the block.

Drag the block and place it beneath the if/else if block set. In this scenario, we want our telemetry to be constantly providing output rather than waiting for a designated check.

Let's start by getting a motor spinning automatically when we hit play on our program!

From the DcMotor menu in Blocks select the block .

Add this block to the OpMode within the while loop. In this scenario we want our motor to continually run so long as our OpMode is active:

Select Save OpMode in the upper lefthand corner of the programming interface.

Try running this OpMode on the test bed and consider the following questions:

We are going to add several telemetry blocks within our program, but let's start by having our robot tell us how much red, green, or blue it sees when looking at an object with our Color Sensor.

For this we will be using the block from the Telemetry menu. We will need three in total, one for each color, which will be entered in the "key".

The "precision" on the block will be changed to 3. Precision sets the number of decimal places!

To "number" we will add the appropriate block from the "Color" menu:

To add telemetry for hue, saturation, and value we will repeat most of the previous process. However, for "number" we will snap in the matching variable block.

Recall that telemetry is the process of collecting and transmitting data. There is a lot of useful information our motors could send back to us, but to start let's have it output the power based on the joystick's movement.

Similar to what we did for our servo program, let's add a block from the telemetry menu to the end of our loop:

From the DcMotor menu pullout the block . Drag the block and attach it to the number parameter on the telemetry blocks.

Change the key parameter to "Motor Power"

When the OpMode is run the telemetry block will display the current power based on the joysticks movement. Give it a try!

What is a Motor?

Just like servos, a motor is a form of actuator. You may picture a dozen different things when you think of a motor, from those used to spin the wheels of a car to the large turbines that allow a plane to fly. For our robots, we will be focusing on DC motors. These are a type of electrical motor that use direct current, or DC, to rotate and produce the mechanical force needed to move an attached mechanism.

Most standard motors are able to continuously rotate in either direction with an adjustable speed or power. Some motors may also include a built in encoder, which allows them to move to a specified position, similar to a servo, or to collect data like the number of completed rotations!

To access the motor snippets in Blocks we need to look under the Actuators dropdown menu:

You may notice there are several options for blocks under the DcMotor menu. For Hello Robot we will be using those found in the DcMotor menu itself and under Dual.

As the name suggests, the blocks found under Dual are intended for the use of two motors. We will learn more about them in !

In the next few sections, we will be learning to program our motor to first move automatically in different directions then in response to our gamepad inputs. In our final section we will take a look at using telemetry with our motor's built in encoder.

Below is a sneak peek of our final full code:

Driving Motors with the Gamepad

In the previous section you learned how to set the motor to run at a specific power level in a specific direction. However, in most applications, it will be necessary to control the motor with a gamepad, to easily change the direction or power level of a mechanism.

We are able to use a button to set the motor to a specific power or we can program it so it changes based on the direction of one of the gamepad's joysticks!

From the Gamepad Menu in Blocks select the Block.

When using Blocks we are able to snap some blocks together.

Looking at the block you might notice it is the perfect shape to snap into the end of block, over the 1, like a puzzle piece!

This set of blocks will now continually loop and read the value of gamepad #1’s left joystick (the y position) and set the motor power to the Y value of the left joystick.

Save your OpMode and test it out with your gamepad! Think about the following questions while testing:

• What happens when you move the left joystick up a small amount versus a large amount?

• What happens if you move the joystick to the left or right along the X-axis?

• What happens if you move the joystick at a diagonal or rotate it 360 degrees?

You may notice that when moving along the X-axis nothing happens at the moment. However, once the joystick hits an angle near the Y-axis vertices the motor may start to jitter and spin.

When you tested your program, did the motor spin the expected direction while moving the joystick up or down?

In the FTC SDK for most controllers the Y value of a joystick ranges from -1 when a joystick is in its topmost position, to +1 when a joystick is in its bottommost position.

That may be a little confusing to control, but we can add a negative symbol, or negation operator, to the line of code to change the direction of the motor in relation to the gamepad.

From the Math Menu in Blocks select the block in the image below.

Drag the negative symbol block so it snaps in place between the and blocks:

We've asked our robot to gather a lot of data with the color sensor. Now let's have it use that information to output an actual color name rather than just a value!

Detecting Common Colors

Recall when we learned about using if/else statements while working with the touch sensor.

Let's first set up the skeleton of our if/else statement for determining different colors:

Once we've added our block we'll click the gear to add the needed "else if" pieces to have enough for all our colors. To each we will add a block from the Logic menu. Next we can add our variable and a block to each side of this logic statement. We want for each if/else our robot to check if the read hue is LESS THAN a set number!

Last we can add our telemetry for our robot to read out information to the Driver Hub based on what it detects:

Each check will be for a certain color that is within the specified range. "Key" can be changed to "Color" on the telemetry blocks. We can add the colors in first:

Next we will add our values for the hue ranges. For example, a color that's hue is between 90-149 should appear as green.

The exact hue values may need to be adjusted slightly, but those used above are based on the default conversion of HSV to RGB when using hue to identify color.

You'll notice that "red" is detected for values under 30 and above 350. This is intentional as red is the beginning and end of the RGB spectrum!

Let's snap our If/Else statement into our loop below the "Alpha" telemetry call.

Save your OpMode and give it a try! You can adjust the values as you need to better reflect the colors available or changes due to lighting in the room.

During the process of creating an OpMode, the Blocks tool prompted the selection of a sample code. In Blocks, these samples act as templates, providing the blocks and logical structure for different robotics use cases. In the previous section, the sample code BasicOpMode was selected. This sample code, seen in the image below, is the structural shell needed in order to have a working OpMode.

An OpMode can often be considered a set of instructions for a robot to follow in order to understand the world around it. The BasicOpMode provides the initial set of instructions that are needed in order for an OpMode to properly function.

Though this sample is given to users to reduce some of the complexities of programming as they learn; it introduces some of the most important code blocks. Let's take a closer look at some of them!

Comments are blocks of code intended to help you the programmer.

Let's start by reviewing how to access servos within Blocks. At the top of the Categorize Blocks section there is a drop down menu for Actuators. When the menu is selected it will drop down two choices: DcMotor or Servo. Selecting Servo will open a side window filled with various servo related blocks.

Let's start by programming our servo to rotate to the default 1 position!

From the Servo menu, we will primarily be using the block

Add this block to the op mode code within the .

Click on the number block to change from to .

What is a Servo?

A servo is a form of actuator or a device designed for moving. With a typical servo, you can specify a target position. The servo will turn its motor shaft to move to the target position, and then maintain that position, even if moderate forces are applied to try and disturb its position.

For Hello Robot we will be using the Smart Robot Servo, which is able to switch between a continuous and angular mode.

• Continuous mode allows for the servo to rotate a full 360°, either direction, indefinitely similar to a standard motor.

• Angular mode sets the servo to move to specified positions within a 270° range of motion.

Let's take a look at how to program our servo while it is on angular mode:

While most common servos have a range of 180° for motion, the Smart Robot Servo has a range of 270° due to its ability to switch between modes. When programming this means our 0 and 1 position might be a little different than what you'd expect.

Looking at the image above we can see that on default when asking our servo to move to its position 0 it will be at -135° . On the opposite end, moving to its position 1 takes our servo to +135° . Therefore if we wanted to return to 0° we would need to program it to move to its position 0.5.

Let's review quick our basic positions:

Based on what we've learned so far, think about the following two questions:

1. If we wanted our servo to move to -67.5° what position would we program it move to?

2. If we have programmed our servo to move to position 0.7, what would that equal in degrees?

In the next few sections, we will be learning to program our servo to first move automatically to different requested positions then in response to our gamepad's input.

Below is a sneak peek of our final full code:

Touch Sensor Basics

Let's start by breaking down how a touch sensor works at its core!

The information collected by a touch sensor comes in two states, also known as binary states. This information is perfect to use with a conditional statement like an if/else statement.

The block collects the binary TRUE/FALSE state from the touch sensor and acts as the condition for the if/else statement.

Let's take a look at our touch sensor block paired with our block:

Take a moment to think what this code is asking the robot to do. We could read this line of code as "If the touch sensor is pressed do ____, else if the touch sensor is not pressed do _____."

It's always helpful for us to be able to see what the robot thinks its doing on our Driver Hub's screen. To do this, let's request the robot shares some telemetry data while our program is active.

We can access the "Telemetry" blocks under our "Utilities" dropdown on the menu. Look for the block to be added in each section of the if/else statement.

What happens if you run the program right now?

When on the default "Telemetry" block the information provided is not helpful for the robot to communicate with us. Therefore we need to change "key" and "text" to match the desired information.

The "key" should be something related to which sensor, motor, or other device we are receiving information from. Meanwhile "text" will tell us what is happening based on the state of our touch sensor and our if/else statement.

Let's give our code another try to see what happens on the Driver Hub's Screen. Did you see something like the following?

Remember its up to us to decide what our telemetry readout says. With that in mind we could change it so our robot says "Hello World" when the button is pressed:

At the moment, our robot does not have any senses to help navigate the world around it like you might. However, that's the key advantage to adding sensors to our design.

For the touch sensor, one of the most common uses is for it to act as a . This will help the robot know when it needs to halt the movement of a mechanism, like an arm or lift, that's at its limit similar to how your nerves help to tell your brain to do the same.

We can test this idea by adding on to our existing if/else statement. This time we are going to ask our motor to move until our sensor is pressed using the block:

In the above example the if/else is checking first for if the touch sensor is pressed. The full statement could be read as "If the touch sensor is pressed set the motor's power to 0 else, if it is not pressed, set the power to 0.3".

There may be situations where we want our program to read if the touch is NOT pressed first. Let's take a quick look at how that would function using the block from the "Logic" menu.

Give it a try!

Color Sensor Basics:

While a touch sensor features a physical switch to gather information, a color sensor makes use of reflected light. By doing so it collects different data to determine how much light it is seeing, the distance to a surface, and of course what color is in front of it.

But what makes up a color?

For our robot we're going to focus on a few key components: hue, saturation, and value. With these we can use something known as the HSV color model to have the robot translate what its seeing into a recognizable color.

HSV is a form of a cylindrical RGB color model used to do things like create color pickers for digital painting programs, to edit photos, and for programming vision code.

Hue, saturation, and value all will play a part in helping our robot tell us what color it detects and allow us to make adjustments for something like a uniquely colored game piece!

Detecting Light vs. Dark

Before we tackle colors, let's start with having our robot use the color sensor to tell us how much light is being reflected.

To start, let's grab a block to add to our loop. Our "key" should be set to "Light detected":

To the "number" place we will pull a block from the color sensor menu:

Time to test your program to see what your color sensor detects! While testing think about the following questions:

• Is the number higher when less or more light is detected?

• What happens when the color sensor looks at different color surfaces?

• Does the value change when turning the color sensor's LED light on or off?

Let's start by establishing a few variables in our program.

We'll be going over is in more detail during Part 2: Robot Control, but for this example we are using them to help our robot translate the data it records more clearly. Our variables will be called "color", "hue", "saturation", "value", and "normalizedColors".

We've discussed how most of these are related to the HSV color model, but what about normalizedColors?

Color Normalization is another technique within vision programming intended to help compensate for differences caused by lighting and shadows when looking at colors. This also affects shades of a color. For example, there are a ton of different shades of blue, such as cyan, navy, and aquamarine, but to our robot these will all be referenced as blue.

Now that we've named our variables, we need to set them to different values.

From our variable menu we need a block. From the dropdown menu, we can change it to "normalizedColors". Next we will snap it in place with a block from the Color Sensor menu below our light detecting telemetry:

Next, let's go ahead and add set blocks for all our variables:

To each we can connect their corresponding block from the Color menu under Utilities:

Next we need to change our variable name from the default of "myColor".

Notice that "color" is matched with NormalizedColors using the matching variable while the rest have the variable set to "color".

From here we can add our telemetry blocks to see what values the color sensor detects!

Programming a Servo with a Gamepad

Having our robot able to rotate the servo automatically can be incredibly useful, especially when writing an autonomous program, but what if I want to control the positions with my gamepad?

Let's take a look at how we can add input commands to our code!

For this example the known state will stay at position 0, so that after initialization the servo will be a the -135 degree position of the servo range. The following list shows what buttons correspond with which servo position:

Blocks for adding controller inputs can be found in the "Gamepad" menu:

One of the most common logic statements used in programming is an if/else statement, also known as an if/then statement. This block can be found under the "Logic" menu in Blocks:

In its most simple format we will be asking our robot to check IF something is happening and if the answer is yes, or true in our robot's mind, THEN it will DO what has been asked.

During this section we are going to be asking "If the Y button is pressed on our controller then move our servo to position 0."

If our servo will move to position 0 when the previous statement is TRUE, what do expect to happen when the answer is FALSE (or the Y button is not pressed)?

Our if/else statement can come in many forms that includes multiple different conditional statements. Blocks allows for our base block to be easily added to add as many conditional statements as we need by clicking the blue gear on our block.

Adding an block by clicking and dragging to our existing if statement converts it into becoming an if/else if statement. Using our previous example we can see how this may look in Blocks:

Now our statement is checking first if Y is being pressed to move to position 0, but has added now the option to look for something else, such as another button being pressed.

Let's add to our existing logic statement the ability to move our servo to position 1 when A is pressed on our controller. Give it a try first before revealing the answer below!

How would our full logic statement be read once our new blocks are added?

To add all of our gamepad inputs we need to further extend our if/else if statement:

Now there are three different paths in our if/else if block that our robot may follow based on each input request. We've previously added our ability to move to position 0 and 1, but what about 0.5?

You may have noticed in our gamepad chart at the beginning of this section that we are going to have two buttons able to move our servo to position 0.5. This is so we can practice using a logical operator like the block in our program!

From the Logic Menu in Blocks select the block.

Add this block to the if/else if block, as shown in the image below. Use the dropdown menu on the block to change it from an block to an block.

Add each button block to the if/else if block as seen in the image below.

Now to finish by adding our blocks to each section of the If/else if block. Set the servo position to correspond with the assigned gamepad button.

There are three different paths in this if/else if statement. If the first conditional statement is true (the Y button is pressed) the servo moves to code position 0 and the other conditional statements are ignored.

If the first condition is false (the Y button is not pressed) the second condition is analyzed. This means the order we add our pathways DOES matter. If X and A are pressed at the same time, the robot will will try to prioritize the X button first.

Give it a try!