Introduction to Loops

When it comes to programming, there's often times we want a robot to do something over and over again until we tell it to do something else. It might be a movement, a continual check of a sensor, or so many different things at once.

We could attempt to program each instance manually. In fact let's see if we can have our robot move a couple of feet using just the block setting the power fully.

Adding multiple drive blocks to a program

My OpMode is already becoming quite long yet the robot is barely moving anywhere!

The Control Hub reads through each line of code provided incredibly fast. So fast it may not even provide enough time for a motor to fully turn on before it's off to the next if there's nothing in place to allow a buffer or repeat.

There are options for adding timers to help, but in this tutorial we're going to focus on using loops!

Looping a drive block so long as the OpMode is active

Loops control the flow of a program by repeating the execution of the code within the loop until an exit condition is met.

Loops in Blocks

When using the recommended "BasicOpMode" sample in Blocks, the template provides a "while loop" by default that will continue after Play is pressed on the Driver Hub and until Stop is pressed.

The default loop in the BasicOpMode sample

This is where most of the OpMode will live creating what's known as an iterative program structure. What matters most with this loop is the call for if opModeIsActive.

If students experience a problem where their code appears to start then immediately stop, double check they have a loop in their OpMode! In OnBot Java, this appears as while (opModeIsActive()) followed by the code.

Call for if the opModeIsActive

This call checks that the OpMode should still be running, meaning Stop has not been pressed, and should ALWAYS be included with "while loops", even if there is another condition being checked. This is intended to be a safety feature to ensure everything shuts down properly when Stop is pressed OR in the event of a disconnect/malfunction.

Example of the loop checking two conditions

Programs running without this check may cause an error on the Driver Hub or crash.

Loops Practice

In Blocks, there are a few loop options, but we'll be focusing on the options to repeat a number of times and the "while loop":

Repeat and while loops in Blocks

In this practice exercise, we're going to have the robot count so first we need to create a new variable called "count".

Creating a "count" variable

This variable needs to be to 0 during initialization before we use it in the loop.

Adding the "count" variable to initiliazation

From the loop menu, we'll use the option to repeat 10 times. Then use our variable and math blocks so that the final count goes up by 1 each repeat.

Adding a repeat 10 times and math for increasing the count

Lastly, we need to add telemetry so we can see what the count currently is on the Driver Hub's screen. The telemetry AND telemetry update blocks must be in the repeat loop.

Adding telemetry to see the current count

Save and test the OpMode!

What happened?

Likely, you saw the number for the count rapidly increasing much more than 10 times. We can see just how fast the program cycles through each loop!

But why does it continue past 10 times?

Let's look closer at our program. Right now we have two loops going!

The two loops: while loop and repeat 10 times

Recall, our larger loop will continue until Stop is pressed since there is no other exit condition given. Each time the 10 count ends, the "while loop" starts again doing another 10 counts and again and again and again... until Stop is pressed.

To remedy this, we can tell the OpMode to stop once the 10 counts have ended.

Adding a call to request the OpMode stops once the 10 counts finish

Save the OpMode and try again!

What happened?

The program ended... but it was so fast we could hardly see it work!

Let's add a delay for this experiment to make it easier to watch. From the LinearOpMode menu, look for the sleep block:

Add the sleep block below the telemetry update. The default is a 1 second delay, which works well for this test!

Save your OpMode and test a final time!