EV3 Robotics›Level 3 · Advanced›Lesson 15
Level 3 · Lesson 15 · EV3-L03-1560 minutes · Ages 9–16 · Model: EV3 Bowling Car
The Bowling Car: a driving base with a swinging arm on a Medium Motor that bowls a ball down a lane at a set of pins.
A bowling run is a routine — line up, adjust, approach, swing, follow through. Written as blocks, changing the run means rewriting the program. Written as a list, changing the run means changing four numbers.
By the end of the lesson your car will perform a run stored as data, and a short loop will be the only part that moves anything — which means you can change the whole routine without touching the code that performs it.
An industrial robot arm is almost never programmed by typing coordinates. An engineer takes a hand-held pendant, drives the arm to each position in turn, and presses a button to record it. The arm plays the points back afterwards at full speed.
The arm’s software does not change between jobs. What changes is the list of points. The same welding robot does a car door on Monday and a wing bracket on Tuesday, running identical code over different data.
Because the person who knows the job is not the person who writes the software. A production engineer can teach an arm a new path in twenty minutes; changing the program would mean a software release, testing, and a week of waiting.
Separating what to do from how to do it is one of the biggest ideas in computing. A CNC machine reads a file of moves. A washing machine’s programmes are tables of times and temperatures, not separate programs.
Every change would be a code change. Every code change risks breaking the parts that already worked — and the person best placed to make the change would not be allowed near it.
When the routine lives in data, changing the routine cannot break the machine.
You have used lists to remember what happened. Today a list holds what to do, and a short loop walks it — the same walking pattern from Lesson 9, doing something quite different.
when program starts :: events hat move [forward v] for (2) [rotations v] at (40) % speed :: movement turn [right v] for (0.3) [rotations v] at (30) % speed :: movement move [forward v] for (1.5) [rotations v] at (60) % speed :: movement [A v] run [clockwise v] for (180) [degrees v] at (100) % speed :: motors
when program starts :: events hat delete all of [moves v] :: list delete all of [amounts v] :: list add [drive] to [moves v] :: list add (2) to [amounts v] :: list add [turn] to [moves v] :: list add (0.3) to [amounts v] :: list add [drive] to [moves v] :: list add (1.5) to [amounts v] :: list add [bowl] to [moves v] :: list add (180) to [amounts v] :: list broadcast [run routine v] :: events
moves item 3 with amounts item 3. This is the table shape from Lesson 8.when I receive [run routine v] :: events hat
set [i v] to (1) :: variables
repeat (length of [moves v])
set [what v] to (item (i) of [moves v]) :: list
set [how much v] to (item (i) of [amounts v]) :: list
write (what) at line (1) :: display
if <(what) = [drive]> then
move [forward v] for (how much) [rotations v] at (40) % speed :: movement
end
if <(what) = [turn]> then
turn [right v] for (how much) [rotations v] at (30) % speed :: movement
end
if <(what) = [bowl]> then
[A v] run [clockwise v] for (how much) [degrees v] at (100) % speed :: motors
end
change [i v] by (1) :: variables
end| To change… | Blocks version | List version |
|---|---|---|
| How far the first drive goes | Find the block, change the number. | Change one number in the data. |
| The order of the steps | Drag blocks around and hope. | Reorder the add lines. |
| Run a different routine entirely | A second program. | A second set of add lines. Same interpreter. |
| Add a new KIND of action | Add blocks. | Add one rule to the interpreter — the only time you touch it. |
Two lists read at the same index is a table. Item 3 of moves and item 3 of amounts belong to the same step. They must always be added in pairs, or every step after the mistake refers to the wrong number.
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.
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.
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:
| Block | The locker version |
|---|---|
add [banana] to [snacks v] | Put a banana in the next free locker. Always the end of the row. |
(item (3) of [snacks v]) | Open locker 3 and tell me what is inside. One locker, one look. |
replace item (3) of [snacks v] with [candy] | Open 3, take out what is there, put candy in. Nothing else moves. |
delete (3) of [snacks v] | Empty locker 3 and close up the gap — everything after it shuffles down one. What was in 4 is now in 3. |
(length of [snacks v]) | How many lockers are in use. |
delete all of [snacks v] | Empty the whole row. This belongs at the top of a program. |
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.
Lists are not only for numbers. Anything a block can report can go in one:
| Block | What it does |
|---|---|
add [thing] to [List v] | Puts a new value on the end. |
(item (1) of [List v]) | Reads the value at a position. Positions start at 1. |
(length of [List v]) | Reports how many values are stored. |
delete all of [List v] | Empties it. This belongs at the top of the program, for the same reason a variable is set to zero there. |
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.
into a variable
into a list
Watch the variable box, not the list. Every reading it shows is correct; it is the ones it has already forgotten that matter.
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.
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
Watch i rather than the blocks. It is the only thing that changes between one pass and the next, and it is what makes each pass look at a different locker.
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.
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)
endOnly ever two numbers are being compared at a time. A sort looks complicated because it repeats, not because any one step is hard.
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.
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.
Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.
| Block | What it does |
|---|---|
repeat (10) end | Runs the blocks inside a set number of times, then carries on below. |
forever end | Runs the blocks inside over and over, and never carries on below. |
repeat until <> end | Repeats until a condition becomes true — a loop with a sensor as its exit. |
Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.
repeat (3)
forever
↑ this block never runs
Both programs contain the same green-light block. Let it run as long as you like — the right-hand ring will never turn green.
The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.
A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.
A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.
So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.
Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:
It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.
when program starts :: events hat
forever
if <[1 v] is pressed? :: sensors> then
[A v] start motor [clockwise v] :: motors
else
[A v] stop motor :: motors
end
endRead it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.
This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:
when program starts :: events hat if <[1 v] is pressed? :: sensors> then [A v] start motor [clockwise v] :: motors else [A v] stop motor :: motors end
The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.
with forever — a closed loop
without it — the common mistake
↑ running — for the only time
Both programs contain exactly the same if/else. The only difference is the forever block around one of them.
Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.
The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.
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.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
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.
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.
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
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.
set before the loop
set inside it
Both programs contain both blocks. Only the position of set [count] to 0 is different.
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.
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
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.
pick an oval
the same oval fits all three
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
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.
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.
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.
One part of the program says what to do. Another part knows how. Neither needs to change when the other does.
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.
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.
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:
| Block | The locker version |
|---|---|
add [banana] to [snacks v] | Put a banana in the next free locker. Always the end of the row. |
(item (3) of [snacks v]) | Open locker 3 and tell me what is inside. One locker, one look. |
replace item (3) of [snacks v] with [candy] | Open 3, take out what is there, put candy in. Nothing else moves. |
delete (3) of [snacks v] | Empty locker 3 and close up the gap — everything after it shuffles down one. What was in 4 is now in 3. |
(length of [snacks v]) | How many lockers are in use. |
delete all of [snacks v] | Empty the whole row. This belongs at the top of a program. |
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.
Lists are not only for numbers. Anything a block can report can go in one:
| Block | What it does |
|---|---|
add [thing] to [List v] | Puts a new value on the end. |
(item (1) of [List v]) | Reads the value at a position. Positions start at 1. |
(length of [List v]) | Reports how many values are stored. |
delete all of [List v] | Empties it. This belongs at the top of the program, for the same reason a variable is set to zero there. |
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.
into a variable
into a list
Watch the variable box, not the list. Every reading it shows is correct; it is the ones it has already forgotten that matter.
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.
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
Watch i rather than the blocks. It is the only thing that changes between one pass and the next, and it is what makes each pass look at a different locker.
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.
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)
endOnly ever two numbers are being compared at a time. A sort looks complicated because it repeats, not because any one step is hard.
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.
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.
Say this back before moving on: “The list is the routine. The loop is the machine.”
Swing the bowling arm by hand and watch where the ball would leave it. That release point decides everything about where the ball goes.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The chassis. Today its screen names each step as it runs, so a routine stored as data is still something you can watch happen. |
| Large Motor ×2 — the drive | A movement pair. The approach must be repeatable or the release point moves and the data is meaningless. |
| Medium Motor — the bowling arm | Swings the arm. Medium because a bowl is a fast flick rather than a heavy push, and speed is what sends the ball. |
| Touch Sensor — the trigger | Starts a run. Keeps the machine from bowling while somebody is setting up the pins. |
| The arm and ball cradle (not electronic) | The ball must sit the same way every time. A cradle that lets the ball roll to one side turns a repeatable machine into a random one, and no amount of good data fixes it. |
Sensors go in ports 1, 2, 3, 4. Motors go in ports A, B, C, D. They are not interchangeable, and nothing will tell you politely if you swap them.
| Part | Port | Why this one |
|---|---|---|
| Left drive (Large) | B | The movement pair. |
| Right drive (Large) | C | The other half of the pair. |
| Bowling arm (Medium) | A | Its own job, driven by its own step type. |
| Trigger (Touch) | 1 | Touch stays on 1 across the course. |
Check your own build now:
move forward drives nothing.Two routes, and either is fine. USB is the reliable one and the one to fall back on when a room’s Bluetooth is busy; Bluetooth leaves the robot free to move, which some models need.
Do these in order. Naming the Brick after you go looking for it in the list is how groups end up driving each other’s robots.
EV3 until somebody changes it.EV3.The two failures, every class, every time. The Brick has gone to sleep while you were building — press the centre button to wake it. Or you have paired with the group at the next table, which is why the name matters.
The long version, including Port View and how to read the port tiles, is in the Brick & Bluetooth guide.
Bluetooth — this one drives away from you. A trailing cable also adds a different drag on every run, which is a source of variation you invented yourself, and today’s whole point is that the same data should produce the same run.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
One stack loads the routine, one performs it. After this, you will only ever edit the first.
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
delete all of [moves v] :: list
delete all of [amounts v] :: list
add [drive] to [moves v] :: list
add (2) to [amounts v] :: list
add [turn] to [moves v] :: list
add (0.25) to [amounts v] :: list
add [drive] to [moves v] :: list
add (1) to [amounts v] :: list
add [aim] to [moves v] :: list
add (-0.25) to [amounts v] :: list
add [bowl] to [moves v] :: list
add (200) to [amounts v] :: list
write [PRESS TO BOWL] at line (1) :: display
forever
wait until <[1 v] is pressed? :: sensors>
wait until <not <[1 v] is pressed? :: sensors>> :: control
broadcast [run routine v] and wait :: events
write [PRESS TO BOWL] at line (1) :: display
end
when I receive [run routine v] :: events hat
set [i v] to (1) :: variables
repeat (length of [moves v])
set [what v] to (item (i) of [moves v]) :: list
set [how much v] to (item (i) of [amounts v]) :: list
write (what) at line (1) :: display
write (i) at line (3) :: display
if <(what) = [drive]> then
move [forward v] for (how much) [rotations v] at (40) % speed :: movement
end
if <(what) = [turn]> then
turn [right v] for (how much) [rotations v] at (30) % speed :: movement
end
if <(what) = [aim]> then
turn [right v] for (how much) [rotations v] at (15) % speed :: movement
end
if <(what) = [bowl]> then
[A v] run [clockwise v] for (how much) [degrees v] at (100) % speed :: motors
[A v] run [counterclockwise v] for (how much) [degrees v] at (30) % speed :: motors
end
change [i v] by (1) :: variables
endaim is a turn at a lower speed — a separate step type because a fine adjustment and a big turn want different speeds. Notice a negative amount turns the other way.broadcast and wait runs the routine so the trigger stack cannot start a second run over the top of the first. Lesson 4, doing exactly its job.What success looks like: press the trigger and the car drives, turns, drives, adjusts and bowls — with each step named on screen as it happens.
If a step is skipped, its name in the data does not match the name in the interpreter. bowl and Bowl are different words. This is the one fragile part of the technique and it fails silently.
One change at a time. Predict, then run, then look. For the first four, do not touch the interpreter at all.
add lines. Remember to move both the move and its amount, or every step after it will use the wrong number.wait, which pauses for that many seconds. This is the only change that belongs in the interpreter, and it is one new rule.Editing the routine should never mean editing the machine. If it does, the step type you need does not exist yet.
Look at your interpreter again. It is one loop with four rules in it, and every rule is a couple of blocks.
Now imagine a machine with twenty step types. That loop becomes twenty rules in one place, and it stops being readable — the very problem Lesson 1 solved for straight-line programs.
The answer is My Blocks again, but built out of each other: a pick up that calls lower, grip and raise. Naming things that are made of other named things is how a program stays readable at any size, and the next model is a robotic arm whose catalogue entry says exactly that.
Lesson 1 named a routine. Lesson 15 stored one. Next: routines built out of routines.
Build the model before you read any further. Everything after this is about making it do something, and none of it will make much sense with nothing on the table in front of you.
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
The same build on Google Drive — sometimes a video, sometimes a scan:
Use the viewer's own controls to zoom and turn pages. Fullscreen makes it big enough to build from.
Check the finished build against the picture before you switch anything on. A motor mounted the wrong way round is far easier to spot now than it is to debug later, when it looks like a program fault.
Work through the challenges in order — each is harder than the last. The mission comes after all three, and it is meant to make you plan before you build.
Change the routine without touching the interpreter. Make the car drive further on its first move and turn the other way on its second — by editing only the data. If you opened the interpreter, look again at which part you actually needed to change.
Add a new kind of step. Add "wait", which pauses for that many seconds, and use it in your routine to let the pins settle before bowling. This is the one change that belongs inside the interpreter. Say out loud why this one is different from challenge 1.
Two routines, one machine. Store two complete routines and let the Brick buttons choose between them before the run starts. The interpreter must not change at all. If you find yourself writing a second interpreter, stop — you want a second set of data.
Teach the car a routine instead of typing one. Build a recording mode: the user drives the car by hand using the Brick buttons, and every move they make is added to the lists as they go. Pressing the centre button ends recording. The car then plays the whole routine back by itself. This is how industrial robot arms are actually programmed, and it is a genuine piece of engineering. Plan first, on paper: what does one button press add to the lists? How do you record how FAR it drove, not just that it drove? What happens if they record thirty moves — does anything break? Two rules: 1. The playback code is the interpreter you already have, unchanged. If recording forces you to change how playback works, the design is wrong. 2. Recording must be able to happen twice without restarting the program — which means you know exactly where the lists get emptied.