Numbers Nothing Measures: The Scoreboard

Variables

Why anybody needs one

Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.

Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.

Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.

That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.

The paper, and the two things you can do to it

Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.

set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.

• change leaves a trail — every value follows from the one before it. This is what counting is.
• set wipes the sheet. Use it to start a count, never to continue one.
• Press set score to 0 after counting up a few times and watch the whole history vanish. That is what happens to a count when a set block ends up in the wrong place — and it is the commonest variable bug there is.

Blocks reference

set [count v] to (0)

change [count v] by (1)

(count)

Set, or change?

set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.

The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.

Anything oval is a number you can pick up

EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:

• Oval — reports a number. The blue degrees counted, the timer, a distance, your own variable.
• Pointed — reports true or false. These go in an if or a wait until, not in a variable.
• Block-shaped — does something. These stack up; they do not fit inside anything.

So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.

This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:

when program starts :: events hat
[A v] reset degrees counted :: motors
set [degree_turn v] to ([A v] degrees counted :: sensors)
start moving [right: 30] :: movement
wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)>
stop moving :: movement

Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.

Reset at the start, every time

A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.

Why it matters

A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.

Comparing and combining

A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.

Blocks reference

<(x) > (50)>

<(x) < (50)>

<<> and <>>

<<> or <>>

Try it: which way round does it go?

Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.

Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.

• < is true while x sits on the left. Slide x past the marker and it flips.
• > is the same question the other way round — so exactly one of the two is true, unless the markers are on the same spot.
• = is true for one single position out of twenty-one. Try landing on it. That is why a sensor is almost never compared with =: a reading passes straight through the exact number without ever being measured there.
• not flips the answer, whatever it was. not (x < 4) covers everything x < 4 does not — including landing exactly on 4.

Try it: which numbers make it true?

The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.

Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.

Watch the circle, because it carries the part everyone gets wrong:

• Hollow ○ — the boundary is not included. x < 0.2 shades everything left of 0.2 but leaves 0.2 itself out, because 0.2 is not less than 0.2.
• Filled ● — the boundary is included. Choose = and nothing is shaded at all: one single number qualifies.

Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.

Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.

Try it: and, or, not

These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.

Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.

• and is true on one row out of four. It narrows — the robot acts less often, but more certainly.
• or is true on three rows out of four. It widens — the robot acts more readily.
• The two agree on the top and bottom rows and disagree in the middle. Whenever swapping one for the other seems to make no difference, you have only tried the rows where they agree.

Watch them decide

Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.

The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.

Choosing the threshold

The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.

Combining two conditions

and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.

In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.

The Brick display

The Brick’s screen is a small black-and-white whiteboard. You can wipe it, draw one of the built-in pictures on it, or write your own words at a spot you choose. It is how the robot tells a person what it is doing.

Blocks reference

clear display :: display

display [Eyes / Neutral v] :: display

display [Eyes / Neutral v] for (2) seconds :: display

write [Hello] at line (1) :: display

write [Hello] at x: (10) y: (40) with font [normal black v] :: display

Clear it, or write on top of what is there

The screen has no memory of whose writing is whose. It keeps every mark until something wipes it — including the marks left by the last run. Watch the same program with and without its clear display block.

Both Bricks are told exactly the same thing. The left one wipes the screen first, so line 7 holds one message and reads correctly. The right one never wipes, so each new message is drawn over the last and the words turn into a smudge. This is why a program that seems to display nonsense is usually displaying the truth — several times over.

Where the writing goes

There are two blocks for writing text, and they describe where in two completely different ways. Watch one message move around the screen under both of them.

Writing on a line

write [EV3] at line (1) is the simple one. You give it a line number and it puts the text there, starting hard against the left edge — you do not choose how far across, only how far down.

• Line 1 is the top. The numbers count downwards, so line 2 is below line 1, not above it.
• There are eight of them, each about ten pixels lower than the last. That means all eight sit in the upper part of the screen and the line block cannot reach the bottom at all.
• One message per line. Two messages sent to the same line land on top of each other and turn into a smudge — put them on different lines, or clear the screen in between.

For most robots this is all you need: a status word on line 1, a reading on line 3, a warning on line 5. Pick your lines at the start and keep each one for one job, the way you would keep one colour of status light for one meaning.

Writing at x and y

write [EV3] at x: () y: () with font [] treats the screen as a grid of pixels — 178 across and 128 down — and lets you put the text anywhere on it.

• x is how far across, from the left edge. x: 0 is the far left; x: 177 is the far right. Bigger x moves right, which is what everybody expects.
• y is how far down, from the top edge. y: 0 is the very top; y: 127 is the bottom. Bigger y means lower — this is the one that catches people out, because on a graph at school a bigger y means higher.
• The corner is 0, 0. x: 0 y: 0 is the top-left, and it puts the text in exactly the same place as at line 1 — the two blocks are describing the same screen.
• The pair of numbers is the top-left corner of the text, not its middle. The letters go down and to the right from the point you name.

The block ends with a font dropdown, and normal black is the usual choice. A larger font makes the writing easier to read from across the room but takes more room across the screen, so fewer characters fit before the text runs off the edge.

Which one to use

• Use lines for ordinary status messages — quick to write, impossible to get wrong, and eight of them is plenty for one robot.
• Use x and y when the position itself matters: putting a label and its number side by side, lining a heading up over a reading, filling the lower part of the screen, or moving something across the screen as a value changes.

Putting a number on the screen

The text slot of either block will take a reporter, so a sensor value can be shown directly: drop (4 distance in cm) into the slot and the screen shows the reading. That is the EV3’s version of a print statement, and it is the fastest way to find out what a robot actually thinks it is seeing.

A bare number on its own is hard to read, though. To show DIST: 23 rather than 23, use the operator block join [DIST: ] () to glue the label to the value, and put the join into the write block’s text slot.

when program starts :: events hat
clear display :: display
forever
  write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (1) :: display
end

Note the forever: a value written once is a value from the start of the program. To watch a reading change, the write block has to be inside a loop.

Advanced — a dashboard, not a number

Once one value is on the screen the rest follows, and the useful trick throughout is join: it glues two pieces of text together and hands the result to the write block. Anything that reports a value can go in either slot — a variable, a sensor, or another join.

A variable with a label on it

Counting is the classic case. A variable counts how many times the Touch Sensor has been pressed, and a bare 5 on the screen tells nobody anything — PRESSED: 5 tells them everything:

when program starts :: events hat
clear display :: display
set [count v] to (0) :: variables
forever
  wait until <[1 v] is pressed? :: sensors>
  change [count v] by (1) :: variables
  write (join [PRESSED: ] (count)) at line (1) :: display
  wait until <not <[1 v] is pressed? :: sensors>>
end

The two wait until blocks are what make it count presses rather than counting as fast as the loop runs while your finger is down. That is the Touch Sensor’s own lesson, but it shows up here because a counter on the screen is where you first notice it going wrong.

Several sensors, one line each

Give every reading its own line and keep it. A line that changes meaning halfway through a program is unreadable at a glance, which is the only speed a screen on a moving robot gets read at.

when program starts :: events hat
clear display :: display
forever
  write (join [DIST: ] ([4 v] distance in [cm v] :: sensors)) at line (2) :: display
  write (join [DEG: ] ([A v] degrees counted :: sensors)) at line (5) :: display
end

degrees counted is worth putting on the screen the first time you use it — it is the fastest way to find out whether a motor is turning as far as you think it is, and it is the block behind every “why did it stop early” question.

Turning a number into a word

Sensors report numbers, and people read words. The Colour Sensor reports 5; the person watching wants RED. A chain of if … then … else blocks does the translation, and it is worth doing once into a variable rather than in every write block:

if <([3 v] color :: sensors) = (5)> then
  set [name v] to [RED] :: variables
else
  if <([3 v] color :: sensors) = (4)> then
    set [name v] to [YELLOW] :: variables
  else
    set [name v] to [OTHER] :: variables
  end
end
write (join [COLOR: ] (name)) at line (4) :: display

The same shape turns a distance into a warning. Here the screen carries the number and what the number means, which is what lets somebody across the room tell whether the robot is about to hit something:

if <([4 v] distance in [cm v] :: sensors) < (10)> then
  set [status v] to [TOO CLOSE!] :: variables
else
  if <([4 v] distance in [cm v] :: sensors) < (30)> then
    set [status v] to [OBSTACLE FOUND] :: variables
  else
    set [status v] to [NOTHING FOUND] :: variables
  end
end
write (status) at line (3) :: display

Drive all four of those at once below. The screen is the real thing — five write blocks, five lines, and every one of them a join.

Advanced — stopping the screen from flickering

The moment a reading goes inside a loop, one of two things goes wrong, and which one depends on where the clear display block went.

Almost everybody tries clear inside the loop first. It gives the right text — and a screen that blinks several times a second, because between the clear and the write there is genuinely nothing on the screen and the loop goes round faster than your eye.

So the clear gets moved to the start of the program, the blinking stops, and the words go wrong. Writing text paints only the characters it has and leaves everything past them exactly where it was. Write RED over YELLOW and the LOW is still there: the screen says REDLOW. Go the other way — yellow first, then red — and it looks fine, which is why this bug takes so long to pin down.

when program starts :: events hat
clear display :: display
forever
  write (name) at line (3) :: display
end

The fix is to make the new text at least as long as the old one, and join already does that: pad it with spaces. RED plus three spaces is six characters — exactly enough to paint over YELLOW. Nothing is left behind, and nothing is ever blank.

write (join (name) [   ]) at line (3) :: display

Pad to the length of the longest thing that line can ever show. Six characters covers RED, BLUE and GREEN but not NOTHING FOUND — count the longest message, and add spaces to match. The same applies to numbers: DIST: 5 after DIST: 40 leaves a stray 0 on the end, so a line that shows a two-digit reading needs a trailing space.

Use clear-inside-the-loop when the whole screen changes at once and a flicker does not matter; use the padding trick whenever a value is being watched.

Advanced — a whole list on the screen

Once several values need showing, the line number becomes a counter and the values come out of a list: write item 1 at line 1, item 2 at line 2, and so on inside a repeat. That needs the list blocks rather than the display blocks, so it lives with them — Lists covers building one and reading it back item by item, and the loop that walks it is the same loop that fills the screen.

Why it matters

Machines in the real world tell you what they are doing: a microwave counts down, a lift shows its floor, a car dashboard warns you. A robot that shows WAITING and then OPEN is far easier to understand — and far easier to debug — than one that moves silently.