EV3 Robotics›Level 3 · Advanced›Lesson 18
Level 3 · Lesson 18 · EV3-L03-1860 minutes · Ages 9–16 · Model: Motorbike
The Motorbike: two wheels in line, a Large Motor driving the rear one, a Medium Motor steering the front, and an Ultrasonic Sensor looking up the road.
Everything you have built so far could be told to go from stopped to full speed and would simply do it. A bike cannot. Ask for 80% instantly and the rear wheel spins, the front lifts, or the whole thing goes over sideways.
By the end of the lesson your bike will reach the same speeds it always could, but never jump to them — and stopping will be a controlled thing rather than an event.
A lift does not start at full speed. Watch the floor indicator on a tall building and you will see it accelerate over a second or two, run, then ease off before it stops. The engineers could make it snappier and deliberately do not — passengers would stumble, and a lift that spilled coffee would be replaced.
The same shape is everywhere: a train pulling away, a crane slewing, a camera gimbal panning, an electric window closing. All of them ramp up, run, and ramp down. It is so standard that motion-control engineers call it a trapezoidal profile — a picture of speed against time that is a trapezium.
Because a sudden change of speed is a large force, and force is what breaks things and tips them over. A gentle change of the same size, spread over a second, is a small force — same destination, much less drama.
A ramp does not limit how much the machine does. It limits how quickly it changes its mind.
A crane that slewed instantly would swing its load; a lift would injure people; a bike falls over. And in every case the machine is being commanded something it can technically do — full speed is within its power. What it cannot do is get there in no time.
The limit that matters is usually not the value. It is the rate of change of the value.
A ramp keeps two numbers: the speed you want, and the speed you are currently commanding. Every time round the loop, the current one moves a small step towards the wanted one.
forever
if <(current) < (wanted)> then
change [current v] by (2) :: variables
end
if <(current) > (wanted)> then
change [current v] by (-2) :: variables
end
[B v] start motor at (current) % speed :: motors
endwanted may jump from 0 to 80 in an instant; current takes forty passes to follow it.| Without a ramp | With a ramp | |
|---|---|---|
| Command | start motor at (wanted) | start motor at (current) |
| 0 → 80 | Instant. The bike rears or slips. | About a second. The bike accelerates. |
| Emergency stop | Instant. The bike pitches forward. | Controlled — unless you choose otherwise. |
| Top speed reached | Same. | Same. Nothing is given up but suddenness. |
That 2 is how much the speed may change per pass of the loop. Make it 1 and the bike is stately. Make it 20 and you have effectively removed the ramp. It is the only tuning knob, and it has a physical meaning: it is the acceleration limit.
The loop speed matters as much as the step size. A step of 2 in a loop that runs 100 times a second is a very different acceleration from a step of 2 in a loop with a wait 0.1 in it. If you add anything slow to the loop, the ramp changes without your touching it — which is a genuinely surprising bug the first time it happens.
Real vehicles brake harder than they accelerate, and so should yours. Two step sizes, chosen separately:
if <(current) < (wanted)> then change [current v] by (accel) :: variables end if <(current) > (wanted)> then change [current v] by ((0) - (brake)) :: variables end
accel of 2 and brake of 6: builds speed gently, sheds it three times faster. That asymmetry is a safety decision.If wanted is 41 and the step is 2, current goes 40, 42, 40, 42 — oscillating for ever around a value it can never land on. The fix is the deadband you already know from Lesson 10: when the gap is smaller than the step, just set it.
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.
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.
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
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.
Drag either marker, or use the arrow keys.
is x to the LEFT of it?
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.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
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.
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.
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
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.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
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.
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.
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.
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
speed last — does nothing
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
Keep what you want and what you are commanding as two separate numbers, and let the second chase the first.
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
speed last — does nothing
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
Say this back before moving on: “Wanted jumps. Current walks.”
Stand the bike up and push it gently. How much speed can it gain before it becomes unstable? That is the number your ramp exists to respect.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The frame, and the reason the bike is top-heavy. A tall mass is exactly what makes sudden acceleration a problem. |
| Large Motor — the rear wheel | Drives the bike. It has more torque available than the tyre can put down — which is why an instant command spins the wheel instead of moving the bike. |
| Medium Motor — the steering | Turns the front wheel. Steering also wants ramping: a bike whose bars snap to full lock at speed goes down instantly. |
| Ultrasonic Sensor — the road ahead | Supplies the wanted speed: clear road means fast, something ahead means slow. It sets the target; the ramp decides how quickly the bike obeys. |
| Wheels and tyres (not electronic) | Check both are true and neither rubs. A dragging wheel needs more power to start, which pushes you towards exactly the sudden commands this lesson is about avoiding. |
Give it a straight, clear run of at least two metres. Ramping takes distance by definition — a bike that accelerates gently needs room to do it, and testing on a short table teaches you nothing except that it fell off.
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 |
|---|---|---|
| Steering (Medium) | A | The fine-control motor, first port. |
| Rear wheel (Large) | B | The drive. Only one driven wheel, so there is no movement pair here. |
| Road ahead (Ultrasonic) | 4 | Ultrasonic stays on 4 across the course. |
Check your own build now:
start motor, not start moving — a movement block expects two.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. A cable on a two-wheeler is a fall. The bike is balanced at best, and a lead pulling on one side is exactly the disturbance it cannot absorb.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Show the problem, then fix it. Catch the bike on the first one.
when program starts :: events hat wait (2) seconds :: control [B v] start motor at (70) % speed :: motors wait (3) seconds :: control [B v] stop motor :: motors
when program starts :: events hat
set [current v] to (0) :: variables
set [wanted v] to (0) :: variables
set [accel v] to (2) :: variables
set [brake v] to (5) :: variables
clear display :: display
when program starts :: events hat
forever
if <((wanted) - (current)) > (accel)> then
change [current v] by (accel) :: variables
end
if <((current) - (wanted)) > (brake)> then
change [current v] by ((0) - (brake)) :: variables
end
if <([abs v] of ((wanted) - (current))) < (accel)> then
set [current v] to (wanted) :: variables
end
[B v] start motor at (current) % speed :: motors
write (wanted) at line (2) :: display
write (current) at line (4) :: display
end
when program starts :: events hat
wait (2) seconds :: control
set [wanted v] to (70) :: variables
wait (4) seconds :: control
set [wanted v] to (0) :: variableswhen program starts :: events hat
forever
set [gap v] to ([4 v] distance in cm) :: variables
if <(gap) > (60)> then
set [wanted v] to (70) :: variables
end
if <<(gap) < (60)> and <(gap) > (25)>> then
set [wanted v] to (30) :: variables
end
if <(gap) < (25)> then
set [wanted v] to (0) :: variables
end
endwanted; the ramp stack turns those jumps into something the bike can survive.wanted.What success looks like: the bike pulls away smoothly, runs, slows as it approaches an obstacle and stops before it — with no lurch at either end, at a top speed that would have thrown it over in step 1.
If line 4 never reaches line 2, your step size is smaller than the rounding, or the third rule is missing. If it reaches it in one pass, the step is so big the ramp is doing nothing.
One change at a time. Predict, then run, then look.
accel to 20. You have effectively removed the ramp. Compare with step 1 — this is the same failure, arrived at from the other direction.accel to 0.5. Very smooth, very slow to get going. Time how long it takes to reach full speed and decide whether you would accept it.brake equal to accel. The bike now takes as long to stop as to start. Put an obstacle in and see whether it stops in time — this is why braking is allowed to be harsher.wait (0.05) seconds to the ramp loop. The acceleration changes dramatically without your touching accel. Explain to a partner why — this is the loop-speed trap, and it catches everyone once.A ramp costs you nothing at the top and everything in suddenness. That is almost always the right trade.
Your bike is careful about how it changes speed. It is not careful at all about whether it should be running.
Press Run with the steering off-centre, or the sensor unplugged, or the bike lying on its side, and it sets off regardless — because nothing in the program checks anything before it starts.
A machine that refuses to start when conditions are wrong, and says why, is easier to use and much harder to break. Aircraft call it a pre-flight check; programmers call it a guard clause. The next model is a helicopter, and it will not take off until it is happy.
You have made a machine that moves well. Next, one that knows when not to.
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.
Find the largest acceleration your bike survives. Raise the step size until the front wheel lifts or the rear slips, then come back one step. Write the number on the board with your top speed. It is a fact about your machine, not about the program.
Brake harder than you accelerate. Use two separate step sizes. Set braking three times the acceleration and test stopping in front of an obstacle. Then make them equal and try the same stop. Say which you would fit to a real vehicle and why.
Find the loop-speed trap. Add a "wait 0.05 seconds" inside the ramp loop and run it without changing the step size. The acceleration changes dramatically. Explain to a partner exactly why — this catches everybody once, and understanding it is worth more than avoiding it.
Drive a course at the highest average speed you can without ever lurching. Set out a straight run with an obstacle part way along and a stopping line at the end. The bike must accelerate away, slow for the obstacle, pass it, speed up again, and stop on the line. Judged on three things, in this order: 1. It never lurches, wheelies or slips. Any of those and the run does not count. 2. It stops within 10 cm of the line. 3. Total time. Two rules: the acceleration and braking limits are named variables you can defend, and the wanted speed is set only by what the sensor sees — no timed sequences. The interesting discovery is that the fastest run is not the one with the highest top speed. Work out why, and write one sentence about it.
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.
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.