EV3 Robotics›Level 1 · Beginner›Lesson 28
Level 1 · Lesson 28 · EV3-L01-2860 minutes · Ages 9–16 · Model: Road Roller
The Road Roller: two Large Motors driving the back, and three big tyres squeezed together on one axle at the front to make a heavy roller drum.
A roller’s job is repetition. It goes up the strip, comes back down it, goes up again — the same movement, over and over, until the surface is flat.
So this is the model that will finally catch out something you have been assuming since Lesson 10. You have written “out four rotations, back four rotations” a dozen times and called it equal and opposite. Today you do it five times in a row and find out that the robot is nowhere near where it started.
Behind every road resurfacing crew. The tarmac is laid hot and loose, and the roller goes over it again and again until it is hard enough to drive on.
The drum is heavy and it is wide and smooth. Weight presses the loose material together; width means each pass covers a useful strip; smooth means it leaves no marks behind.
And crucially, one pass is never enough. Compacting takes several runs over the same ground, which is why a roller driver spends the day going backwards and forwards over a strip most people would call finished.
Now the problem that is really today’s lesson. Each pass has to land on the same strip. If the roller wanders a few centimetres sideways each time, then after ten passes it is rolling somewhere else entirely — and there is a strip in the middle that has been rolled ten times and one at the edge that has been missed.
A small error you would never notice once becomes a large error when you repeat it. That is not a fault in the machine; it is arithmetic.
Every real movement is slightly wrong. Repeat it and the wrongness does not cancel out — it accumulates.
A motor block that says 4 rotations really does turn the motor four rotations; the Brick counts them and it is accurate. What is not accurate is what happens between the motor and the floor. The tyre grips a little differently each time, the surface is not perfectly even, and the machine is nudged by its own cable.
| What you assumed | What actually happens |
|---|---|
| Out 4, back 4, so it returns to the start. | It returns to nearly the start — out by a few millimetres. |
| Do that five times and it is still at the start. | Those few millimetres have become a few centimetres, all in the same direction. |
The important word is same direction. If the error were random, half would be too far and half too short and it would roughly cancel. It is not random: whatever causes it — a tyre with slightly less grip on one side, a cable pulling one way — causes it the same way every time. So it adds.
Measure your robot after ten runs, not one. One run tells you almost nothing about how a machine behaves in use.
A driving base has two Large Motors, one per wheel. You could drive them with two separate motor blocks — but they would never start at quite the same instant, and the robot would curve away. EV3 has a separate family of Movement blocks that treat the pair as a single driving base.
port Bport C| Block | What it does |
|---|---|
set movement motors to [B v] and [C v] :: movement | Tells the Movement blocks which two ports are the driving wheels. Put it at the top of the program, before any movement. |
move [forward v] for (2) [rotations v] :: movement | Drives both wheels together, so the robot travels in a straight line. |
move for (1) [rotations v] at (75) (25) % speed :: movement | Drives the two wheels at different speeds, which makes the robot curve. |
set movement speed to (50) % :: movement | Sets how fast the driving base travels from now on. |
set movement motors to [B] and [C] is the block that decides which two motors every Movement block after it will drive. It does not look at the robot. It drives the two ports you name, whether or not there is a motor in them — so those two letters have to be the two sockets the cables are actually in.
This is the single commonest reason a driving base does nothing, and it is invisible in the program: every block is spelled correctly and the robot still will not go.
the same program on both robots
The yellow outline marks the two ports the block is driving. A robot only goes straight when both of them have a motor in them.
Both robots run the identical program. The left one has its motors in B and C, so both named ports have a motor and the robot drives straight. The right one is plugged into A and B: the block drives B, finds nothing in C, and never mentions the motor in A at all — so one wheel turns, one wheel sits there, and the robot swings round the dead one instead of driving.
If neither named port has a motor in it — cables in A and D, say, with the block still set to B and C — the robot does not move at all. The program runs happily to the end and the Brick reports nothing wrong, because as far as it is concerned it did exactly what it was told.
So before you look for a bug in the program, look at the cables: read the port letters off the Brick, then make the block say those two. B and C are only the usual choice, not a rule — if your build has the driving motors in A and D, set the block to A and D and everything works.
Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.
The path is worked out from the two wheel speeds in the block, not drawn by hand — so changing the preset changes the numbers and the shape together.
Notice there is no steering block anywhere in that program, and no steering part anywhere on the robot. The turn is made entirely by driving the two wheels different amounts.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement move [forward v] for (2) [rotations v] :: movement move for (1) [rotations v] at (50) (-50) % speed :: movement
“Move forward 2 rotations” says nothing about the floor — it says how many times the wheels go round. How far the robot actually travels depends on how big the wheels are, and once round a standard EV3 driving wheel is about 17.5 cm.
Before doing any sums, get a feel for it. Drag the robot along and watch both scales at once — rotations on top, centimetres underneath, the same line. Land on the half marks: there is a number between 1 and 2, and it is 1.5.
Drag the robot, or use the arrow keys — it moves in half rotations. Rotations above the line, centimetres below.
1.5 — a half rotation past 1. Half a turn of the wheels is 8.75 cm, so halves matter.
35 ÷ 17.5 = 2. That is a number you can type straight into the block.
set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement move [forward v] for (2) [rotations v] :: movement
Steering at right 100 or left 100 drives the two wheels in opposite directions, so the base stops travelling and pivots where it stands. The angle it sweeps is a simple doubling of the rotations:
Half a rotation is the one worth remembering: a square corner, 90°.
| Rotations | The robot turns |
|---|---|
| 0.25 | 45° — half a corner |
| 0.5 | 90° — a square corner |
| 1 | 180° — turn round and face back |
| 2 | 360° — all the way round |
The one to memorise is 0.5 rotations = 90°. Everything else follows from doubling or halving it.
set movement speed to (20) % :: movement move [right: 100] for (0.5) [rotations v] :: movement
Turn slowly. The wheels on a driving base are big and the robot carries a lot of weight, so at full speed it keeps going after the motors stop and lands past the angle you asked for. Somewhere between 15% and 30% speed is where turns become repeatable. A turn that overshoots is almost always a turn taken too fast, not a wrong number.
These figures belong to your robot. The distance depends on the wheels and the angle depends on how far apart they are, so a wider base needs a different number for 90°. Test it, measure what actually happened, and adjust — the same discipline as the Gyro Sensor tolerance.
Every wheeled vehicle steers this way — a tank, a digger, an office chair with two driven castors. Cars use a steering rack instead, but a robot that turns by driving its wheels at different speeds needs no steering mechanism at all.
There are two ways to tell an EV3 motor how much to move: give it a length of time, or give it an amount of turn. Only the second one is repeatable, and that difference decides whether a machine works reliably or only sometimes.
| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | One full turn of the motor shaft, then stop. The program waits for it. |
[A v] run [clockwise v] for (180) [degrees v] :: motors | Half a turn. 360 degrees is one rotation. |
The counters below tick up in step with the shaft, so you can watch a rotation being counted rather than take it on trust.
the same movement, written in degrees
The two motor read-outs are the same measurement — 1 rotation is 360°. Use whichever makes the number easier to read.
Notice that the two motor counters finish together: 2.00 rotations and 720° are the same instant, because they are the same measurement in different units. So pick whichever makes the number easier to read. A winch that needs eight full turns is clearest in rotations. A gate that lifts a quarter turn is clearest in degrees — 90 rather than 0.25.
The third counter is the one that catches people out. The block counts turns of the motor, not of the thing it drives — and the gear in the demo is three times the size, so two motor rotations move it only 0.67 of a turn. Ask for two rotations and the mechanism does not move two rotations’ worth unless the gearing is one to one.
That is why a number that works on one build has to be retuned when the gearing changes — the program is right, the mechanism is different.
A printer feeds paper an exact distance; a lift stops level with the floor; a robot arm returns to the same place a thousand times. None of that is possible by timing a motor — they all count turns.
Say this back before moving on: “A small error in the same direction every time becomes a big error.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and adds the weight the roller needs. |
| Large Motor ×2 | Ports B and C, driving the rear wheels. |
| The roller drum (no cable) | Three tyres squeezed onto one axle. It is not driven — it is dragged along, and it is heavy on purpose. |
Before you blame the program, find out which way your particular roller already wants to go.
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 rear motor | B | B and C are the pair. B is always left. |
| Right rear motor | C | Decided from behind the machine, facing the way it drives. |
| Sensors | none | Worth noticing today: the roller cannot tell it has drifted. Only you can. |
Check your own build now:
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, and this time it is not optional. Today you are measuring drift in millimetres. A USB cable dragging behind the robot produces drift far bigger than anything you are trying to study, and it would make the whole lesson meaningless.
Six blocks: five passes up and down the same strip. Watch where it finishes, not how it looks while it runs.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (40) % :: movement repeat (5) move [forward v] for (3) [rotations v] :: movement move [backward v] for (3) [rotations v] :: movement end
Walk it in the order the Brick runs it:
What success looks like — and read this carefully. Success today is not the roller finishing on the line. Success is running it, measuring honestly how far off it is, and being able to say which direction the error went. A roller that misses by two centimetres and a student who measured it is a better result than a lucky run nobody checked.
Measure both ways. How far forward or back of the line did it finish, and how far to the left or right? They are two different errors with two different causes.
This is a measurement lesson, so keep a table. Three columns: what you changed, how far off it finished, and which direction.
Step 5 is the honest ending. You did not remove the error; you cancelled it out for one particular number of runs. Really fixing it would mean the robot checking where it is — with a sensor, or by reading its own motors — and that is what the next levels are for.
A robot that cannot check where it is can only ever guess, however carefully you tune the guess.
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.
This model drives, so its challenges are run on a mat. Mats differ between branches — check you are looking at the one in your room.
WRO 2026 RoboMission Elementary — Robot Rockstars · official WRO game mat, 2362 × 1143 mm
The challenges name these places rather than distances, so the same challenge works on any mat:
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.
Measure your drift honestly. Run the out-and-back program ten times, then measure how far from the start line the roller finished and in which direction. Do the whole thing three times over and report all three results. Consistent numbers mean the error has a cause.
Show that error accumulates. Measure the finishing error after 1 run, after 5 and after 10, three attempts each. Report the three averages and say whether ten runs really did produce about ten times the error of one.
Correct it, then break your correction. Adjust your forward and backward numbers until the roller returns to the line after five runs. Then run the corrected program for fifteen runs and measure again. Report both, and explain why a correction tuned for five does not hold for fifteen.
Roll a strip properly, and be honest about how well you did it. Your roller must cover a marked strip on the mat with repeated passes, finish at a station your teacher names, and be within a hand's width of where it should be. You must also hand in your measurements — the run is only half the work. Plan on paper before you drive. Decide how many passes the strip needs and how you will know, at the end, whether you actually finished where you meant to rather than just near it. Two questions when you demonstrate it. Which direction does your robot drift, and what in the build do you think causes it? And what would your robot need in order to fix the drift itself rather than being tuned by you?