This section pairs with Unit 1, Lesson 6 from the Intro to Robotics V2 curriculum.
Let's take a look at the basic structure and key blocks of the OpMode. This what is provided when using the sample BasicOpMode:
This sample is recommended as it provides the needed basic structure for a program to run properly with the Driver Hub, but it can be modified to best fit the current needs of the project.
The marked comments also help give direction for where different blocks should be added depending on their purpose.
Put Initialization blocks here - shows us where we will be setting up some variables, resetting encoders, setting motor directions, and anything else that needs to happen when the code is first activated.
Put run blocks here - is where anything that will be used when hitting the play button on our Driver Hub should be added.
Put loop blocks here - is similar to our last comment, but is for anything that needs to be repeated the entire time our program is running and will be halted when pressing the stop button.
This contains the components of the program of the designated name. Anything sitting loose in the programming space, unless in a created function, will not be read when the program is run.
When the Robot Controller reaches the block it will stop and wait until it receives a Start command from the Driver Hub. Any code after this block will get executed only after the Start button has been pressed.
Whenever there is a call opModeIsActive, the Control Hub is checking that the OpMode is supposed to be running and has not been shut down by the Driver Hub. If something happens, for example the Driver Hub shuts off, this will change from true to false since it can no longer be checked, shutting down the current program.
In more complex programs, this call must be included in added loops alongside any other conditions, such as a count, sensor information, or time limit.
This sample Blocks program defaults to being in an iterative control structure, meaning it's intended to continue looping until Stop is pressed on the Driver Hub or a different condition is met.
Code that should continually run so long as the OpMode is active, will be placed in the loop. If a program starts and immediately stops, students may need to double check their code is set to loop.
Let's create our first OpMode to do something similar to how we get started in other programming languages. Let's have the robot read out "Hello World!" on the Driver Hub.
To do this we can make use of telemetry.
Telemetry is the process of collecting and transmitting data. In robotics, telemetry is used to output internal data, such as from the actuators and sensors, to the Driver Hub. It is a way for the robot to communicate back to the programmer what the robot thinks its doing or seeing.
From our Telemetry menu look for the call to add telemetry with a key and text.
The "key" is how we label the data being shown on the Driver Hub. In this case we'll set it to "Robot Says"
The "text" is then our output. This might be data from a sensor or just instructions serving as a reminder for running the code. We can manually enter "Hello World!" for this example.
Snap this block into the loop above the call to update the telemetry.
From here we will click Save OpMode and are ready to give it a try!
To run a program in the Driver Hub, first check it's connected to the intended Control Hub. The name will appear on the Driver Station App as seen here:
Then select the program from the dropdown menu. We will be sticking to TeleOp programs stored in the right menu.
Select the OpMode from the list.
Now we can click Initialize, which let the robot run any set up code we made.
And press Play when ready.
In this example, we can see the message on the right! Pressing Stop will halt the code at any time.
Let's briefly look at what happens if our telemetry block is not in the loop of our OpMode. Try dragging it to be below "Put initialization blocks here" and test it out after saving!
Now try moving the call to update telemetry with it in the initialization area.
In the next section, we'll get the actuators on the testbed spinning!
The telemetry block from the last section can be removed from our OpMode.
Let's start by getting our Core Hex Motor spinning on the testbed. Under the Actuators menu look for DcMotor:
When looking at the options, the names of the motors will typically appear in alphabetical order. In the pictures used for this guide coreHex shows as the default option. If you named your motors differently, there will be variation.
First, we'll add a power block to our loop:
With that we can save our program and run it to see what happens!
The max power for spinning forward is 1. The max power for spinning in reverse is -1. Going above these values will not make the motor spin any faster. However, it also will not damage the motor so students can be encouraged to explore what happens!
Take a moment to try adjusting the power of the Core Hex motor then add the HD Hex Motor to spin in a similar fashion.
The HD Hex Motor's name can be selected from the dropdown on the power block.
While in angular mode, servos are programmed a little different than motors. Rather than assigning a power, we'll be setting positions for them to move between.
Note: This menu will appear differently if there is a continuous servo listed in the current configuration file.
When looking at the options, the names of the servos will typically appear in alphabetical order. In the pictures used for this guide servo show as the default option. If you named your servos differently, there will be variation.
Let's start by adding a block to set our servo's position to 1.
With that we can save our program and run it to see what happens! After running the program once, stop and try to run it again.
If we want our servo to move each time our program runs, we need it to first reset to a different position. In this example, we can do this during initialization.
Add a position block for 0 under Put initialization blocks here.
Now save the OpMode and run the program again.
Take a moment to try different positions for your servo to move between.
In the next section we'll add a gamepad to control the movements of our actuators!
Since the call to update telemetry is now before the call to waitForStart, our message will appear after initialize has been pressed, but will continue to be present after hitting play since no other command has been given.
When using telemetry, a call to update block is key to allow the information to be continually reported back, accurate, and available on the Driver Hub.
We have our motors running autonomously, but now let's add some manual control with a gamepad.
The Gamepad menu is always available in Blocks to search for the desired button or joystick control.
For our motors, we can set the power of the motor to be equal to the movement of the joystick. As the joystick moves up and down along the y-axis, it's value changes from -1 to 1 with 0 being off.
Click the gamepad block for the LeftStickY to the motor power block of the Core Hex Motor.
Before testing, it's good to note that by default the direction of the Y-axis on the gamepad is inverted, meaning if I moved the joystick up expecting the robot to move "forward" the motor will actually spin in reverse.
While programming, we can adjust this by adding a negative symbol from the Math menu.
It will snap between setting the motor power and the joystick calls:
Save your OpMode and test it out!
When you are ready, add similar controls for the HD Hex Motor on the RightStickY.
Because our servos are moving between positions rather than setting a power, they must be bond to a Boolean button on the gamepad, such as the D-Pad, bumpers, or symbol buttons.
What happens if we try to connect one of these gamepad buttons direction to where we set the servo position?
Blocks will not allow this connection since it would not be functional. We need to instead use a Logic block to say "If the gamepad button is pressed, do ________"
If/Else statements are one of the most common and fundamental logic statements in programming. As the name suggestion, this allows us to program a check for the robot to see if something is happening then react based on the options available.
In this instance, let's set our If/Else to be if the Triangle button on the gamepad is pressed move the servo to Position 1.
Save your OpMode and give it a test!
If If/Else block is editable to add additional checks all together! To do so click the gear to open the block's menu.
Adding additional "else ifs" extends the blue block:
Give this a try to set a variety of servo positions based on which button is pressed!
Let's take a look an example of how an If/Else Statement reads in a human friendly way.
The above can be read "If the Y button is pressed then move the servo to position 0, else if the A button is pressed move the servo to position 1."
Each pair contains the check or "if" and what should happen, the "do". Since there are multiple checks, after the first is reported as false the robot moves on to the next one, "else if".
