Challenge 1
Drive the length of the table and back using only equal speed pairs, finishing within a hand's width of the start.
What you are building 3 min
The Racecar: two Large Motors driving the rear wheels, a small free-rolling wheel at the front, and a wedge-shaped body with a wing at the back.
Look closely at the front wheel. It does not steer. There is no steering rack, no servo, nothing to point it. It simply rolls wherever it is dragged.
So how does this car go round a corner? By driving one rear wheel faster than the other — and by the end of the lesson you will be setting those two speeds yourself, one number each.
In the real world 5 min
Where you have seen it
A Formula 1 car takes a corner at Sepang at over 200 km/h. Its front wheels do steer — but that is not the whole story of how it gets round.
Why it is built that way
Here is the fact the whole lesson turns on. On a bend, the outside wheel travels further than the inside wheel. They go round the same corner in the same time, along circles of different sizes — so they cannot be turning at the same rate.
That is why every real car has a differential: a gearbox between the driven wheels whose only job is to let them turn at different speeds while both still push. Invented in the 1820s, and still under every car on the Federal Highway today.
What would go wrong without it
Lock two driven wheels to one rigid axle and the car cannot corner honestly. One wheel has to scrub — skid sideways — for the whole bend. You can hear it in a supermarket trolley with a stiff caster, and you can feel it in a go-kart, which has no differential and hops its inside rear wheel off the ground through every turn.
A turn is a speed difference. It has never been anything else.
The main concept — one number each 6 min
In Lesson 11 you steered with a single number: 0 for straight, 100 to spin. Today you set the two motor speeds directly, and watch what steering was doing all along.
move for (2) [rotations v] at (50) (50) % speed :: movement move for (2) [rotations v] at (50) (25) % speed :: movement move for (2) [rotations v] at (50) (-50) % speed :: movement
The first number is the left motor, the second is the right — in the order set by set movement motors to [B v] and [C v]. Get that block wrong and every turn in your program mirrors.
Read the pair, predict the path
| Left | Right | What the car does |
|---|---|---|
| 50 | 50 | Straight ahead. Equal speeds, equal distance. |
| 50 | 25 | A wide curve to the right. The left wheel covers more ground, so the car swings away from it. |
| 50 | 0 | Pivots around the stopped right wheel — the tightest turn that still moves forward. |
| 50 | −50 | Spins on the spot. The wheels fight each other and the car goes nowhere. |
The rule to hold on to: the car always turns away from the faster wheel. If the left is quicker, it goes right. Say it out loud once and you will never have to work it out again.
So why does the steering block exist?
Because most of the time you want to say what the car should do, not what each motor should do. Steering is the friendlier block and you should keep using it.
The pair is for when you want a curve that steering makes awkward, when you need one wheel exactly stopped, or — most usefully — when one motor is mounted differently from the other and you have to compensate for it.
Driving with two motors
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 CBlocks reference
| 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. |
The letters must match the sockets
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.
when program starts
set movement motors to B and C
move forward for 3 rotations
the same program on both robots
2wheels driven · matched1wheel driven · mismatched
B and C: both sockets fullB and C: C is empty
Two robots, and the very same program: drive the motors in ports B and C forward.
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.
Straight, curved, and on the spot
Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.
when program starts
set movement motors to B and C
move for 2 rotations at 50 50 % speed
50left wheel · B50right wheel · C
Equal speeds → a straight line
Both wheels are set to the same speed.
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.
- Both wheels the same speed — the robot goes straight.
- One wheel faster than the other — it curves towards the slower side. The bigger the difference, the tighter the curve.
- One wheel forward, the other backward — it spins on the spot, which is how a robot turns in a space no wider than itself.
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
How far is one rotation?
“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 rotations26.3 cm
1.5 — a half rotation past 1. Half a turn of the wheels is 8.75 cm, so halves matter.
cm=2rotations
35 ÷ 17.5 = 2. That is a number you can type straight into the block.
- 1 rotation = 17.5 cm. Two rotations is 35, three is 52.5.
- Halves are real. 1.5 rotations is a perfectly good thing to type into the block, and it is 26.25 cm — right between the 1 and the 2 you already tried.
- To go a distance you have chosen, divide by 17.5. The calculator does it, but do a few by hand first — 35 ÷ 17.5 = 2 is worth seeing.
- Measure your own wheels before trusting the number. A base built with different wheels travels a different distance per rotation, and every calculation on this page moves with it.
set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement move [forward v] for (2) [rotations v] :: movement
Turning on the spot
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.
Why it matters
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.
Two numbers, left then right. The car turns away from the faster one.
Curves and point turnsFrom Lesson 11 — the single steering number, and where the turn happens.Show meHide
Speed and power
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.
Blocks reference
| 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. |
Set it first
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
A set speed to 25 %
A run clockwise for 2 rotations
speed last — does nothing
A run clockwise for 2 rotations
A set speed to 25 %
0.00rotations · slow0.00rotations · fast
Speed first: the movement was slowSpeed last: it only affects the NEXT movement
Two programs. Same two blocks in each — only the order is different.
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.
Slow is often better
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.
What’s in this build 4 min
Look at your car. How many electronic parts does it have? Fewer than you might guess for something this fast.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Sits low and central. It is also most of the car’s weight, which is why the model puts it between the axles. |
| Large Motor ×2 — the rear wheels | Large, not Medium: these carry the whole car. Each drives one wheel, which is what makes independent speeds possible at all. |
| The small front wheel (not electronic) | Free-rolling and unsteered. It goes where the back end sends it. Smaller than the rear wheels, so the nose sits low. |
| The rear wing (not electronic) | On a real car it presses the tyres into the road. On yours it is weight over the driven wheels — which does the same job for the same reason. |
No sensors at all. Every turn this car makes is a number you chose, run open-loop — nothing checks whether it worked. That is exactly why Lesson 37’s Gyro turns will feel like such a relief.
Ports — and the rule 4 min
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 wheel (Large) | B | B and C are the pair. The Movement blocks assume them, and B is the left-hand number in today’s block. |
| Right rear wheel (Large) | C | The right-hand number. Swap these two and every turn mirrors. |
“Left” means the car’s left, not yours. Sit behind the car, facing the way it drives, and decide from there. Half the mirrored turns in this lesson come from a student standing in front of the model.
Check your own wiring now:
- Left motor in B, right motor in C.
- Both wheels the same size. One larger wheel is a permanent speed difference the program cannot see, and the car will curve on every straight.
- Lift the car and spin both rear wheels by hand. They should turn with the same effort. A tight one will lose every race.
- Cables routed over the top, away from the wheels. A cable in a rear wheel stops that side dead — which the program reads as a very sharp turn.
Connect the Brick 4 min
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.
How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide
USB — the reliable one
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- Other end into the computer.
Bluetooth — name it first
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.
- Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
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. This car drives away from you at speed. A USB cable becomes a tether that either steers the car or leaves the desk with it.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two Large Motor tiles, on B and C. Two is the number — one tile means a cable is out.
- Spin the left wheel by hand. Tile B must move. Spin the right; tile C must move. If they are the other way round, fix the cables now — not the numbers in your program.
- Put the car on blocks so the wheels spin free for the first run.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
One lap of an oval: down the straight, round the bend, back down the other straight, round again.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement clear display :: display write [LAP 1] at line (1) :: display play beep (72) for (0.2) seconds :: sound repeat (2) move for (3) [rotations v] at (60) (60) % speed :: movement move for (2) [rotations v] at (60) (20) % speed :: movement end stop moving :: movement play sound [Communication / Goodbye v] until done :: sound
set movement motorsfirst. It sets which motor is the left-hand number. Everything after it depends on it, and it costs one block to be certain.- The straight is (60) (60) — the same number twice. Equal speeds mean equal distances mean a straight line.
- The bend is (60) (20). The left wheel does three times the work of the right, so the car sweeps right. Change 20 and you change how tight the bend is.
- The
repeat (2)makes the oval. Two straights and two bends. If your bends are not half-circles, the car will not come back to where it started.
What success looks like: the car runs a rounded rectangle and finishes roughly where it began, pointing roughly the way it started. Roughly is the honest word here — and Lesson 37 is where you stop accepting it.
If the car turns left instead of right, your B and C are swapped. Fix the cables, not the numbers — otherwise every program you write from now on is wrong in the same hidden way.
Change it and test 8 min
One change at a time, and predict before each run. Mark the car’s starting spot with tape so you can see how close it gets back.
- Change the bend’s second number from 20 to 40. Predict: tighter bend or wider? Now try 0, then −60.
- Make the straight (60) (55) — almost equal, but not quite. Run it down a long straight. A 5% difference does not look like much on the screen and it is very obvious on the floor.
- Raise both straight speeds to (100) (100). Does the car still hold its line? Fast robots wander, because both motors take time to get going and they never take exactly the same time.
- Now the real experiment. Run the same program three times from the same tape mark without changing a single number, and mark where it finishes each time. How far apart are the three?
- Run it once on the table and once on carpet. Same numbers, different floor. What does that tell you about programs that describe motors rather than journeys?
Steps 4 and 5 are the point of the lesson, and they are not really about the block. Nothing in this program checks whether the car went where you meant. It commands the wheels and hopes. That is called running open-loop, and every model you build up to Lesson 36 does it.
A program that commands motors is not a program that produces a journey. The floor gets a vote.
