What is an Encoder?

Encoders are a form of sensor built into some motors that help provide feedback to our robot. There are different kinds of encoders, but we're going to be focus on what's called a quadrature encoder for this tutorial. These encoders are able to count the number of revolutions of the motor also sometimes called "ticks".

While quadrature encoders aren't able to tell exact positions, they can still be used to help the motor move to a specified point. We'll go over how to do so later in this tutorial, but this works by specifying first an origin point in our code then a point the motor should move away.

Different motors have different numbers of ticks per rotation of the output shaft based on the gear ratio of the motor. When the Control Hub is turned on, all of its encoder ports are at 0 ticks. As a motor moves forward, its encoder value increases. As a motor moves backwards, its encoder value decreases.

Exploring Motor Modes

Let's take a closer look at the different modes we can set our encoder to with our motor. The mode is often established during the initialization process of our code, meaning the motors are ready to go throughout our program, but it is possible to change this for specific use cases as it executes.

Which mode we need to use largely depends on the intended function of the motor and any attached mechanism. For example, we may not need our encoders active on the drivetrain motors when they're being controlled by a joystick's input. On the other hand, we may have a flywheel design that requires a specific speed our encoders can help us achieve.

Using STOP_AND_RESET_ENCODER

When using encoders, it is strongly recommended to first use STOP_AND_RESET_ENCODER during initialization. This will allow you to know what position the motor is starting in, however you will want to plan for a repeatable start up configuration each time!

A motor can be switched to "STOP_AND_RESET_ENCODER" while a code is executing as well. This is often set up using a button on the gamepad to allow the driver to reset the encoder in the event of a motor misbehaving, such as after the robot's been caught on an obstacle.

Using RUN_WITHOUT_ENCODER

Use this mode when you don’t want the Control Hub to attempt to use the encoders to maintain a constant speed. You can still access the encoder values, but your actual motor speed will vary more based on external factors such as battery life and friction. In this mode, you provide a power level in the -1 to 1 range, where -1 is full speed backwards, 0 is stopped, and 1 is full speed forwards. Reducing the power reduces both torque and speed.

The RUN_WITHOUT_ENCODER motor mode is very straightforward, you simply set a power throughout the program using the "Power" block or, such as for a drivetrain, to be set by the joysticks.

Using RUN_USING_ENCODER

In this mode, the Control Hub will use the encoder to take an active role in managing the motor’s speed. Rather than directly applying a percentage of the available power, RUN_USING_ENCODER mode targets a specific velocity (speed). This allows the motor to account for friction, battery voltage, and other factors. You can still provide a power level in RUN_USING_ENCODER mode, but this is not recommended, as it will limit your target speed significantly.

Setting a velocity from RUN_WITHOUT_ENCODER mode will automatically switch the motor to RUN_USING_ENCODER mode. You should pick a velocity that the motor will be capable of reaching even with a full load and a low battery.

Using RUN_TO_POSITION

In this mode, the Control Hub will target a specific position, rather than a specific velocity. You can still choose to set a velocity, but it is only used as the maximum velocity. The motor will continue to hold its position even after it has reached its target.

To use RUN_TO_POSITION mode, you need to do the following things in this order:

1. Set a target position (measured in ticks)

2. Switch to RUN_TO_POSITION mode

3. Set the maximum velocity (if not determined by a gamepad input)

Remember it is recommended to always reset the encoder during initialization, however you will need to make sure your robot has been reset physically to the initialization position. For example, an arm may need to be brought back to the start up configuration like for the beginning of a FTC match.

The motor will continue to hold its position even after it has reached its target, unless you set the velocity or power to zero, or switch to a different motor mode.

We've tackled the basics. We have a robot able to drive around. What could be next?

Right now our robot is largely dependent on inputs from us as the driver from the gamepad. We've helped it learn to sense a little bit using the touch sensor, but there is still more we can do.

During Part 3 we will be learning how to help our robot navigate the world around it autonomously in different ways. To start we will look at how to use a timer for the robot to keep track of how long it should do something. From there, we will move on to using the built in encoders of the HD Hex and Core Hex Motors.

Encoders are a form of sensor that help collect data for the motor. Some encoders count the number of completed rotations. Others are able to track the exact position of a motor, similar to a servo. The use of encoders brings the need for more math and complex programming, however it will allow your robot to navigate more efficiently.

Quick Links

Right now our robot should move forward 3 seconds then stop. What if we wanted our robot to do something else after those 3 seconds? How do we request our program to continue?

To start let's duplicate our existing loop. We can right click on a block to duplicate it. In this case, since our block is a loop, it will duplicate everything within the loop.

We can snap our second loop below the original, however something is still missing. If we want our second loop to start we need our timer to first reset! We can add a block between our two loops.

Notice our second loop also has a call for telemetry data, however the name is the same! Let's edit it to be "Number of Seconds in Phase 2". Keep the names in mind if you duplicate additional loops.

Quick Check!

Give your program a test to see what happens. Think about the following while testing:

• How long does the robot move?

• Could you tell when the robot switched between Phase 1 and 2?

• What happens if we change the power in the second loop?

Reversing Movement

Having multiple loops with different amounts of time can give us a lot of power to help our robot navigate an area. For now let's have our robot complete it's first movement forward for 3 seconds, then reverse back to the start.

This simply requires changing our power in the second loop to -1 !

Now that you have created the constant variables needed to calculate the amount of ticks per mm moved, you can use this to set a target distance. For instance, if you would like to have the robot move forward two feet, converting from feet to millimeters and multiplying by the COUNTS_PER_MM will give you the amount of counts (or ticks) needed to reach that distance!

Let's create two more variables called leftTarget and rightTarget. Add the and blocks within the if/then statement that will run once Play is selected.

Converting from mm to Feet

Right now the main distance factor is COUNTS_PER_MM , however you may want to go a distance that is in the imperial system, such as 2 feet (or 24 inches). The target distance in this case will need to be converted to mm.

To convert from feet to millimeters use the following formula:

If you convert 2 feet to millimeters, it comes out the be 609.6 millimeters. For the purpose of this guide, lets go ahead an round this to be 610 millimeters.

Converting Feet to Ticks

Next, multiply 610 millimeters by the COUNTS_PER_MM variable to get the number of ticks needed to move the robot 2 feet. Since the intent is to have the robot move in a straight line, set both the leftTarget and rightTarget, to be equal to 610 * COUNTS_PER_MM

Moving the motors to a specific position, using the encoders, removes any potential inaccuracies or inconsistencies from using Elapsed Time. The focus of this section is to move the robot to a target position using encoders.

Setting up the Drivetrain Encoders

Before diving in too far, recall that for certain , like the , one of the motors needs to be reversed as the motors are mirrored. In our example, we are adding the block under the .

RUN_TO_POSITION

If we want our robot to travel a specific distance we will need to do a bit of math beforehand to calculate the TargetPosition. But for now let's start simple by setting the target position to 1000 ticks.

As mentioned, normally there would be more math involved to help determine how fast the motors should move to reach the desired position. But for testing purposes, we are going to start by keeping it simple!

Quick Check!

Save your OpMode and give it a test. What happens once you press play? What happens if you stop the program then start it again?

STOP_AND_RESET_ENCODERS

For our demo code we will want to request our motors reset their encoders during the initialization process of the program.

Setting up the whileLoop

Let's say we want our program to run only for however long it takes for the motors to reach designated position. Or maybe we intend for the robot to do something else after reaching the destination. For this we will need to edit our whileLoop block!

Save your OpMode and give it a try!

As soon as the motors hit the desired position the program will end instead of continuously run in the event they do not perfectly hit the position.

In the previous section, the basic structure needed to use RUN_TO_POSITIONwas created. The placement ofwithin the code, set the target position to 1000 ticks.

But how far is a tick and how can we use them to help our robot navigate an area? We could attempt to estimate the distance the robot moves per tick or we can convert the amount of ticks per revolution of the encoder into a unit like millimeters or inches! For instance, if you work through the conversion process and find out that a drivetrain takes 700 ticks to move an inch, this can be used to find the total number of ticks need to move the robot 24 inches.

What's Needed for the Conversion

This process will take a bit of math to achieve so let's break it down.

When using encoders built into motors, converting from ticks per revolution to ticks per unit of measure moved requires the following information:

• Ticks per revolution of the encoder shaft

• Total gear reduction on the motor

  • Including gearboxes and motion transmission components like gears, sprockets and chain, or belts and pulleys

• Circumference of the driven wheels

Ticks per Revolution

The amount of ticks per revolution of the encoder shaft is dependent on the motor and encoder. Manufacturers of motors with built-in encoders will have information on the amount of ticks per revolution.

For HD Hex Motors the encoder counts 28 ticks per revolution of the motor shaft.

Total Gear Reduction

For the Class Bot V2 there are two UltraPlanetary Cartridges, 4:1 and 5:1, and an additional gear reduction from the UltraPlanetary Output to the wheels, 72T:45T ratio.

Using the compound gearing formula for the Class Bot V2 the total gear reduction is:

Circumference of the Wheel

The Class Bot V2 uses the 90mm Traction Wheels. 90mm is the diameter of the wheel. To get the appropriate circumference use the following formula

You can calculate this by hand, but for the purpose of this guide, this can be calculated within the code.

Quick Summary

To summarize, for the Class Bot V2 the following information is true:

Translating the Conversion to Code

Setting up Variables

Each of these pieces of information will be used to find the number of encoder ticks (or counts) per mm that the wheel moves. Rather than worry about calculating this information by hand, these values can be added to the code as constant variables. To do this create three variables:

• COUNTS_PER_MOTOR_REV

• DRIVE_GEAR_REDUCTION

• WHEEL_CIRCUMFERENCE_MM

Now that these three variables have been defined, we can use them to calculate two other variables: the amount of encoder counts per rotation of the wheel and the number of counts per mm that the wheel moves.

Calculating COUNTS_PER_WHEEL_REV

To calculate counts per wheel revolution multiply COUNTS_PER_MOTOR_REV by DRIVE_GEAR_REDUCTION Use the following formula:

Where:

Calculating COUNTS_PER_MM

Once the COUNTS_PER_WHEEL_REV is calculated, it can be used to calculate the counts per mm that the wheel moves. To do this divide the COUNTS_PER_WHEEL_REV by the WHEEL_CIRCUMFERENCE_MM. Use the following formula.

Where,

Final Variables

Once COUNTS_PER_WHEEL_MM is set, this completes the conversion process, and all constant variables are set.

Make sure to save your OpMode here to prevent any progress being lost in the event of a disconnect!

Often times, like in the program created during , we use the block to set the drivetrain motors to a set power or power based on a joystick's inputs. The combined power going to both motors help to determine the direction the robot moves or turns.

However, in RUN_TO_POSITION mode the encoder counts are used instead of to dictate directionality of the motor.

• If a target position value is greater than the current position of the encoder, the motor moves forward.

• If the target position value is less than the current position of the encoder, the motor moves backwards.

Since speed an directionality impacts how a robot turns, target position and velocity need to be edited to get the robot to turn. Consider the following code:

The rightTarget has been changed to be a negative target position. Assuming that the encoder starts at zero due to STOP_AND_RESET_ENCODER this causes the robot to turn to the right.

Notice the velocity is the same for both motors. If you try running this code, you can see that the robot pivots along its center of rotation.

To get a wider turn, try changing the velocity so that the right motor is running at a lower velocity than the left motor. Adjust the velocity and target position as needed to get the turn you need.

Introduction to ElapsedTime

When using our gamepad, we can actively communicate with our robot while our program runs. Our robot waits for our input and acts accordingly until a different command is issued. However, this may not always be the case, such as during the autonomous period of a FTC competition.

Our robot is smart enough to navigate some on its own, however we need to help it along to know what to look for. Eventually, you could work up to your robot being able to navigate using a camera and machine learning or its IMU to sense direction, but for now let's start with one of the built in features of the SDK: ElapsedTime

What do you think of when you think of a timer? A stopwatch? Your phone? Maybe the timer on a microwave or oven? Timers commonly consist of two main categories: count up and count down. You can think about the differences of these two by a comparison like keeping track of how fast a runner did a 100m dash vs. needing to know how much longer our food should cook.

ElapsedTime is a count up timer. Registering the amount of time elapsed from the start of a set event, like the starting of a stopwatch. In this situation, it is the amount of time passed from when the timer is created or reset within the code.

Quick Links:

Sneak Peek of Our Full Code:

Now that we have an estimate for our target position let's see if we can refine it to be more precise using similar methods to what we covered during the Drivetrain Encoders section.

What's Needed for the Conversion

Ticks per Revolution

Recall, that ticks per revolution of the encoder shaft is different than the ticks per revolution of the shaft that is controlling a mechanism, such as what we determined on our Drivetrain.

The amount of ticks per revolution of the encoder shaft is dependent on the motor and encoder. Manufacturers of motors with built-in encoders will have information on the amount of ticks per revolution.

In the Core Hex Motor specifications there are two different Encoder Counts per Revolution numbers:

• At the motor - 4 counts/revolution

• At the output - 288 counts/revolution

At the motor is the number of encoder counts on the shaft that encoder is on. This number is equivalent to the 28 counts per revolution we used for the HD Hex Motor.

The 288 counts "at the output" accounts for the change in resolution after the motion is transmitted from the motor to the built in 72:1 gearbox.

Lets use the 288 as ticks per revolution so that we do not have to account for the gearbox in our total gear reduction variable.

Total Gear Reduction

Since we built the the gear reduction from the motor gearbox into the ticks per revolution the main focus of this section is calculating the gear reduction of the arm joint.

The motor shaft drives a 45 tooth gear that transmits motion to a 125 tooth gear. The total gear ratio is 125T:45T. To calculate the gear reduction for this gear train, we can simply divide 125 by 45.

Quick Summary

To summarize, for the Class Bot V2 the following information is true:

Adding Arm Encoders to the Program

Establishing Initialization Variables

Now that we have this information lets create two constant variables:

• COUNTS_PER_MOTOR_REV

• GEAR_REDUCTION

Add the variables COUNTS_PER_MOTOR_REV and GEAR_REDUCTION variables to the initialization section of the program.

Our COUNTS_PER_MOTOR_REV and GEAR_REDUCTION variables will be set to a value that will then be used to calculate our other two variables COUNTS_PER_DEGREE and COUNTS_PER_GEAR_REV.

Let's go ahead and add these variables to our OpMode.

Adding Calculations to the Variables

Now that these two variables have been defined, we can use them to calculate two other variables: the amount of encoder counts per rotation of the 125T driven gear and the number of counts per degree moved.

Calculating counts per revolution of the 125T gear (or COUNTS_PER_GEAR_REV) is the same formula we used for COUNTS_PER_WHEEL_REV variable on our drivetrain, so to get this variable we can multiple COUNTS_PER_MOTOR_REV by GEAR_REDUCTION.

To calculate the number of COUNTS_PER_DEGREE divide the COUNTS_PER_GEAR_REV variable by 360.

All together our variables will look like below:

Adjusting our If/Else Statement

We need to create one more non-constant variable that will act as our position. This will be called armPosition.

To get to the 90 degree position, the arm needs to move roughly 45 degrees therefore set arm position equal to COUNTS_PER_DEGREE times 45.

Save your OpMode and give it a test!

We've covered using encoders for a drivetrain, but what about for a different mechanism, such as an arm? Unlike the drivetrain, the arm does not follow a linear path. This means rather than converting to a linear distance it makes more sense to convert the encoder ticks into an angle measured in degrees!

In the image below two potential positions are showcased for the Class Bot arm. One of the positions (blue) is the position where the arm meets the limit of the touch sensor. Due to the limit, this position will be our default starting position.

From the Class Bot build guide, it is known that the Extrusion supporting the battery sits a 45 degree angle. Since the arm is roughly parallel to these extrusion when it is in the starting position, we can estimate that the default angle of the arm is roughly 45 degrees.

The goal of this tutorial is to determine the amount of encoder ticks it will take to move the arm from its starting position to a position around 90 degrees.

There are a few different ways this can be accomplished. For example, an estimation can be done by moving the arm to the desired position and recording the telemetry feedback from the Driver Station. Alternatively, we can do the math calculations to find the amount of encoder ticks that occur per degree moved.

Follow through this tutorial to walk through both options and determine which is the best for your team!

Setting Velocity in our Program

Velocity is a closed loop control within the SDK that uses the encoder counts to determine the approximate power/speed the motors need to go in order to meet the set velocity.

To set a velocity, its important to understand the maximum velocity in RPM your motor is capable of. For the Class Bot V2 the motors are capable of a maximum RPM of 300. With a drivetrain, you are likely to get better control by setting velocity lower than the maximum. In this case, lets set the velocity to 175 RPM!

Since RPM is the amount of revolutions per minute, a conversion needs to be made from RPM to ticks per second (TPS). To do this, divide the RPM by 60 to get the amount of rotations per second.

Rotations per second can then be multiplied by COUNTS_PER_WHEEL_REV, to get the amount of ticks per second.

Adding Ticks per Second as a Variable

Create a new variable called TPS. Add the to the beginning of the if/then statement above the target variables.

Changing from Power to Velocity

With the velocity set, let's give our program a test run after saving!

Full Program

For now our goal will be to have the motors move forward for 3 seconds. To accomplish this we need to edit our main While Loop so that it triggers when the OpMode is active AND the ElapsedTime timer is less than or equal to 3 seconds.

Setting a Time Limit

Lets start by creating our less than or equal to condition. Grab the from the Logic menu.

With our time condition ready, we can set it aside for a moment.

Modifying Our While Loop

Now let's set up our logic to modify our While Loop.

Quick Check!

Let's give our OpMode a try and test the following scenarios:

• What happens when hitting play quickly after the initialization button is pressed?

• What happens when hitting play 2 seconds after the initialization button is pressed?

• What happens when hitting play 10 seconds after the initialization button is pressed?

Resetting the Timer

Not being able to pause between initialization and pressing Play is probably not ideal in most situations. It certainly makes tracking how far the robot will travel more challenging, the opposite of what we'd like ElapsedTime to help us do.

Since this is before our loop our robot will complete it once when Play is pressed. Then will complete the check for our while loop.

Test your program again with this change!

Adding Telemetry

In previous parts, we've looked at adding telemetry as a way for the robot to communicate with us. In this situation, it would be helpful for the robot to be able to tell us how much time it has counted so we can make adjustments to our program!

Recall we can find our telemetry block under the utilities menu:

For our key let's call it "Number of Seconds in Phase 1" for now. This will be useful for distinguishing where in our program our robot is during the next section.

Save your OpMode and give it a try!

For this tutorial, our OpMode is named HelloRobot_ArmEncoder!

Estimating the Position of the Arm using Telemetry

Let's start by creating a simple program for moving our robot's arm. The one below will look very similar to the code created during Part 2: Robot Control!

Adding Telemetry

Finding the Position with Telemetry

Save the OpMode and run it.

Use the gamepad commands to move the arm to the 90 degree position. Once you have the arm properly positioned read the telemetry off the Driver Hub to determine the encoder count relative to the position of the arm.

Adding RUN_TO_POSITION to the Program

Lastly, we can remove the final "else" of our statement for now since we are now using RUN_TO_POSITION mode.

Despite our power being a positive value for both directions, the arm will move up or down based on the set position!

Testing the Program

If you try running this code you may notice that the arm oscillates around the 90 degree position. When this behavior is present you should also notice the telemetry output for the encoder counts fluctuating.

Recall RUN_TO_POSITION is a Closed Loop Control, which means that if the arm does not perfectly reach the target position, the motor will continue to fluctuate until it does. When motors continue to oscillate and never quite reach the target position this may be a sign that the factors determining tolerances and other aspects of the closed loop are not tuned to this particular motor or mechanism.

There are ways to tune the motor, or ways to have the program exit once the position is reached, but for now we want to focus on working with the arm and expanding on how limits and positions work with regards to the mechanism.

In Part 2: Robot Control the idea of creating a limit switch was introduced using a physical sensor, like a touch sensor. We can make use of our motor's built-in encoder to do something similar. While a physical sensor would be described as a hard limit, using the built-in encoder is called a soft limit.

To set the soft limits we will build off the program created in the last sections (HelloRobot_ArmEncoder)!

Creating minPosition and maxPosition

To start, we need to create our upper and lower limits. Create two new variables one called minPosition and one called maxPosition to be added to initialization.

Adjusting our If/Else Statement

To start, our If/Else Statement will be changed back to a simplified format like we had at the beginning of estimating the position of the arm.

To set the limit we need to edit our if/else statement to include our limits:

• If up on the Dpad is pressed and the position of the arm is less than the maxPosition, then the arm will move to the maxPosition.

• If down on the Dpad is pressed and the position of the arm is greater than the minPosition then the arm will move towards the minPosition.

Overriding Limits

One of the benefits of having a soft limit is being able to exceed that limit.

Remember that the encoders zero tick position is determined by the position of the arm when the Control Hub powers on! So if we aren't careful to reset the arm before powering on our robot this will effect the arm's range of motion. For instance, if we have to reset the Control Hub while the arm is in the 90 degree position, the 90 degree position will become equal to 0 encoder ticks.

As a back up, we can create an override for the range of motion. There are a few different ways an override can be created, but in our case we are going to use the "A" button and touch sensor to help reset our range.

Adding a Gamepad Override

Now that we have this change in place, when the "A" button is pressed the arm will move toward the starting position.

Adding a Touch Sensor Limit

Next, when the arm reaches and presses the touch sensor we want to STOP_AND_RESET_ENCODER .

Save your OpMode and try testing it!

Locating ElapsedTime Blocks:

Before getting started, let's quickly identify where we will find our ElapsedTime blocks. This menu can be found under the Utilities dropdown on our side toolbar.

Setting up the Basics:

For this section, let's start by creating a new OpMode named HelloRobot_ElapsedTime using the BasicOpMode sample.

Recall when we created variables while programming our drivetrain. We will be using them again during this part to help with calculations! To start create a variable called runtime.