Challenge 1
Climb one step square. Start the machine dead in front of the step, run it, and look at the BACK corners as it goes up — both should lift at the same moment. Do it three times from the same start.
What you are building 3 min
The Stair Climber: two Large Motors, one on each side, driving a mechanism that lifts the machine up a step and then pulls the rest of it after.
A step is not a floor. On a floor, one wheel running slightly faster than the other just means the robot drifts a little to one side — a nuisance. On a step, one side arriving before the other means the machine goes up at an angle, one corner catches, and it falls off backwards.
Both sides have to move as one. Today you find out why two motor blocks cannot promise that, and what to use instead.
In the real world 5 min
Where you have seen it
Delivery drivers use stair-climbing trolleys, and they are one of the few pieces of machinery that look like they should not work. Instead of wheels there are clusters of three, mounted on a spider. The cluster rolls along the floor, and when it meets a step it rotates as a whole, walking the next wheel up onto the stair.
Why it is built that way
The clusters on the two sides are joined by an axle running right through the trolley. That is not laziness — it is the design. A shared axle means the left cluster physically cannot rotate without the right one doing the same, so the two sides are kept in step by the metal, not by the person pushing.
Anything that climbs does something equivalent. A tracked digger, an escalator, a lift with cables on both sides: they all have something forcing the two sides to agree.
What would go wrong without it
Let one side get ahead on a step and the machine twists. Now the two sides are being asked to lift different amounts of weight, so the one carrying less pulls further ahead, which twists it more. It gets worse on its own until something jams or the whole thing tips.
On the flat, a difference between two sides is a drift. On a step, a difference is a fall.
The main concept — one command, two motors 6 min
You have two ways to drive a pair of motors, and they are not equally good. One of them keeps the pair level. The other only hopes.
The way that hopes
[B v] run for (1) [rotations v] at (40) % speed :: motors [C v] run for (1) [rotations v] at (40) % speed :: motors
You could fix the taking-turns part with the parallel stacks from Lesson 1. But even side by side, these are still two motors being told the same thing separately. If one meets more friction than the other it falls behind, and nothing in the program notices or corrects it.
The way that keeps them level
set movement motors to [B v] and [C v] :: movement move [forward v] for (1) [rotations v] :: movement
The magenta Movement blocks treat two motors as one machine. The Brick compares what each one has actually done and slows the one that is running ahead so they stay matched. That correction happens continuously, and it is the entire reason these blocks exist.
| Block | What it actually does |
|---|---|
| set movement motors to B and C | Nothing moves. It says which two motors are the pair, and which is left. A setting, like the stop setting in Lesson 2. |
| move forward for () rotations | Drives both, together and level, for that many rotations, then ends. |
| set movement speed to () % | Sets the speed the Movement blocks will use — the pair’s version of Lesson 5’s speed block. |
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 motors told the same thing are not the same as one pair told once.
This is not the opposite of Lesson 28. The Tricycle wanted its two motors to disagree, because the difference was the steering and the floor let the wheels travel different distances. A climber has both sides gripping the same step, so a difference has nowhere to go except into twisting the frame. Same blocks, opposite advice, and the build is what decides which you want.
The Touch Sensor as a start buttonWaiting for a press before anything moves. Open it if the sensor block is rusty.Show meHide
The Touch Sensor
The Touch Sensor is the simplest input the EV3 has: a button that is either pressed or not. That sounds trivial, but it is how a robot knows it has hit a wall, reached the end of a track, or been told to start by a person.
released
pressedBlocks reference
| Block | What it does |
|---|---|
wait until <[1 v] is pressed? :: sensors> | Holds the program here until somebody presses the sensor. |
<[1 v] is pressed? :: sensors> | Reports true or false. Drop it into a condition to make a decision rather than a wait. |
[1 v] when [bumped v] :: events hat | Starts a whole stack of its own. The dropdown chooses the moment: pressed, released or bumped. |
Three different events
A button is not only “pressed”. One press is three things: the moment it goes down, the time it stays down, and the moment it comes back up. Watch what a single press does to three programs at once.
when program starts
forever
if 1 is pressed? then
change count by 1
versus two hat blocks
1 when pressed
1 when bumped
0is pressed? in a loop0when pressed0when bumped
In a loop: 0 answers from one pressBumped: exactly one
Nobody is touching the sensor. All three programs are watching it.
The middle counter is the one that surprises people. Nothing is wrong with it — a loop really does check that fast, and every check really is a separate answer.
Nothing there is broken. A loop really does get round hundreds of times a second, and each time it asks is pressed? the honest answer is still yes — so if that loop plays a sound or counts something, it does it hundreds of times from one finger. The two hat blocks each fire once, and they fire at different moments: pressed the instant the button goes down, bumped only when it comes back up.
The three options, and what each is for:
- Pressed — the button is down right now. Good for “hold to run”.
- Released — it is up again. Good for acting when somebody lets go.
- Bumped — pressed and released. This is what you want for “click to start”, because it will not fire repeatedly while a finger stays down.
The classic bumper
when program starts :: events hat set movement motors to [B v] and [C v] :: movement start moving [straight: 0] :: movement wait until <[1 v] is pressed? :: sensors> stop moving :: movement
The robot drives until something presses the sensor. Note that the movement is started unmeasured on purpose — the sensor decides when to stop, not a distance.
Why it matters
Touch sensors are everywhere in machines you cannot see into: a lift knows the doors are shut, a printer knows the lid is closed, a washing machine will not spin until it is latched. They are safety devices as much as inputs.
Say this back before moving on: “Set movement motors does not move anything.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Compares the two motors many times a second and trims whichever is ahead. That comparison is the whole point of this lesson. |
| Large Motor ×2 | One per side, ports B and C. Both are lifting the machine’s weight against gravity, so both need the torque. |
| Touch Sensor | Starts the climb, so you can line the machine up against the step properly before anything moves. |
| The climbing mechanism (not electronic) | Whatever lifts the machine — a cluster, a leg or a track. Its two sides must be built the same, and this is the one model where a single extra spacer on one side really shows. |
Check the two sides are twins
- Look down at the model from directly above. Are the two sides mirror images, or has one got a beam the other has not?
- Turn each side by hand through a full cycle. Do they take the same effort, and do they catch at the same point?
- Set the machine on a flat table. Does it sit level, or does one corner lift?
- Find a step to climb — a book, a ruler, a stack of tiles. Keep the same step all lesson, or you are changing two things at once.
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 motor | B | B is left, always — and the Movement blocks are built around that assumption. |
| Right motor | C | C is right. Together B and C are the pair the Movement blocks drive. |
| Touch Sensor | 1 | Touch is always port 1 in this course. |
Check your own build now:
- Stand behind the climber, facing the step it will climb, and decide which side is left from there.
- Left motor in B, right in C, Touch in 1.
- Route both motor cables so neither can catch on the step. A cable hooked over an edge is a one-sided load, which is exactly the fault this lesson is about.
- Push the machine up to the step by hand and check both sides touch it at the same moment. If they do not, the machine is not square — fix that before programming.
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 for this one. A cable trailing off one side of a climbing machine pulls that side back — and a one-sided pull is the precise failure this lesson exists to prevent.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Two Large Motor tiles, on B and C, plus a Touch tile on 1.
- Turn the LEFT side by hand and check tile B moves. Then the right side and tile C.
- If they are swapped, swap the cables rather than the program. Everything you write afterwards assumes B is left.
- Press the Touch Sensor and watch its tile change.
Make it move 10 min
Line it up, press the button, climb one step, stop. Short on purpose — one step done properly is worth more than three done at an angle.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement write [Ready] at line (1) :: display [1 v] wait until [pressed v] :: sensors clear display :: display write [Naik] at line (1) :: display move [forward v] for (2) [rotations v] :: movement play beep (70) for (0.3) seconds :: sound write [Selamat] at line (3) :: display
- set movement motors to B and C — the pairing. Still nothing has moved.
- set movement speed to 30% — slow. A climb is not a race, and a slow climb gives the Brick more chances to correct the two sides.
- Ready, then wait until pressed — the machine waits while you square it up against the step. This is the part people skip and then blame the program for.
- move forward for 2 rotations — one climb, both sides level, ending by itself.
- beep and Selamat — it tells you it finished, so a stall is obvious rather than ambiguous.
What success looks like: the machine goes up square. Watch the back edge rather than the front — if one back corner lifts before the other, the two sides are not in step, however level the front looks.
If it climbs crooked even with Movement blocks, the fault is mechanical, not electrical. The Brick can only match how far each motor turns; if one side’s mechanism is stiffer or geared differently, equal turning does not mean equal climbing. Go back to section 5.
Change it and test 8 min
One change at a time, and always from the same square start against the same step.
- Replace the Movement block with two separate Motor blocks on B and C, in two parallel stacks. Same speeds, same rotations. Climb the step and watch the back corners.
- Now make it harder for them: tape a small weight to one side only, and run the two-Motor-block version again. Then run the Movement version with the same weight. This is the whole lesson in two runs.
- Put the speed up to 70% with the Movement blocks. Faster is not obviously better here — say what goes wrong.
- Change the climb to 4 rotations and try two steps in one go. Does the second step work as well as the first?
- Add a
wait (1) secondsbetween two separate 2-rotation climbs. A pause to settle between steps. Better or worse than one long climb?
Step 2 is the evidence, and it is worth doing properly. The weighted side falls behind badly with two Motor blocks and barely at all with a Movement block — because only one of those two arrangements is checking.
Movement blocks do not make the motors equal. They notice when they stop being equal and do something about it.