Letting the User Choose: The Minigun Plus

The Brick buttons

The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.

Blocks reference

when [center v] button [pressed v] :: events hat

wait until <is [center v] button pressed? :: sensors>

Press to begin

A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.

The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.

A hat, or a wait?

• A hat gives the button its own separate stack, which can run at any time. Good for a control the user may press whenever they like.
• A wait puts the button in the middle of a sequence. Good for “press to begin”, where nothing should happen before it.

Why it matters

Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.

Lists

A variable holds one number. A list holds many, in order, under one name — so a robot can remember every reading it took rather than only the most recent.

A corridor of lockers

If a variable is a piece of paper with one number on it, a list is a row of lockers. Each locker has a number on the door, and each one holds something of its own. They all share a name — snacks, colours — and you tell them apart by the number, not the name.

The doors matter. You cannot see what is in the whole row at a glance: to find out what is in locker 3, you have to open locker 3. And if you want to change what is in there, you open it, take out what is inside, and put something else in. Try it — click a door.

1?

2?

3?

add crispsdelete all

length of snacks = 3

add candy to snacks

Three lockers are in use. You cannot see inside any of them until you open one — click a door.

Every list block is one of those physical actions, and the block for whatever you just did appears underneath the lockers:

add [banana] to [snacks v]

(item (3) of [snacks v])

replace item (3) of [snacks v] with [candy]

delete (3) of [snacks v]

(length of [snacks v])

delete all of [snacks v]

Deleting is the one that catches people. A locker does not stay empty — the row closes up. Delete item 2 of a five-item list and you have a four-item list, with everything after position 2 now one number lower than it was. Any position you wrote down before the delete is wrong afterwards.

What a robot puts in them

Lists are not only for numbers. Anything a block can report can go in one:

• Colours from the Colour Sensor. Drive along a line of coloured cards adding each reading, and at the end the robot has the whole sequence — not just the last card it went over.
• Positions in degrees. A list of angles is a list of places an arm should go: 0, 90, 180, 270. Walking the list drives the arm through the positions in order, and changing where it stops means editing a number rather than rewriting the program.
• Words. apple, banana, candy — a vending machine holds its stock in one list and the matching prices or positions in another, so item 2 of one lines up with item 2 of the other.

Blocks reference

add [thing] to [List v]

(item (1) of [List v])

(length of [List v])

delete all of [List v]

Collecting readings

The natural shape is a loop that takes a reading and adds it. Watch the same four readings go into a variable and into a list.

Notice that the variable is never wrong. Every number it shows is a real reading, correctly taken, moments ago. It simply has room for one, so each new reading pushes the last one out — and by the fourth stop three readings have quietly ceased to exist.

Afterwards the list can be walked to find the largest, the smallest, or the average — none of which is possible if you only ever kept the latest value.

Positions count from 1, not 0. A loop that starts its counter at 0 reads a position that does not exist and misses the first entry.

Reading the whole list out

Storing readings is only half of it. To use a list you walk it, and that needs one more idea: a variable that holds a position rather than a value. Call it i. Set it to 1, read item i, then change i by 1 — and the next pass round the loop looks at the next locker.

Two things make this work without anybody counting. The loop repeats length of colours, so it runs once per item however many there are; and i doubles as the screen line, so each item lands on its own row.

when program starts :: events hat
delete all of [colours v]
add [red] to [colours v]
add [blue] to [colours v]
add [green] to [colours v]
add [yellow] to [colours v]
clear display :: display
set [i v] to (1)
repeat (length of [colours v])
  write (item (i) of [colours v]) at line (i) :: display
  change [i v] by (1)
end

Nowhere does that program mention the number four. Add a fifth colour and it writes five lines, unchanged — which is the whole reason to ask a list its length rather than typing a number you will have to remember to update.

Going further: sorting, and finding the biggest

Once a robot can walk a list it can do real work on one. Both of these are the same trick — go along comparing two items at a time — and they differ only in what they do about it. Sorting swaps the pair; finding the biggest just remembers the winner.

when program starts :: events hat
set [i v] to (1)
repeat ((length of [nums v]) - (1))
  set [j v] to (1)
  repeat ((length of [nums v]) - (i))
    if <(item (j) of [nums v]) > (item ((j) + (1)) of [nums v])> then
      set [temp v] to (item (j) of [nums v])
      replace item (j) of [nums v] with (item ((j) + (1)) of [nums v])
      replace item ((j) + (1)) of [nums v] with (temp)
    end
    change [j v] by (1)
  end
  change [i v] by (1)
end

A bubble sort looks hard because it is a loop inside a loop, but no single step is: compare two neighbours, swap them if they are the wrong way round, move along one. Each full pass floats the biggest remaining number to the end — which is where the name comes from — so after as many passes as there are items, the list is in order.

Finding the biggest needs no swapping at all. Assume the first item is the winner, walk the rest, and whenever you meet something bigger, remember that instead. One pass, one variable. Swap the > for a < and the same program finds the smallest — which is how a line-following robot works out its black and its white before choosing a threshold between them.

Why it matters

This is data collection — a robot driving a course while recording distances, then reporting what it found. It is the difference between a machine that reacts and one that measures.

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.