What’s the point?
To help students understand that in order to get information from the environment, a robot must have both a sensor and a program set to accommodate and process information coming in through the sensors.
To help students understand that a program uses sensory input to make decisions about what to do next
(e.g., If this input comes in, do one thing; if another input comes in, do something different).
What you will need:
For each group:
• The Robotics Inventions™ kit
• A disk
• A copy of the Technical Guide
• Roverbot building instructions, Constructopedia, pages 12-17
• A building bin (optional)
• Student activity sheets
For the class:
• Transparencies # 2, 2A, and 3
• One pre-built M. Pathfinder
Programs used : StartTouch (to initialize an input port for touch); StopOnPres1; StopOnPres2 (found on the student activity sheets)
Prepare Ahead:
1. Make enough copies of the Working with Touch Sensors student activity sheets for each student to have one.
4-1

2. Download the StartTouch program into slot #5 of the M. Pathfinder you will be using for demonstration. This program must run at least one time before you can get touch sensor readings by using the View on the display window.(See Important Note in the box below.)
About the touch sensor The touch sensor consists of a small pushbutton built into a 2 X 3 Lego™ brick.
Notice that four out of the six studs are wired. Therefore, it is important to place the connector wire on top of the wired studs. The touch sensor has two discrete states—pressed and released. A sensor block can be set to check whether the sensor is pressed or released.
A sensor block can also be set to check whether the sensor is clicked— pressed and released within 0.25 seconds.
The RCX Code notation The RCX Code notation The RCX Code for a pressed sensor is an arrow pointing to the for a released sensor is an arrow pointing away from the notation for a clicked sensor is a sensor with pushbutton. pushbutton. no arrow.
B-5
Important Note: Use the View button on the RCX to see the state of the touch sensor (1=pressed;
0=released; 1 followed by 0=clicked) on the display window. Accurate information will be displayed only after you initialize the input port for that sensor. That means that you have to download and run a program containing a touch sensor block. Note that this needs to be done every time you-install firmware.
Troubleshooting : If using the View button you do not get a 0 when the sensor is pressed and a 1 when it’s released, download a program containing a touch Sensor Watcher or a touch Stack Decision Maker and run it once.
New commands introduced in this activity:
SDM-1
SDM-5
SDM-6
Activity Overview
In this activity you will first use a built M.Pathfnder to demonstrate the use of a touch sensor. Then students will build Roverbot and attach touch sensors to it. Roverbot is a four-wheeled, two motor vehicle, with a sturdy base designed to hold both light and touch sensor attachments.
This activity is designed to help students understand the advantages and flexibility sensors add to a system. In a class discussion, you will remind students of the problem they solved in the previous activity— making a robot move toward a wall, hit it, and go back—emphasizing that the programs they wrote were limited to a specific distance from the wall. When the distance changed, the program had to change too. Here, students realize the robot has no way of telling that it hit something. This provides a smooth transition to the introduction of a touch sensor—a device that can register when it’s pressed and when it’s released.
SDM-2
SW-1
To introduce the touch sensor, you will connect it to a long connector wire and attach it to M. Pathfinder, Port 1. You will show students the pushbutton, explaining that it has three states, pressed, released and clicked.
You will then tell students that you want M. Pathfinder to keep going and to stop only when the sensor is pressed. Running it on program #1, you will press the sensor and have students observe that the robot is not responding to input from the sensor. You will then point out that in order to receive input from a sensor and to be able to decide what to do when it’s pressed or released, the robot must have a program to follow.
Next, you will have students build Roverbot, attach a touch sensor to it, and follow the activity sheet that will walk them through two programs
4-2

with sensor blocks ( Wait Until and Sensor Watcher ). You will decide whether to introduce the sensor blocks to the entire class before they do the activity sheets or to have the students work in small groups first, following the activity sheet and trying to figure it out on their own.
Transparency # 3 will help you guide a class discussion, highlighting the relationships between command blocks in different programs. This can be used as needed, either as an introduction or a summary (or both).
Finally, you will give students enough time to try to solve the RCXtra challenges. These problems give them an opportunity to apply newly introduced commands, and may inspire them to come up with their own problems to solve.
Programming for sensor input: To have a program act on incoming sensor input, the program must have a way of monitoring the incoming information. For example, if a program is set to run one way if a touch sensor is pressed and another way if it’s not, then the program must have a way of checking whether or not the sensor is pressed.
RCX Code offers several ways to obtain sensor input, using Stack Decision Makers and Sensor Watchers.
Stack Decision Makers The Robotics Invention System places blocks that monitor incoming sensor information in several bins—Wait, Repeat, Yes or No, and Sensors. Since our activities are organized around kinds of sensors rather than around kinds of blocks , we’ve decided to cluster all sensor blocks that can be embedded in a stack into one group that we called Stack Decision Makers. These include the Wait Until ,
Repeat While , Repeat Until , and the Yes or No blocks. We called them Stack Decision Makers: Stack because they are always part of a stack, and Decision Makers because when it’s their turn to execute, the program has a decision to make—to wait, to execute one branch or another, or to continue to do what it has been doing.
Stack Decision Makers make a program branch, repeat actions, or wait for input. These include the Yes or
No block for branching, the Repeat While and Repeat Until for repeating a set of commands based on sensor input, and the Wait Until block for having a program wait until a certain condition is met and then executing the commands that fall under it.
Sensor Watchers also check for sensor input, but they are not embedded in a stack of commands. They are connected to the program at the top level (to the program block). At this level, Sensor Watchers monitor the sensors all the time (with preset intervals), checking for input repeatedly, while other parts of the program continue to run. With Sensor Watchers, a program can monitor up to 9 stacks, each with its own watcher.
Whole Class Activity
Before students build Roverbot : Remind students of the problem they solved last: having M. Pathfinder move towards a wall, hit it, and go backwards. Ask students whether or not they think M. Pathfinder had a way of telling if it hit something. Explain that it really didn’t matter that there was a wall at the end of its trip forward; it was basically programmed to move forward for a certain amount of time.
4-3

4-4
How can we explain. . .
Using the View button on the RCX, pointed to a port where a touch sensor is connected, it sometimes happens that the number 100 is displayed when the sensor is pressed, rather than the expected number 1. This happens when a touch sensor is connected to a port that has not been initialized to use a touch sensor, but instead was initialized to read a light sensor.
If this happens, initialize the port by running any program with a touch sensor watcher (e.g., StartTouch) block once.

Show the class the touch sensor. Explain that in order to tell when it’s pressed, a robot must have a way to get that information. A touch sensor, with its pushbutton, can send a signal to the RCX each time there is a change in its state—if it’s pressed after it has been released; if it’s released after being pressed; or if it’s pressed and immediately released (clicked).
Connect the touch sensor to a long connector wire and attach it to an M. Pathfinder. Tell the students that you have connected a touch sensor to M. Pathfinder and that you want it to stop when you press the touch sensor, which would be similar to the touch sensor being pressed against another object such as the wall. Run it on Program 1. Press the touch sensor. (It won’t stop.) Ask the students why they think it won’t stop. Point out that the touch sensor is in good working order, as shown on the display window when you view input from the touch sensor. When it’s pressed, the display reads 1; when released, it reads 0.
It is important that students understand that it is not enough to add a touch sensor. The program has to have a block that reads information from the touch sensor and then makes a decision about what to do based on this information (e.g., If it’s pressed, turn motors off).
Tell students that it is better to work with a sturdier vehicle when attaching sensors. (It is easier to connect sensor attachments to a sturdy construction.) Explain that they’ll be building Roverbot, adding touch sensors, and programming it to accept touch input.
Small Group Activity
Building Roverbot : Have students work in small groups, following Constructopedia building instructions, pages 12-17. Give each student a copy of the activity sheet. As they build, talk to students in their groups, showing them the touch sensor and how it should be connected to the connector wire. Point to the 4 wired studs on the sensor and explain that the connector wire must be connected on top of these studs. Explain that, unlike motors, sensors are connected to input ports, marked 1, 2 or 3.
Have students follow the Working with Touch Sensors activity sheet, attaching a touch sensor to their
Roverbot and programming it to receive touch information. As they work in small groups, make sure students understand the problem they are trying to solve: causing Roverbot to change its behavior in response to input from a touch sensor.
The following Programming Highlights explain the programming ideas that students will need to master in order to solve this problem. They also note potential confusion points, with suggestions for what you can do to help your students work through them.
In this activity students are working with the Wait Until and Sensor Watcher sensor blocks. In the next activity they may be using the Yes or No Stack Decision Makers. We’ve decided to discuss all programming highlights here in order to give you a more global view of the various ways to get information from a sensor.
We do not recommend introducing all these concepts in the first sensor lesson.
4-5

Wait Until This Stack Decision Maker block makes a program pause and wait until a certain condition becomes true (e.g., wait until the touch sensor is pressed). Stack commands attached to a Wait Until block will not run until the sensor condition is met.
Once the specified condition is true, the program continues top-down, carrying out the stack that follows. The entire sequence only runs once.
In this block the program looks for touch information coming through input port 1.
Click wizard tab
The question that the program is evaluating is “Is the touch sensor pressed?” As indicated by an arrow pointing at the pushbutton. To see the condition, users must click on the wizard tab.
SDM-1
Be on the lookout
It is critical that the sensor be connected to the same port as the one selected in the program. By default, port 1 is selected in sensor blocks, unless it’s already taken by another sensor. It sometimes happens that students connect a sensor to ports 2 or 3, but forget to change it in the program. They are then puzzled when their robot doesn’t do what they expected it to do.
What you can do: Students are likely to be away from their computer when testing a program. If the above problem comes up, suggest they go back to look at their program and check their sensor selection.
Sometimes students attach a stack of commands to a Stack Decision Maker, losing sight of the condition they are trying to satisfy.
This is likely to come up especially with the Wait
Until, Repeat Until and Repeat While blocks because these blocks do not have any iconic indication of the desired sensor event.
Tell students to open the wizard by clicking the wizard tab and to go to the sensor event box.
Pointing to the sensor event, ask the students,
“What is the question the program is asking here?” Have students translate the iconic representation to a question. Then tell them the program is going to stop waiting once the answer to this question is “Yes.”
In this block the question the program is evaluating is “Is the touch sensor released?” As indicated by an arrow pointing away from the pushbutton.
It is important no to confuse the Stack Decision
Maker Wait Until with the Wait For block.
The Wait For block is not a decision maker.
It is important not to c
SDM-1
R/W-1
4-6

Touch Sensor Watcher: The Touch Sensor
Watcher monitors the state of the sensor, watching for a specific condition—pressed, released or clicked. It sets off a stack of commands attached to it when the condition becomes true. Translated to plain English, each touch Sensor Watcher is set to watch for a sensor event, say if the sensor is pressed, as if continuously asking the question “Is the touch sensor pressed?” As soon as the answer to the question is “yes,” the watcher sets off the stack attached to it.
Note that the Sensor Watcher monitors the state of the sensor frequently, as if repeating the question over and over again.
The question here is,
“Is the sensor pressed?”
Each time the sensor is pressed the stack is carried out.
SW-1
Be on the lookout
It sometimes happens that students connect a sensor to ports 2 or 3, but forget to change it in the program.
See note in the “Be on the lookout” on page 4-5.
It is important that students understand that a stack attached to a sensor watcher will be carried out each time the specified event becomes true. In the Move example, the stack is carried out when the sensor is pressed.
Continuing to hold the sensor pressed will not trigger the stack again. The sensor must be first released and then pressed again for the stack to retrigger.
What you can do: Explain that when a watcher monitors the sensor, it looks for
“something interesting” for the program. The first time the event becomes true is always “interesting.”
After the first time, the watcher will be looking for a change before it will consider the event to be true again.
Here two watchers monitor the touch sensor attached to port 1, each watching for a different event. One asks, “Is the sensor pressed?” The other asks, “Is the sensor released?” as indicated by the arrows. Each watcher will trigger its stack as soon as its condition becomes true.
Note that click is yet another event a touch sensor watcher could test for. A program recognizes a click as a press followed by a release within 0.25 seconds.
4-7

What happens if the touch sensor is pressed while a stack is still running?
If you press the touch sensor once, the stack attached to the watcher is set off. If uninterrupted, all the blocks in the stack will be carried out.
However, if you happen to press the senor again, before the stack is finished, the stack will start over from the top without executing the rest of the commands.
If the touch sensor is pressed again while the program is executing the second On AC
For 3 block, the stack will retrigger without beeping.
© 2002 The LEGO Group. Used here with permission.
4-8

Motors don’t stop, unless told to do so (well, almost) Once a motor is turned on, it will stay on until an Off command is issued. The Off command may or may not be in the same stack and may be hidden in an On For block.
A program can run up to 9 stacks in addition to the
Main program. An important question is how commands in one stack affect those in another. For example, what happens to a stack in the Main program when a sensor watcher stack is triggered? The simplest way to answer this question is to say, “it depends.”
It depends on whether or not the different tasks
(stacks) are seeking control over the same resource
(e.g., motors). For example, if the Main program turns on motors and a sensor watcher triggers a stack that has beep blocks as in the program TwoJobs below, the two stacks can be carried out without interruption.
Here there is no competition between the stacks. Each stack controls different resources: one controls the motors, the other controls sound.
However, as illustrated in the program Stop, both t the
Main stack and the Watcher stack are seeking control over the same motors. In this case, the motors will be turned off when the sensor is pressed.
In the program TwoJobs, motors A and C turn on in the
Main stack. It beeps whenever the touch sensor is pressed. Beeping does not interrupt the motors running.
The motors run continuously and beeping occurs in parallel, because beeping and motors running do not compete for the same resource.
Be on the lookout
When solving somewhat more complex problems, students must keep several things in mind when using a sensor watcher: what the robot is doing at the time sensory input comes in; how the robot will change its behavior as a result of a condition becoming true; how this change will affect what it has been doing.
What you can do: Transparency #2 provides several examples you can use to help students understand how commands in different stacks affect each other. (e.g., how commands in the Main program are affected by commands in a
Sensor Watcher stack).
4-9

If the stack triggered by pressing the touch sensor has an Off
AC block, it will turn off the motors as soon as the touch sensor is pressed. In this program, motors will not turn on again when the sensor is released.
Be on the lookout
Looking at the program Stop, students may expect the motors to resume running when the touch sensor is released. However, the last command the motors received was to turn off and the On AC command has already executed. Therefore, to restart the motors an
On AC block must be used.
You can use the program OnAgain,
Transparency #3, to illustrate this point.
Important Note: The programs TwoJobs and Stop are simple examples. They also tell only a very small part of the story. The next section provides additional details on how tasks interact.
.
Motors A and C are on and stay on until the touch sensor is pressed, then they turn off.
Motors A and C are on. When the touch sensor is pressed, motors reverse direction, stay on for 3 seconds, and then stop. They will turn on again when the touch sensor is pressed, not because of the On block in the main program, but because the
“press stack” is set off again.
Therefore, it’s going to be on for 3 seconds. (To have the motor continue to run forward for unspecified length of time you’ll have to add the Reverse
Direction and On AC blocks to the
Press stack.)
4-10

Transparency 2 (continued)
:Motors A and C are on. When the touch sensor is pressed, it beeps 3 times. The motors stay on while it beeps and beyond because nothing turned them off.
© 2002 The LEGO Group. Used here with permission.
Smart Tasking As you have seen in the program Stop, stack. a sensor event can interrupt the Main program. An important question is what happens to the unexecuted blocks in the Main program after a sensor event takes place? A feature called Smart Tasking manages the order of task operations. When an event triggers a stack, the blocks in the stack carry out. This may or may not interrupt the stack in the Main program, depending on whether or not the stacks issue commands to the same resource (e.g., the same motor, A). If commands do not address the same resource, both stacks continue to carry out (e.g., On A in one stack; On C in the other stack). If the commands address the same resource (e.g., On A in one stack, Reverse Direction A), the unexecuted blocks in the Main program are put on hold. The stack triggered by the event watcher carries out and only then the program returns to the Main
Motors A and C are on (moving forward). When the touch sensor is pressed, they reverse direction and continue to move for 1 second; then reverse direction again and continue moving (Nothing stopped the motors, so the On AC remains in effect throughout.)
Be on the lookout Students may expect a program returning to the Main program to treat On and On For the same way.
What you can do: Use Transparency #
2A to help you guide a class discussion about how Smart Tasking deals with the commands
On and On For.
See Additional Programming Highlights,
Chapter 8, for an example of what we mean by “addressing the same resource:”
4-11

Consider the program MainStreet. The program starts by turning on motor A for 3 seconds; While
A is turning, (but before motor C is turned on), the touch sensor is pressed. The Sensor Watcher stack triggers and the Main stack is put on hold.
As a result, motor A is turned off. The program waits 1 second, and then returns to the
Main stack.
Where will the Main stack pick up?
Notice the dashed horizontal lines in the picture above. They designate logical chunks of commands for the Smart Tasking. The program will pick up from the top of the chunk that was interrupted. In this example it will start over with the
On A For block.
It can be difficult to determine where in the stack the
Main program will pick up after a sensor event interruption. This difficulty is directly related to how students think of how much time the program spends executing a block.
The large majority of students have no difficulty understanding the operational differences between the power commands On For and On . However, many are likely to misconstrue an important distinction between the two—how long it takes the program to execute the block before it moves on to the next block. While in the On For block, the program focuses on the block for the specified length of time (e.g., 2 seconds), in the On block the program drops to the next block almost instantaneously.
4-12

Here is an example: In the first stack, the motors run for
2 seconds before the beep sounds. In the second stack the beep sounds as soon as the motors turn on.
But because the motors stay on, students may think that the program is still executing this block.
Here the program doesn’t leave the On
AC block for 2 seconds. Only then will it drop to the next block, Beep.
Here the program executes the On AC block in a fraction of a second and immediately moves to the next block, Beep.
How does this relate to Smart Tasking? Look at the
NoPickup and Pickup programs below.
In the program NoPickup, On AC executes instantaneously, and the program leaves the On AC block. When the touch sensor is pressed, the motors turn off and Smart Tasking returns the program to the Main stack. The motors do not turn on again because at the program had already left the On AC block.
Do not let the fact that the motors are still running confuse you.
4-13

On the other hand, in the program Pickup, if the touch sensor is pressed within 8 seconds, while the program is still executing the On AC For 8 block, the motors will turn off.
As soon as the sensor is released, Smart Tasking will return the program to the Main stack, where it will pick up at the top of the string of blocks enclosed in the horizontal dashed lines (i.e., starting over the On AC For 8 block).
Here the program executes the On AC block in a fraction of a second and immediately moves to the next block, Beep.
Teacher’s notes: In the program NoPickup, On AC executes instantaneously, and the program leaves the
On AC block. When the touch sensor is pressed, the motors turn off and Smart Tasking returns the program to the Main stack. The motors do not turn on again because the program had already left the On
AC block.
© 2002 The LEGO Group. Used here with permission.
Note : If you wanted the motors to stop when the sensor is pressed, you would either have to deactivate Smart Tasking or add an
End Program block in the sensor stack.
See Additional Programming Highlights ,
Section 8, for additional details on Smart
Tasking and End Program .
Here the program doesn’t leave the On AC block for
2 seconds. Only then it drops to the next block, Beep.
Teacher’s notes: On the other hand, in the program Pickup, if the touch sensor is pressed within 8 seconds, while the program is still executing the On AC For 8 block, the motors will turn off briefly. Smart Tasking will immediately return the program to the Main stack, where it will pick up at the top of the string of blocks enclosed in the horizontal dashed lines (i.e., starting over the On AC For 8 block).
4-14

This is a good time to have students use the newly acquired programming commands and concepts. Allow students enough time to experiment with Wait Until and Sensor Watcher commands, making Roverbot respond to input.
RCXamples : Here are some sample solutions to the problem of going and stopping as a result of responding to touch input.
Pressed
Here Roverbot moves forward when the sensor is released. It stops when the sensor is pressed. Motors will turn on each time the sensor is released.
RCXtras: If appropriate, give students additional challenges. Here are some examples with sample solutions.
1. Make Roverbot move forward then reverse direction when the touch sensor is pressed and beep when it is released.
Pressed
In this program, the robot will reverse direction when the sensor is pressed and beep when released. It will do this only once. The program will not respond to additional input from the sensor.
Note that here the motors stay on because there’s no command
Released that turns them off.
© 2002 The LEGO Group. Used here with permission.
4-15

Here Smart Tasking returns the program to the Repeat Forever loop. You can hear the motors “click” as they stop for a fraction of a second, hardly noticeable, and then continue to run.
Here motors turn off when the touch sensor is pressed. The program waits for
2 seconds before returning to the Main stack. Each time the sensor is pressed the motors will turn off for 2 seconds and then turn on again.
Note : Following the next set of programs, the motors stay on because there is no command block that turns them off.
2. Make Roverbot spin clockwise then change direction when pressed.
Running this program,
Roverbot will change direction once. But it will continue to go
Running this program, Roverbot will change its spinning direction each time the sensor is pressed.
© 2002 The LEGO Group. Used here with permission. because the motors were not turned off.
Pressed
4-16

3. Make Roverbot move forward, wait for the touch sensor to be pressed then beep and stop all activities.
Here pressing the touch sensor the first time causes the motors to stop.
Pressing it again won’t restart them.
4-17