Challenge 1
Deal one card to a player exactly 60 cm away, calculating the rotations rather than tuning them.
What you are building 3 min
The Automatic Card Dealer: a driving base carrying a stack of cards, with a small rubber wheel pressing down on the top card. A Medium Motor turns that wheel.
Turn the wheel a little and it peels exactly one card off the stack and flicks it out. Turn it too far and two go. Turn it too little and none do.
By the end of the lesson the robot will drive a set distance to each player and deal one card each — and every number in the program will have been worked out rather than guessed.
In the real world 5 min
Where you have seen it
An ATM counts out banknotes one at a time, at speed, and gets it right millions of times a day. Inside is a rubber roller doing exactly what your card wheel does.
Why it is built that way
The trick is called a friction feeder. A rubber roller grips the top note and drags it forward; a second surface underneath grips the next note and holds it back. The two work against each other, so exactly one leaves.
And the roller does not run for a time — it turns a measured angle. The machine knows its roller’s diameter and it knows how long a note is, so it can work out precisely how far to turn. A note 15 cm long on a roller 3 cm across needs about 1.6 turns — and that is arithmetic, not tuning.
RM50 notes in Malaysia are 145 mm long and RM100 notes are 150 mm. The machine has a different number for each, because 5 mm matters when you are counting money.
What would go wrong without it
A cash machine tuned by trial and error would work on the day it was tuned. Change the note, change the roller, change the humidity — and every number has to be found again by hand. Arithmetic survives all three.
If you know the geometry, you can calculate the number instead of hunting for it.
Before you build 1 min
There is no printed manual for this model — but the video above is a real build video, not a demonstration. It is Lau Mo’s assembly walkthrough for the 45544 + 45560 sets, so you can build straight from it. Pause it often; a video cannot be paged at your own speed the way a manual can.
Watch first for how the card wheel presses on the stack and how the cards are held down. That contact is what the whole lesson depends on.
The programs below name ports rather than motor types.
The main concept — one rotation is a distance 6 min
Lesson 39 had you measure how many degrees made one centimetre of door, because a scissor lattice is complicated and nobody can calculate it. A wheel is not complicated. You can work this one out on paper.
The one formula in Level 2
Distance travelled in one rotation = π × wheel diameter
Roll a wheel through exactly one turn and it lays out its own rim along the floor. That length is the circumference, and π — about 3.14 — is the number that connects a circle’s width to the distance around it. It is the same for every circle that has ever existed.
| Wheel | Diameter | One rotation carries the robot |
|---|---|---|
| Standard EV3 Education wheel | 5.6 cm | 3.14 × 5.6 = 17.6 cm |
| Small EV3 wheel | 4.3 cm | 3.14 × 4.3 = 13.5 cm |
| Large balloon tyre | 8.2 cm | 3.14 × 8.2 = 25.7 cm |
Measure your own wheel — with a ruler, across the middle, over the rubber. The three above are common but yours is the one that matters.
Now turn a job into a program
You want the robot to drive 50 cm to the next player. Your wheel carries it 17.6 cm per rotation.
rotations = distance ÷ circumference = 50 ÷ 17.6 = 2.8
move [forward v] for (2.8) [rotations v] at (40) % speed :: movement
The rotations slot takes decimals. 2.8 is a perfectly legal entry, and rounding it to 3 costs you 3.5 cm every single move — which after four players is 14 cm, and the robot is at the wrong seat.
The card wheel is the same idea, smaller
Measure the card wheel’s diameter, and measure how far a card has to travel to clear the stack. Divide, then multiply by 360 for degrees. Nothing new — just a smaller circle.
What this cannot fix
Turning is not solved by arithmetic. You can calculate a turn from the wheelbase, and it will be wrong, because turning depends on grip and every floor grips differently — Lesson 37 made a whole lesson of it. This model has no Gyro, so its turns are the weak link. Expect the straight lines to be excellent and the corners to drift.
Rotations and degrees
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.
Blocks reference
| 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. |
Count it as it turns
The counters below tick up in step with the shaft, so you can watch a rotation being counted rather than take it on trust.
when program starts
A run clockwise for 2 rotations
the same movement, written in degrees
A run clockwise for 720 degrees
0.00motor rotations0°motor degrees0.00gear rotations
The program begins. Nothing has turned yet, so both counters read zero.
The two motor read-outs are the same measurement — 1 rotation is 360°. Use whichever makes the number easier to read.
Rotations or degrees?
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.
Gearing changes the answer
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.
Why it matters
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.
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.
Measure the wheel once, and every distance in your program becomes a sum instead of a search.
The mechanism changes the unitsFrom Lesson 39 — motor units and job units, and the ratio between them.Show meHide
Reading a motor's position
Every EV3 motor contains a sensor that counts how far it has actually turned. That means a motor is not only an output — you can ask it where it is, and the answer describes what really happened rather than what you asked for.
Blocks reference
| Block | What it does |
|---|---|
([A v] degrees counted :: sensors) | Reports how far this motor has actually turned since the count was last reset, in degrees. |
[A v] reset degrees counted :: motors | Sets the count back to zero, making right here the new reference point. |
([A v] speed :: sensors) | Reports how fast the motor is turning right now, as a percentage. A motor that is being driven but reads zero is a motor that is stuck. |
Asked for, versus achieved
Those two are not always the same. Here are two identical motors, running the same program, with only their mechanisms different.
when program starts
A reset degrees counted
A run clockwise for 2 rotations
write A degrees counted at line 1
the same program, on two identical motors
720degrees asked for0counted · free0counted · jammed
Free: asked 720, counted 720Jammed: asked 720, counted 0
Both motors are told to turn two rotations — 720 degrees. Both counters start at zero.
Nothing on the Brick announces a stall. The only evidence is that the counter stopped changing while the motor was still being told to turn.
Nothing on the Brick announces the jam. The motor is still being driven, the program is still sitting on the same block, and the only trace of the problem anywhere is a counter that has stopped climbing. Comparing what you asked for with what was counted is how a robot notices — which is the whole of stall detection.
Zero is wherever you say it is
When the Brick powers on, the count is simply whatever it happens to be. It is not a position on the machine — it becomes one only when you tie it to something physical.
That is what reset degrees counted is for, and it is not just a tidy-up block for the top of a program. Where you put it decides what zero means, so putting it part-way through — after the mechanism has been driven somewhere known — is the normal way to use it, not an abuse of it.
Find home first, then reset
A conveyor has no idea where it is. Give it a touch sensor at one end and it can find out: drive it until the sensor is pressed, and it is now at a place you can name. Only then reset the count, and that end becomes 0.
when program starts :: events hat [A v] start motor [counterclockwise v] :: motors [1 v] wait until [pressed v] :: sensors [A v] stop motor :: motors [A v] reset degrees counted :: motors
The order is the whole point. Reset before the sensor is pressed and you have zeroed a random spot; reset after it, and every later reading means “how far from home”. This is called homing, and it is why a printer rattles its head to one side when you switch it on.
Drive towards home gently. The mechanism is deliberately being run into its own end stop, so a slow speed saves the gears — and the touch sensor is what stops it, which means it stops in the same place every time regardless of where it started.
Putting zero somewhere more useful
Home is often a corner, and a corner is an awkward place to measure from. Say the conveyor carries a chute that dispenses bricks, and you would rather describe its position as left and right of the middle. Then home once, drive the known distance to the middle, and reset again there:
when program starts :: events hat [A v] start motor [counterclockwise v] :: motors [1 v] wait until [pressed v] :: sensors [A v] stop motor :: motors [A v] reset degrees counted :: motors [A v] run [clockwise v] for (900) [degrees v] :: motors [A v] reset degrees counted :: motors
Now the middle is 0. Moving right counts up, moving left counts down past zero into negative numbers — the count is perfectly happy to go negative — and “go back to the middle” becomes the simplest instruction in the program: drive until the count reaches 0.
Both resets earn their place. The first one turns a meaningless number into a distance from a real, repeatable place. The second one moves zero to where the maths is easiest. A reset in the middle of a program is only a mistake when the mechanism is somewhere you cannot name.
Turning turns into distance
Because the count is in degrees, and a wheel of known size travels a known distance per turn, the reading can be converted into how far the robot has actually driven. That is how a robot reports a distance in centimetres rather than in rotations — and it is why changing the wheels changes the answer.
Why it matters
This is how a printer knows the paper jammed, how a car window stops when it meets your hand, and how a robot arm knows it has reached its limit. A machine that can only give orders is fragile; one that can check what happened can recover.
Say this back before moving on: “Distance divided by circumference is rotations.”
What’s in this build 4 min
Look at your robot. There are three motors and two of them are doing the same job as each other. Which two?
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The body, and the weight that keeps the drive wheels gripping the table. |
| Drive motor ×2 | A matched pair. Their wheels are the ones whose diameter you are about to measure. |
| Card wheel motor | Turns the small rubber wheel that peels a card. Its own job, its own port, and its own circumference. |
| The card wheel and its rubber (not electronic) | Grip is everything. A shiny or dusty wheel slips, and a slipping wheel turns the right number of degrees and moves no card. |
| The card tray (not electronic) | Holds the stack under the wheel with steady pressure. Too much pressure deals two cards; too little deals none. |
Measure before you program
- Measure a drive wheel across the middle, over the rubber, in centimetres. Write it down.
- Multiply by 3.14. That is your circumference. Write that down too — it is the most useful number in the lesson.
- Check it. Mark the floor, run the robot exactly move [forward v] for (1) [rotations v], and measure how far it actually went. Within a centimetre? Good. Well short? Your wheels are slipping and no arithmetic will help.
- Measure the card wheel and find its degrees-per-card the same way.
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 drive wheel | B | The pair. Two motors, one job — driving. |
| Right drive wheel | C | The other half of the pair. |
| Card wheel | A | A separate job, well away from B and C. |
| Sensors | none | Everything today is calculated and commanded. Nothing checks — which is the lesson’s honest limitation. |
Check your own wiring now:
- Wheels in B and C, card wheel in A.
- Both drive wheels the same size. Two different wheels make your circumference meaningless and put a curve in every straight.
- Check both are firmly on their axles. A wheel that slips on its axle turns less than the motor did, and the encoder cannot tell.
- Cables clear of the table surface, and clear of where the cards land.
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. A cable trailing behind a driving robot is a drag that varies with distance — which is exactly the thing you are trying to measure today. It will make your careful arithmetic look wrong.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- Three motor tiles — A, B and C.
- Turn each drive wheel by hand and confirm left is B and right is C. Then turn the card wheel and confirm A.
- Do the one-rotation check from step 5 now, on the actual table you will be dealing on. Tape at the start, run one rotation, measure. That number is your real circumference, and it beats the calculated one whenever they disagree.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Make it move 10 min
Four players around a square table. Drive 50 cm, deal one, turn the corner, repeat.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement clear display :: display write [MENGEDAR] at line (1) :: display repeat (4) move [forward v] for (2.8) [rotations v] at (40) % speed :: movement wait (0.5) seconds [A v] run [clockwise v] for (240) [degrees v] at (30) % speed :: motors wait (0.5) seconds move [straight: 100] for (0.85) [rotations v] at (25) % speed :: movement end stop moving :: movement play sound [Communication / Goodbye v] until done :: sound
- 2.8 came from arithmetic. 50 ÷ 17.6. Change the distance to 70 cm and you can write the new number down without touching the robot.
- 240° came from measurement — Lesson 39’s method on a small wheel. Yours will differ; use yours.
- 0.85 came from tuning, and it is the weak number in this program. There is no Gyro on this model, so the corner is a guess that works on one surface.
- The half-second waits let the robot settle before the card goes. Deal while still rolling and the card lands anywhere.
What success looks like: the robot drives half a metre, pauses, flicks out exactly one card, turns the corner and does it again. Four cards, four seats, and it finishes roughly back where it started.
If it deals two cards, reduce the degrees or lighten the pressure on the stack. If it deals none, the wheel is slipping — clean it, or press a little harder. If the straights are perfect and the corners are not, that is not a bug. That is this model without a Gyro, and it is exactly what Lesson 37 fixed.
Change it and test 8 min
One change at a time, with a tape measure on the table. Today you can predict the answers before you run — so write your prediction down first, in centimetres, and see how close you get.
- Predict, then test. You want 30 cm. Work out the rotations, write down the number, run it, measure. How many centimetres out were you?
- Now 100 cm. If your 30 cm was 1 cm out, is the 100 cm about 3 cm out? Errors that grow in proportion mean your circumference is slightly wrong. Errors that stay the same size mean something else — probably the start and stop.
- Correct your circumference from the data. If 100 cm came out at 106, your real circumference is 17.6 × 1.06. Put the new number in and try again.
- Change the wheels for a different size, if your kit has them. Do not touch the program — measure how far it goes now. Then recalculate and watch it come right.
- Raise the speed from 40% to 90% and run 100 cm again. Does the distance change? A fast start slips, and slip is distance the encoder counted and the robot never travelled.
- Run the whole four-player deal on the table, then on the mat or the carpet. Note which numbers survive the change of surface and which do not.
Step 6 is the summary of the whole lesson. The calculated straight lines travel almost the same distance on any surface. The tuned corner does not. Arithmetic moved the straights out of the “tune it and hope” category; only a sensor can do that for the corners.
Calculate what you can, measure what you cannot calculate, and use a sensor for what you cannot measure in advance.