Quick Learn — the model, the instructions, the program and the challenges. The theory is in Full Lesson.
EV3 Robotics›Level 1 · Beginner›Lesson 1
Level 1 · Lesson 1 · EV3-L01-0160 minutes · Ages 9–16 · Model: Driving Base
The Driving Base: a small robot on two wheels, each with its own motor, and a castor at the back to stop it tipping.
It is the plainest model in the whole course, and the most important one. Almost every robot you build after today sits on top of it — the sensors, arms and grabbers of later lessons all bolt onto this same platform. Get it right once and you get it for free for a year.
By the end of the lesson it will drive forward a distance you choose, come back, and turn to face where you point it — without a steering wheel anywhere on it.
An electric wheelchair has one large wheel each side, each with its own motor, and no steering wheel anywhere. The driver pushes a joystick and the chair works out how fast to spin each wheel.
This is called differential drive, and it is chosen because it can turn on the spot. A car needs a wide space to turn because its front wheels only angle a little. A wheelchair has to turn inside a bathroom doorway, so it is built to rotate about its own centre — something only two independently driven wheels can do.
Give the chair one motor and a steering linkage instead, and it needs a three-point turn to get out of a corridor. The same is true of your robot: with one driven wheel it can only travel in arcs, and a great many of this year’s challenges would be impossible.
A robot with two driven wheels does not need a steering wheel. It steers by driving one wheel differently from the other.
That is the whole idea of this lesson, and it is worth saying out loud before you touch a single brick:
Same speed on both wheels → straight. Different speeds → a curve. Opposite directions → it spins on the spot.
Everything else today is a way of making that happen reliably. The EV3 has a pair of blocks built exactly for it, and the module below is the reference you will come back to all year.
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.
Say this back before moving on: “My robot has one motor per wheel. If I want it to turn, I change what one wheel is doing.”
Before reading on: look at your model and find the electronic parts. Not the beams, axles or wheels — the parts with cables. How many are there?
Three. Here they are:
EV3 Brick × 1Large Motor × 2The Large Motor is the big, strong one — it is used for driving because it has the torque to move the whole robot. The Medium Motor is smaller and faster and does other jobs; you will meet it in a later lesson.
No sensors today. This robot cannot see, feel or measure anything about the world yet. It only does exactly what it is told, for exactly as long as it is told. Remember that when it drives into a table leg.
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.
The Brick has the numbered ports along one end and the lettered ports along the other. Today you only need two of the lettered ones.
| Part | Port | Why this one |
|---|---|---|
| Large Motor, left wheel | B | B and C are the conventional driving pair, and every movement block in this course assumes them. |
| Large Motor, right wheel | C | Keeping left = B and right = C means a program written by another group runs on your robot. |
Check your own wiring now, before going further:
This is the single commonest reason a driving base does nothing at all, and it is invisible in the program — the blocks are spelled perfectly and the robot still will not drive. Watch what happens when the cables and the block disagree:
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.
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.
Two things go wrong here, every time. The first is a Brick that has gone to sleep — press the centre button and try again. The second is connecting to the next group’s robot, which is why your Brick’s name matters. If a robot across the room starts driving when you press play, you have found the second one.
A cable that is plugged in is not the same as a Brick that is connected. Before you run anything, make the software tell you what it can see.
The check is simple: does the screen agree with the robot in front of you?
Two motors in B and C should show as two motors in B and C. A port showing nothing means the wire, not the program — go back to step 4 and fix it now. Everything after this assumes the software can see both motors.
Now change one thing at a time, and predict before each run. A prediction that turns out wrong teaches you something; watching without predicting teaches you nothing.
That last one catches nearly everybody. Rotations measure how far the wheels turn, not how long for — so a slower robot covers the same ground, just taking its time. Try it on the lab below before you try it on the floor.
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.
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.
The smallest program that makes this model do its job. Three blocks:
when program starts :: events hat set movement motors to [B v] and [C v] :: movement move [forward v] for (2) [rotations v] :: movement
Walk it in the order the robot runs it:
What success looks like: the robot drives in a straight line, roughly 35 cm, and stops on its own. It should not drift left or right, and it should stop without you touching anything.
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:
Switch mats above and every route below is redrawn on the mat you chose.
Work through them in order — each is harder than the last. The extra challenge comes after all three, and it is meant to make you plan before you build.
Start from HOME with the robot fully inside the start area, drive to A and stop with the whole robot inside A. Do it three times from the same spot — it has to land in A all three runs, not just once.
Fullscreen it while you build — you can pause and scrub with the player's own controls.
Start from HOME, drive to A, then turn and drive to B. The robot must end fully inside B, and nothing on the mat may be pushed out of place on the way. Work the turn out by changing what ONE wheel does — do not lift the robot and point it by hand.
Fullscreen it while you build — you can pause and scrub with the player's own controls.
Start from HOME, visit A, then B, then come back to HOME facing the way you began. Use rotations, not time: a program written with waits will drift on the second run and you will see it.
Your robot is a delivery trolley and the drop-off keeps moving. You will be told which station the delivery goes to — A, B or C — only AFTER your program is written, and you may not rewrite it once you are told. Plan on paper before you build anything. Work out what is the same about every route and what changes, and decide how your program will take the difference as a number you can set in one place. You will be asked two questions when you demonstrate it: how do you know it will reach the station, and what would you change if the mat were half the size? Have answers ready.
Fullscreen it while you build — you can pause and scrub with the player's own controls.