In engineering, there are multiple ways to solve problems.

Computer programs use logic to control what happens when.

The outcome of a program is affected by the robot assembly (which parts are connected and how they are connected to the robot) and the program itself.

Often multiple rounds of testing (design, build, test, repeat) are needed to create a successful program.

If/then statement

while loop

input

output

variable

• LEGO Mindstorm Robots (E779, E780, E781, E782, E783, E784, E785)
• Portable Wifi Router (E786)
• Ruler (one per group)
• Each group will need at least one device (laptop, chromebook, iPad, etc. Must have internet access)
• Each group should have access their own Open Roberta Account (ideally all students should have their own account). To create an account follow the instructions found here: https://ucsf.box.com/v/ORNewAccount

Daly Ralson Resource Center:

Lego Mindstorm EV3 robot (E779, E780, E781, E782, E783, E784, E785)

Portable Wifi Router (E786)

Groups of 3-4 students

2 hours

Students should have basic computer skills (Using a mouse/touch screen. Using a keyboard. Accessing a website). Students should have some familiarity with LEGOs.

• Engineering problems often have more than one solution.
• Identify “bugs” or mistakes inside of a program through careful observation and rewrite the program to fix these bugs.
• Identify robot inputs/outputs, and how they change as the program changes.
• Identify all robot sensors and motors, their uses and limitations.
• Understand how to configure a LEGO Mindstorm Robot in Open Roberta to match the real-life configuration of the robot.
• Identify a loop, its uses and limitations.
• Identify an If/then statement, its uses and limitations.
• Understand how to control robot motors, the method through which programs dictate speed, distance, timing, on and off.
• Identify variables within a program, their uses and limitations.

Open Roberta is a cloud-based programming environment inspired by Scratch. It was selected for this project because it can be easily run on any device with a wifi connection and because it is free. It also allows uses to switch between a few languages, aiding ELL students.

Like Scratch, Open Roberta is a visual based programming language, where programs are assembled using a series of blocks that are connected together. To simplify coding, the program only allows blocks that can function together to be connected together. They are color coded with little puzzle pieces to help users identify blocks that fit together.

Setting up Open Roberta:

Before teaching this lesson, create all of the programs described in https://ucsf.box.com/v/ProgrammingModulePrograms in your own Open Roberta account. Or email [email protected] for a copy of the programs in Open Roberta.

Each student group will need at least one Open Roberta account, though it is recommended that all students have their own account. Have each student/student group tell you their username. Send all of the programs described in https://ucsf.box.com/v/ProgrammingModulePrograms to their accounts before beginning the lesson. These programs are designed with several “bugs” and fixing these “bugs” allows students to rapidly learn to program in Open Roberta.

Materials:

Each group needs a LEGO Mindstorm Robot that is preassembled in the default configuration and connected to the wifi. Each student group will need a device connected to the Open Roberta site:lab.open-roberta.org

Robot Set-up:

If you are borrowing materials from the SEP resource center, the robots are preconfigured to connect to the Portable Wifi Router (E786). No additional set up required. Plug the router into an Ethernet cord connected to your school’s wifi. Robots will generally not connect to school wifi as the robot software has trouble connecting to hotspots. It is recommended to use the Portable Wifi Router (E786).

.

(15 mins)

To start the activity, all groups must connect their robot to Open Roberta. Have each student group use the Robot Quick Start Guide (https://ucsf.box.com/v/RobotQuickStartGuide) to help in this process. It might also be helpful for you to walk through these steps on a projector. Students will have to do this each time they use the robot, so do not skip this step.

Once all teams have a robot connected to Open Roberta, assign team roles. The recommended roles are:

• Reader: reads instructions to the team. Keeps the team moving through each program.
• Facilitator: Makes sure everyone agrees on the program before it is sent to the robot. Makes sure no one is confused before moving to the next section or program
• Programmer: Pairs their iPad (or computer) with the robot and sends the program to the robot. In charge of primary program building.
• Robot Manager/Observer (if team of 4): Handles robot/makes observations about robots behavior and explains their findings to the team.

It is recommended to assign the roles randomly and have students rotate through each role after each program is complete. Otherwise, strong programmers may dominate the “programmer” role or weak programmers will avoid the “programmer” role. It is important to stress that everyone can learn to program, but only if the team works together to make sure no one is left behind.

Let the students know that, if their group gets stuck, they should raise their hand. Remind them that there are many solutions to the same problem (no single solution) so to carefully listen to other group members’ ideas.

 Wait Until

Build program 1 with the entire class. Use the powerpoint presentation for this lesson as a guide https://ucsf.box.com/v/ProgrammingModule. Building this program with the class allows the whole class to learn how to find and assemble blocks. Start by clicking on the star icon at the top of the left menu. This reveals more programming options than the “basic” menu.

Tell the students that the first program follows a basic structure of requiring the robot to wait for an input before producing an output. The input will be a button press and the output will be a sound. Ask the programmer from each group to follow along with you.

1. Click on the “control” block.
2. Click on the “wait” block.
3. Drag the “wait until” block into the programming area.
4. Connect the “wait until” block below the “start” block.
5. Click on the “sensors” block.
6. Drag “button enter pressed?” block into the programming area.
7. Connect the “button enter pressed?” block to the right of the “wait until” block.
8. Click on the “action” block.
9. Click on the “sounds” block.
10. Drag “play file 1” block into the programming area.
11. Connect “play file 1” block below the “wait until” block.

Once you’ve completed the above steps, ask the facilitator in each group to make sure their program is identical to the one on your screen. The programmer can then send the program to their robot. They will need to press the arrow located at the bottom right of their screen.

Note: when a program is running on the robot, it will show numbers scrolling across the screen. These numbers are sensor data, which is shown because the “show sensor data” box is checked on the red “start” block. It is helpful for students to see these numbers just to know the program has started, but they may want to turn this setting off at another time.

Once all robots are running the first program, ask the reader from each group to start by reading the instructions for the first program. The observer should take notes, and the facilitator should make sure everyone understands the first program before moving on.

Checking for student understanding:

All blocks must be attached to a start block. Note that the blocks have different “connectors” that will only fit into certain “connectors” on other pieces. Ask the students why not all pieces can fit together? (Because some connections will make a program that doesn’t make sense. For example, placing the “button enter pressed?” after the “play file 1” would not make sense.)

Next the students will learn how their robot is configured, specifically which sensors and motors and plugged into which ports, and the current dimensions (wheel diameter, etc.) of their robot. This will be important especially once the students have started modifying or rebuilding their robots (i.e. using different sensors, changing motor placement, etc.)

Ask the reader to read the next section about the robot’s ports. The observer should identify the answers. The facilitator should make sure everyone agrees with and understands the answers.

Before proceeding, ask 4 volunteers to explain one sensor each. How does it work? What input is it searching for? How might you use it in a program?

Examples:

color sensor:

senses color, color intensity, light

useful for directing movement, identifying objects

touch sensor:

senses touch, button presses

useful for detecting if the robot bumps into something, touches something

ultrasonic sensor:

senses obstacles, uses sound waves (like echo location)

useful for avoiding obstacles, or stopping in front of an object

gyroscope:

sense changes in direction

useful to keep the robot moving in a straight line, useful to make accurate turns using degrees.

Next, ask the programmer to go to the “robot configuration tab” in Open Roberta. Have the observer and the programmer check to confirm that the robot configuration matches what is recorded in the computer. Each group will need a ruler for this section.

Open Roberta starts with a different default configuration. Note that in the correct configuration for the defaul robot, the track width is different (12cm instead of 18cm), Motor B is on the left and Motor C is on the right (see dropdown menu in orange box to switch sides for both Motor B and C). Additionally, a middle motor has been added to Motor A. To add a motor, click on the “Action” block and drag a middle motor to the Motor A port.

Use the powerpoint presentation to guide students through saving a configuration. Make sure all students save the above configuration.

Checking for student understanding:

Ask the students why robot configuration is important? Why might the program need to know how the robot is configured? What if you tried to run a program using a middle motor and the middle motor was missing from this configuration? How would the program know which port to use to talk to that middle motor? Make sure the students understand that altering the robot assembly (changing the shape or adding/removing motors and sensors) will change how a program functions.

Why is the track width and wheel diameter important for the program to know? Open Roberta will actually do calculations from these numbers to make accurate 90 or 180 degree turns, for example. Without an accurate configuration, the robot will not make accurate turns when programmed to. In the future, this is a great place to check when a student’s program isn’t working as expected.

Students may now proceed through the next of the program. Remind the reader to read the next section and all other students to be mindful of their roles.

Students will change the input, to the touch sensor, and the output to “play file 4” in this part of the activity. They should notice that the way the robot senses and responds is now different.

Program 1.1: Wait Block, Part B

Students will change the input, to the touch sensor, and the output to “play file 4” in this
part of the activity. They should notice that the way the robot senses and responds is
now different (below are the directions from the student sheet).

Students Go back to Program NEPOprog.

In Open Roberta, change the program to respond to one of the sensors attached to the
EV3 instead of the “enter” button.

In the sensors tab, drag the green block “touch sensor Port 1 pressed?” onto the work
area and replace the green block in your program

You can also change the way your robot responds.
Change the “play file” block to 4 instead of 1

Then run the program and compare the original program and the New Program.

Loops

Students will now learn about loops. The worksheet asks them to add a loop to program 1 and discuss this new program behaves differently. They should notice that the loop allows the program to repeat. They no longer need to send the program to the robot again to have the robot repeat the sense/response demonstration.

Checking for student understanding:

It is important for students to learn how to recognize what will be repeated in a program. The orange “repeat indefinitely” block will repeat anything within the box. Anything outside of this box will not be repeated.

**Trouble Shooting tip: Make sure to change to button enter & play file 1, can exit by pressing the center and down button

From this point forward. Allow student groups to proceed at their own pace. Remind them to switch roles with each new program.

If Statement or Decisions

Students should switch roles.

Use the powerpoint presentation, to guide students to find Program 2.

1. Go to the upper left menu
2. Select “My programs…”
3. Click on “programming 2” to open.

Program 2 demonstrates that there are many solutions to the same problem. Instead of a “wait until”, it has an “if/do” statement. An “if/do” statement will check if something is true or false before proceeding.

Checking for student understanding:

It is important for students to understand when an “if/do” statement will check if something is true or false. The worksheet will have them put another sound file into the “else” section of the program.

For most students this will result in a surprise! The robot will be noisier than expected, because the robot’s will play the second sound file over and over again until the enter button is pressed, and it will only “play file 1” while the enter button is pressed and then immediately go back to playing the second sound file. Students should understand that, because the “if/do” block is in a loop, the program/robot is constantly checking to see if “if/do” is true or false, therefore constantly playing one sound or the other.

This is a great opportunity to stop the class and ask about this surprise, or check in with groups to ask them if they were surprised by the robot’s behavior with this program, and why or why not.

From this point forward, allow student groups to proceed at their own pace. Remind them to switch roles with each new program.

The Color Sensor

Students should switch roles.

The next program introduces the color sensor. The program they will use has been programmed incorrectly. Note below that the “if/do” block with the yellow block will result in the robot showing the word “red” on its screen.

There are several important parts to this program. First, it demonstrates that several “if/do” blocks can be combined into a single loop or “repeat indefinitely” block. Second, it demonstrates how to use the color sensor to sense discreet colors. Third, it demonstrates how to get the robot to “write” a word on its screen. Fourth, there is more than one solution to fix this broken program.

Obvious solutions are to switch the yellow block out for a red block, or to change the text to “yellow” instead of “red”.  Allow the groups to find their own solution and search through the block menus to find the pieces they need. This exploration will be helpful for future programming. (They are likely other creative solutions beyond these two, i.e. deleting the entire “if/do” block for yellow so the robot only senses and reports blue and green.)

**The color sensor has trouble distinguishing blue and green. Sometimes this program will accidentally report blue as green and vice versa. This is a limitation of the sensor, and is not only important to note for future programs, but is also an important factor of any sensor (all will have limitations to their sensing capabilities).**

Checking for student understanding:

The color sensor is used a lot when modeling cellular behavior in robots. It can be used for phototaxis, to identify colors of objects or boarders to trigger reactions, as a “chemo” sensor (detecting the intensity of black on a black/white color gradient which is used as an analog for a chemical gradient).

Once student groups have finished the program, ask students what the robot is actually “seeing” (i.e. what does the robot report after observing a color?). Students should be aware that the sensor converts this color information into a number that corresponds to a category of color in the program.

Let the students know that the color sensor can also detect brightness of light. Light intensity also converted into numbers (higher numbers for brighter light). Ask students to brainstorm ways that this sensor could be used to move the robot toward light.

Motors and Gears

Students should switch roles.

***Be sure all groups remove the front robot arm before starting the program. Failure to remove the arm may result in motor damage. Warn all student groups not to force the robot arm during this activity as it may result in damage to the motor.***

This program is designed to teach students: how movement is encoded into a program, what that movement looks like, how gears can be used to adjust movement. The program has been programmed incorrectly such that the motor controlling the robot arm will spin 3 rotations. This is far too many rotations for the robot arm.

If the robot arm starts from a parallel position, the motor can only move about a third of a rotation (0.3) before the arm crashes into the brick. The 4-point gear makes this a little easier to see.

The worksheet then asks the student group to add another “middle motor” block that can move the arm back to its original position.

Checking for student understanding:

Proper control of robot motors will be important for solving robotics challenges later in the course. It’s therefore important that students grasp that motors turns (in the wheels or robot arm) can be controlled in a few ways, and that the angle and movement speed can be adjusted specifically for each task.

Understanding how gears change the direction, speed, and force of a movement will be important in designing new robot configurations to address new robotics challenges. Once a team has discovered the correct number of turns required to move the robot arm up and down. Likely they will have used visualization of the 4-point gear to determine the correct fraction of a turn needed. If a group has not discovered the solution check below for common issues:

Common issues with this program to look for in your student groups:

• Program has been successfully corrected, but program started before the robot arm was placed in the starting, horizontal position.
• Robot arm appears to be stuck. Program may still be running, therefore the motor is forcing the robot arm in a direction. Have the student group stop the program by pressing enter and down.
• Making the motor spin the opposite direction is not immediately obvious. The speed must be given a negative sign (even though speed is a scalar) to make the motor spin in the opposite direction.

Variables

Students should switch roles.

In Open Roberta: Please note: “Item” is a placeholder for a variable name—for example, Distance, Color, Push etc. “Set Item” allows you to command the variable to do something—for example, “Set Distance’ to 10 cm.”

This program is designed to teach students: how to create a variable, how to set a variable, how to use variables to direct the output of other blocks, and the effect of different number inputs on the movement of the robot. While running this program, the robot will count the number of times the touch sensor is pushed. It will play a sound when the “push” variable equals 3, however it is programmed incorrectly so that it will never reach 3.

Note that, each time the touch sensor is pushed, the program will add 2 to the “push” variable. So the first time the touch sensor is pushed, push will equal 2, then 4, then 6. Importantly, even though 3 is between 2 and 4, the variable “push” never equals 3 (that integer is skipped) so the program will never end.

Note that the program worksheet shows how to add variables by clicking the “+” button in the red start block. Without clicking the “+” button, there are no variable blocks to select in the menu. This will be important for future programs where students would like to add variables.

Note that this program also has a piece of code that is “greyed out”, not part of the main program and appears lighter than the other blocks.  This code will not be used as part of the program until its added to the main code block. The worksheet asks the students to add the code to the main program to allow them to troubleshoot their code.

Checking for student understanding:

Variables will be useful in robotics challenges if the students want their robot to remember a color or a number and use it later to make a decision, or to compare two inputs or sensed values before making a decision. It also allows for one input to be used multiple times in a program (i.e. the random number is reported on the robot’s screen and used for driving).

Though it might not be immediately obvious from this program, ask students when they might use variables in future programs. Why not take the random number generator and plug it directly into the movement block? How might that change the program?

Driving

Students should switch roles.

Also note, it’s fine for students to skip this activity. We have ordered the programs in this way so Program 6 is a bonus program for groups moving through the programs quickly that allows groups moving at a slower pace more time to finish program number 5.

This program is designed to teach students: how to program directional movement in the robot, to identify different movement options and modifiers in movement blocks, the difference between the robot turning a set degree and a single wheel turning a set degree, how to control movement using one or both of the robot wheels. The program has been programmed incorrectly such that the back button will make the robot go forward, the left button makes the robot go right, and the right button turns the robot left by turning motor C 90degrees, instead of motor B.

The worksheet asks students to test each button and identify the direction of robot movement then fix the program so that the robot will move in all four directions correctly.

Checking for student understanding:

An understanding of how to move the robot in different directions will be important for solving robotics challenges later in the course. It’s therefore important that students grasp that there are many ways to program the robot to move, and how to troubleshoot their code for robot movement that is incorrect.

Common issues with this program to look for in your student groups:

• Program has a double negative for backwards movement (-10 and drive “backwards”). Only one of these needs to be changed to get the robot to drive backwards when the back button is pushed.
• The right and left motor blocks in this program look similar, but one allows the programmer to turn the whole robot, using both wheels, while the other only controls one wheel (C). Ask the students why the robot doesn’t turn 90degrees when the right button is pushed. It’s because the motor block turns the wheel, not the robot, 90degrees.
• Having only one motor move only turns one wheel—allows for more
  precise movement

Wrap-up / Closure:

Here is a review of concepts that may be helpful to review after all groups have finished their programs:

Program 1:

• What is an example of an input (sense)? Button press, color presented, touch sensor pressed, objected detected in infrared sensor, turn detected by gyroscope, etc.
• What is an example of an output (response)? Movement, sound, words appear on the robots screen, change in movement (stop or change direction), etc.
• A simple program structure can be described as robot waits for input (sense), then preforms an action or generates and output (response).
• What is a loop? A section of the program that repeats. Why is it useful? If you want the robot to be checking constantly for an input. If you would like the robot to repeat an action, or repeat the entire program.

Program 2:

• How is an “if/do” block the same as a “wait” block? Both “check for” or “wait” for a certain input (sense).
• How is an “if/do” block different from a “wait” block? The “wait” block will not let the program proceed until it senses a particular input. The “if/do” will check for an input and do one action if the input is there (true) and another action if the input is not there (false). Importantly, with an “if/do” block, the program can still proceed even if the robot does not sense the particular input (can still proceed if false), unlike the “wait” block.
• What will the robot do if the “if/do” is false? If the robot does not sense its input, the if/do is false, and it will do whatever action is in the “else” section of the program. If there is no “else” section, or if the “else” section is blank, it will do nothing.

Program 3:

• What color(s) did the robot mix-up even after fixing the program? Green and blue.
• Why might the sensor not always read colors correctly? The color sensor projects light onto objects and then read which color is reflected. It has an LED (smaller blub on the sensor) that projects white light and a photo resistor (larger blub on the sensor) that senses the reflected light. (see more here: https://youtu.be/if1yk4WiaiQ). If colors are similar (like green and blue) and the sensor isn’t very close to the object, it may get the color wrong.
• Does distance matter when using the color sensor? Yes! The closer the sensor is to an object, the more accurately it will be able to read the reflected light as the correct color. The color sensor is averaging the light detected within its field of view. When the object is far from the color sensor, less of its field of view is occupied by the object, so it may average incorrectly. However, if the object is close to the color sensor, all or nearly all of its field of view will be occupied by the object. If the object is touching the color sensor (and blocking all ambient light) the sensor will read the object as black (see more here: https://youtu.be/IplkMchOabc).
• Why doesn’t the sensor work perfectly every time? Unlike our own eyes (which can also make errors, i.e. colorblindness, optical illusions), most sensors are very simple. LEGO sensors are definitely simple. But all sensors have limitations in how they work, when they work, and where they work. As an engineer, it’s important to keep your sensor limitations in mind when building your robot and designing your program (i.e. build the color sensor close to the ground to detect color changes while driving).

Program 4:

• How might robot movement be useful in future challenges? Robot can be programmed to drive towards objects, capture objects, lift or move objects, move as a response to sensing an particular input (i.e. happy dance).
• Does the robot know how its robot arm is positioned before the program is turned on? Does the programmer need to position the robot in a start position? The programmer will always need to check the robot arms are in the right starting spot and that the robot is starting from the correct starting location. The robot has no ability to check if its arms are in the right place or if it is starting from the right location. It’s dumb.

Program 5:

• How might variables be useful in the robotics challenges? If you needed your robot to remember a number or a color, how would you do it? Variables help the robot remember and compare inputs to make decisions later in the program. Variables can be used to help the robot determine which direction (left or right) has a darker color while moving on the chemotaxis mat. Variables can be used to remember which color the “cancer cell” bottle cap is, so that it can find a similar color while investigating the body in the immunoengineering mat.
• Why might it be helpful to have your robot report what each variable is set at on its screen while running the program? Having the robot report its variables while running is very useful for troubleshooting. It can to determine if the input is setting the variable to the correct value and if the robot is responding correctly to the variable after it’s been set.

Program 6:

• There are multiple blocks that direct robot movement (turn right vs, turn on left motor, etc.) Why might it be helpful to have multiple ways to move the robot? It might be helpful to plug in a variable or an input from a sensor as the speed for a motor, for instance, the higher the intensity of a light into one color sensor the greater the speed for a particular motor. Other times, simpler blocks (turn right, drive forward) might be more helpful.
• Is speed a scalar or a vector? Scalar. Then why do the drive blocks require both “backwards” and a negative speed to move backwards? Excellent question. It shouldn’t work like that, but it does. A strongly worded letter to Open Roberta about the difference between a scalar and vector might help them fix this bug.

Cellular Programming:

Do cells have their own programming? How can we reprogram cells?

A great extension to establish the robot as a model for cells is the Cell-to-Robot Word Map. This activity allows students to explore the central dogma (DNA à RNA à protein) and discuss which cell parts and cellular processes could be represented by robot parts and processes.

Sense and Response:

Do cells sense and respond like robots do?

A great extension to connect sense/response is the chemotaxis programming challenge paired with a chemotaxis activity with a live organism (i.e. physarum)

Final Challenges:

Ideally, the students will apply what they learned in this programming module to develop their own solutions to the final challenge mats (and chemotaxis mat).

ETS1 Engineering Design

HS-ETS1-2 Engineering Design

(Breaking down problems into smaller, more manageable problems is scaffolded for each program to guide students toward a solution.)

ETS1.C Optimizing the Design Solution

Practice 1. Asking Questions and Defining Problems

Practice 3. Planning and Carrying Out Investigations

Practice 4. Analyzing and Interpreting Data

Practice 5. Using Mathematics and Computational Thinking

Practice 6. Constructing Explanations and Designing Solutions

Patterns

Cause and Effect

Stability and Change