# Programming Your First Blocks OpMode
{% hint style="info" %}
This section pairs with Unit 1, Lesson 6 from the Intro to Robotics V2 curriculum.
{% endhint %}
## OpMode Structure
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[^1] 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[^2], 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.
### runOpMode
This contains the components of the program of the designated name. Anything sitting loose in the programming space, unless in a created function[^3], will not be read when the program is run.
### Call[^4] waitForStart
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.
### Call opModeIsActive
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[^5] alongside any other conditions, such as a count, sensor information, or time limit.
### Main Loop
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.
## Creating our First OpMode
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!
### Running a Program
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.
### What happens if the code is not in the loop?
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!
What happened?
Likely when you pressed to initialize the code on the Driver Hub, nothing appeared to happen differently. The message continued to only appear after pressing play.
Now try moving the call to update telemetry with it in the initialization area.
What happened?
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.
In the next section, we'll get the actuators on the testbed spinning!
[^1]: Comments are annotations intended to help organize and communicate within a program. The robot does not do anything when it reads them so they are purely for our us as programmers!
[^2]: A **variable** is a storage location with an associated symbolic name, which contains some known or unknown quantity of information referred to as a value
[^3]: Functions aid with organizing code. In Blocks they allow chunks of code to be broken out and represented by a call in the main loop. This helps keep the program from becoming one long, hard to read strand.
[^4]: In programming "call" means to execute. This might be used to activate a specific line of code, function, or reference collected information.
[^5]: Repeated sections of code
