Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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.
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?
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 !
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.
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.
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.
We're updating this documentation!
During 2024 Summer, "Hello Robot" will be getting a refreshed look to reflect changes to the latest versions of the REV Hardware Client and Robot Controller App.
While this guide is still generally relevant, you may see differences in the naming of devices or commands along with visual updates to the guide.
In the previous section you learned about how to use Elapsed Time to allow your robot to navigate the world around it autonomously. When starting out many of the robot actions can be accomplished by turning on a motor for a specific amount of time. Eventually, these time-based actions may not be accurate or repeatable enough. Environmental factors, such as the state of battery charge during operation and mechanisms wearing in through use, can all affect time-based actions. Fortunately, there is a way to give feedback to the robot about how it is operating by using sensors; devices that are used to collect information about the robot and the environment around it.
With Elapsed Time, in order to get the robot to move to a specific distance, you had to estimate the amount of time and the percentage of duty cycle needed to get from point a to point b. However, the REV motors come with built in encoders, which provide feedback in the form of ticks ( or counts) per revolution of the motor. The information provided by the encoders can be used to move the motor to a target position, or a target distance.
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.
There are two articles in that go through the basics of Encoders. Using Encoders goes through the basics of the different types of motor modes, as well as a few application examples of using these modes in code. In this section we will focus on using RUN_TO_POSITION.
The other article, Encoders, focuses on the general functionality of an encoder.
It is recommended that you review both articles before moving on with this guide.
Start by creating a basic op mode called HelloRobot_EncoderAuton.
When creating an op mode a decision needs to be made on whether or not to set it to autonomous mode. For applications under 30 seconds, typically required for competitive game play changing the op mode type to autonomous is recommended. For applications over 30 seconds, setting the code to the autonomous op mode type will limit your autonomous code to 30 seconds of run time. If you plan on exceeding the 30 seconds built into the SDK, keeping the code as a teleoperated op mode type is recommended.
For information on how op modes work please visit the Introduction to Programming section.
For more information on how to change the op mode type check out the Test Bed - Blocks section.
For more information on the directionality of motor check out the Basics of Programming Drivetrains section.
Save and run the op mode two times in a row. Does the robot move as expected the second time?
Try turning the Control Hub off and then back on. How does the robot move?
For more information on the motor mode STOP_AND_RESET_ENCODERScheck out the STOP_AND_RESET_ENCODERS section of the Using Encoders guide.
Rather than attempt to measure, or estimate, the distance the robot moves, the encoder ticks can be converted from amount of ticks per revolution of the encoder to how many encoder ticks it takes to move the robot a unit of distance, like a millimeter or inch. Knowing the amount of ticks per a unit of measure allows you to set a specific distance. 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.
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
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.
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:
Unlike the the spur gears used to transfer motion to the wheels, the UltraPlanetary Gearbox Cartridges are planetary gear systems. To make calculations easier the gear ratios for the Cartridges are already reduced.
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.
Due to wear and manufacturing tolerances, the diameter of some wheels may be nominally different. For the most accurate results consider measuring your wheel to confirm that the diameter is accurate.
To summarize, for the Class Bot V2 the following information is true:
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
The common naming convention for constant variables is known as CONSTANT_CASE, where the variable name is in all caps and words are separated by and underscore.
Add the variables to the initialization section of the op mode.
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.
To calculate counts per wheel revolution multipleCOUNTS_PER_MOTOR_REV by DRIVE_GEAR_REDUCTION Use the following formula:
Where,
Once COUNTS_PER_WHEEL_REV is calculated, use it to calculate the counts per mm that the wheel moves. To do this divide theCOUNTS_PER_WHEEL_REV by the WHEEL_CIRCUMFERENCE_MM. Use the following formula.
Where,
COUNTS_PER_WHEEL_REVwill be created as a separate variable fromCOUNTS_PER_MM as it is used in calculating a target velocity.
Create these variables in Blocks and add then to the op mode under the other constant variables.
OnceCOUNTS_PER_WHEEL_MM is set, this completes the conversion process, and all constant variables are set.
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. Velocity is the same for both motors. If you try running this code, you may notice that the robot pivots along its center of rotation. To get a wider turn 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.
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.
With our time condition ready, we can set it aside for a moment.
Now let's set up our logic to modify our While Loop.
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?
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!
Consider marking different goals on the floor with tape to practice determining how much time the robot needs to reach it.
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!
Hello Robot Part 3: Autonomous and Encoders is currently under construction. Please stay tuned for future updates!
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.
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.
From the variable menu, add the block to the OpMode below the comment block.
In order to utilize elements of the ElapsedTime, runtime will act as the ElapsedTime variable. Add the block to the block.
Before moving on to the rest of the ElapsedTime structure lets go ahead and add the motor related blocks. Add to the op mode to the while loop.
Remember that on a drivetrain one of our motors will need to be set to run in reverse to prevent the robot from spinning in place! Add the block under the the block set.
Add the block to the op mode under the .This will change the direction of the rotation of the right motor to be the same direction as the left motor.
Recall from Using Encoders that using RUN_TO_POSITION mode requires a three step process. The first step is setting target position. To set target position, grab the block and add it to the op mode under the comment. To get a target position that equates to a target distance requires so calculations, which will be covered later. For now, set target position to 1000 ticks.
When there are multiple of the same type of variable (such as multiple Dc Motor variables) the variable specific blocks will choose a default variable based on alphabetical order. For this example Op Mode Dc Motor blocks will default to the arm variable. Click the arrow next to the motor name to change the arm motor variable to the rightmotor variable. Use the variable drop down menu on the block to change from arm to rightmotor.
The next step is to set both motors to the RUN_TO_POSITION mode. Place the block beneath the block.
The main focus of the three step process is to set a target, tell the robot to move to that target, and at what speed (or velocity) the robot should get to that target. Normally, the recommended next step is to calculate velocity and set a target velocity based on ticks. However, this requires quite a bit of math to find the appropriate velocity. For testing purposes, its more important to make sure that the main part of the code is working before getting too deep into the creation of the code. Since the function was covered in previous sections and will communicate to the system what relative speed (or in this case duty cycle) is needed to get to the target, this can be used in the place of velocity for now.
Add the block to the op mode beneath the block. Change the duty cycle (or power) of both motors to 0.8, instead of 1.
Now that all three RUN_TO_POSITION steps have been added to the code the code can be tested. However, if you want to wait for the motor to reach its target position before continuing in your program, you can use a while loop that checks if the motor is busy (not yet at its target). For this program lets edit the block.
Recall that, within a linear op mode, a while loop must always have the Boolean as a condition. This condition ensures that the while loop will terminate when the stop button is pressed.
Grab an block from the logic menu and add it to the while loop. On the left side of the block add the block. On the right side add the block.
Embed the in another block. Place the on the right side of the block. On the left side add the block.
Right now the while loop is waiting for the right and left motors to reach their respective targets. There may be occasions when you want to wait for both motors to reach their target position, in this case the can be used.
In the Basic Encoder Concepts section, it is clarified that ell encoder ports start at 0 ticks when the Control Hub is turned on. Since you did not turn off the Control Hub in between runs, the second time you ran the op mode the motors were already at, or around, the target position. When you run a code, you want to ensure that certain variables start in a known state. For the encoder ticks, this can be achieved by setting the mode to . Add this block to the op mode in the initialization section. Each time the op mode is initialized, the encoder ticks will be reset to zero.
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. What is the distance from the starting point of the robot and the point the robot moves to after running this code?
Reminder that the basis for this guide is the . The REV DUO Build System is a metric system. Since part of the conversion process references the diameter of the wheels, this section will convert to ticks per mm.
Visit the manufacturers website for your motor or encoders for more information on encoder counts. For HD Hex Motors or Core Hex Motors visit the documentation.
Since ticks per revolution of the encoder shaft is before any gear reduction calculating the total gear reduction is needed. This includes the gearbox and any addition reduction from motion transmission components. To find the total gear reduction use the .
The UltraPlanetary Cartridges use the nominal gear ratio as a descriptor. The actual gear ratios can be found in the .
Once the variables are created and added to the op mode, use the blocks to set the variables to the respective values. For WHEEL_CIRCUMFERENCE_MM a combination of the , , and blocks to get the circumference of the wheel. The
= COUNTS_PER_MOTOR_REV
= DRIVE_GEAR_REDUCTION
= COUNTS_PER_WHEEL_REV
= COUNTS_PER_MOTOR_REV
= DRIVE_GEAR_REDUCTION
= WHEEL_CIRCUMFERENCE_MM
= COUNTS_PER_WHEEL_REV
= COUNTS_PER_MM
Again math blocks need to be used to define these variables. Lets start with the COUNTS_PER_WHEEL_REV variable. Add a to the block. Add the and blocks to either side of the block.
Since COUNTS_PER_WHEEL_REV has been calculated it can be used to calculate COUNTS_PER_MM add the to the . On the left side of the add the block. On the right side of the add the .
In the section, the mechanism of was discussed. dictates what direction and speed a motor moves in. On a drivetrain the combined direction and speed of the motors dictates whether the robot moves in forward, backwards, or turns.
In RUN_TO_POSITIONmode 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
For more information on how direction and speed impact the movement of a robot please refer to the explanation of in the section.
Lets start by creating our less than or equal to condition. Grab the from the Logic menu.
Next select the block from the ElapsedTime menu. Snap the block into the left side of the block. Using the dropdown menu, change the generic to the variable we established earlier.
On the other side of our equation, we need to add a block from the Math menu. Change the number block to 3.
Right now the is equal to three. Use the arrow next to the equal sign to choose the less than or equal to sign from the dropdown menu.
First, grab an block from the Logic menu. The block we currently have as part of our loop will be moved to the lefthand side.
On the other side, add the block:
This block set will connect where the block originally was. Now the while loop will now activate when both conditions of the AND block are true.
To keep this from happening the timer should be reset once the OpMode is active. Grab the call block from the ElapsedTime menu and switch it to our runtime variable.
This will be added to our program BELOW the comment and ABOVE the while loop.
Now let's explore what happens when we change our time limit to different amounts. You can adjust your time limit by changing the 3 in our block to a different number.
Our block will snap into our number slot.
| ElapsedTime | Drivetrain Encoders | Arm Encoders |
|---|