Challenge 1
Build your base and confirm all four ports in Port View. Both drive motors must count up when you push the robot forward by hand.
The mission 3 min
Build the robot you drew last lesson, then prove it works and measure what it does.
A robot that has been built is not a robot you can program. You do not yet know how far one rotation carries it, whether both motors are plugged in the way you think, or whether the Colour Sensor can see the mat at all. Today turns the model into a set of numbers.
The number the mat needs 4 min
In lesson 1 you planned a route in stations. To drive it, every leg has to become a number of rotations, and that conversion needs one value:
circumference = 3.14 x wheel diameter rotations needed = distance to travel / circumference
The standard EV3 Education wheel is 56 mm across, so one rotation is about 176 mm. The smaller wheel is 43 mm, giving about 135 mm. Measure your own with a ruler rather than trusting the number — tyres wear, and the figure printed on the side is the rim, not the rubber.
The technique — Port View before anything else 10 min
Port View is on the Brick, not in the app. Third tab along, and it shows what each port is actually reading right now. It is the fastest debugging tool in the whole course, and Level 4 teams should reach for it before they reach for the laptop.
- Turn the Brick on and open Port View.
- Push the robot forward by hand. Ports B and C must both count upwards. If one counts down, that motor is mounted mirrored — fix the build, not the program.
- Hold the robot over white mat, then over a black line. Port 3 must change by a large amount. If it barely moves, the sensor is too high.
- Write all four readings down. They are your baseline for the rest of the block.
“It counts down” is a build problem. You can paper over a mirrored motor with a negative speed in every block for the next forty-five lessons, or you can turn the motor round once today. Turn it round.
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.
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.
The Colour Sensor
The Colour Sensor looks down at a surface and can answer three quite different questions: what colour is this?, how bright is this? and how light is the room? Choosing the wrong one is the usual reason a line-following robot refuses to work.
front
sideBlocks reference
| Block | What it does |
|---|---|
([3 v] color :: sensors) | Reports which colour it sees, from a short list — red, blue, green, black, white and a few more. |
([3 v] reflected light intensity :: sensors) | Reports how bright the surface is, as a number from 0 (black) to 100 (white). |
<[3 v] is color [red v]? :: sensors> | Reports true or false for one particular colour. |
([3 v] ambient light intensity :: sensors) | Reports how much light is falling on the sensor, 0 to 100, with its own lamp switched off. |
Which colour, exactly?
The sensor does not describe a colour — it picks one from a list of eight, and that list is the whole of what it can ever say:
| Reports | Means |
|---|---|
| 0 | no colour — too far away, or too dark to call |
| 1 · 2 · 3 | black, blue, green |
| 4 · 5 · 6 | yellow, red, white |
| 7 | brown |
Anything you put under it is forced into one of those eight. There is no orange and no purple: an orange brick comes back as red or as yellow, and often as red one moment and yellow the next as the robot creeps along. Light blue and grey are the other classic pair to avoid — grey is neither black nor white, so it flips between them.
This is why colour mode is a good fit for a task you control and a bad fit for one you do not. Sorting the LEGO bricks that come in the set works, because they are made in exactly these colours. Reading a printed sheet, a coloured tile from another set, or anything pastel is asking the sensor to answer a question it does not have a word for.
Two practical points follow from how it decides. It shines its own lamp and looks at how much red, green and blue comes back, so it must be close — about half a centimetre, and no more than a centimetre. Lift it and the answer decays to 0. And because it takes those three readings before it can answer, colour mode is the slowest thing this sensor does; a robot driving quickly can pass right over a small patch without ever reporting it.
When a colour must be recognised reliably, test it. Drive the robot slowly over the real surface with color shown on the screen and watch what it actually says — including what it says at the edges between two colours, which is where the wrong answers live.
Colour, or brightness?
Both questions are asked of the same surface at the same moment. Watch the two answers travel across a strip of colours and then over the edge of a black line.
when program starts
forever
write 3 color at line 1
write 3 reflected light intensity at line 3
colour: 2 possible answers herereflected light: every value from 88 down to 8
The sensor sits a few millimetres above the surface, with its own lamp shining down.
Watch the two read-outs over the last third of the strip. One of them changes once. The other changes the whole way across.
Over the patches, both read-outs are useful. Over the edge of the line they part company: the colour name has only two answers to give and jumps between them, while the number slides smoothly from 88 down to 8. Every value in that slide tells you how far onto the line the sensor is — which is information the name simply does not carry.
- Use colour when the answer really is a name — sorting red bricks from blue ones, stopping on a green square.
- Use reflected light when the answer is a matter of degree — following the edge of a black line, where the useful readings are all the greys between black and white.
A line follower built on colour names only knows “black” or “not black”, so it can only lurch. Built on reflected light it can tell how far onto the line it has drifted, which is what makes smooth following possible.
The third mode: ambient light
The first two modes both switch the sensor’s own lamp on and measure what bounces back off the surface. Ambient light intensity does the opposite: the lamp goes off, and the sensor simply reports how much light is arriving from wherever — 0 in the dark, up to 100 in bright light.
| Mode | Own lamp | Measures | Points |
|---|---|---|---|
| colour | on | which of eight colours the surface is | at the surface, very close |
| reflected light | on | how much of its own light comes back | at the surface, very close |
| ambient light | off | how bright the surroundings are | wherever you want to measure |
That makes it the only one of the three that is not really about the floor. A number between 0 and 100 means very little on its own, so watch the same sensor sit through five different rooms — nothing underneath it changes at any point.
the sensor’s own lamp is off — it is measuring the room
Start in the dark — a hand over the lens, or the lights off. Almost no light reaches the sensor, and it reports 0.
Nothing under the sensor changed at any point in this run. Ambient light is the one mode that is not asking about the surface at all.
Those are the shape of the scale rather than exact figures, but the shape is the useful part: a lit room is nowhere near 100, and the top of the range is reserved for a light pointed straight at the sensor. Cover it with your hand and the number drops to near zero — which is the easiest way to check the sensor is doing what you think.
Point it at the ceiling and it tells you whether the room lights are on; point it forwards and a torch will spike the reading, which is a way of signalling to a robot without touching it.
Do not reach for it as a substitute for reflected light. Room light falling on a black line and on white paper is almost the same, so ambient mode can barely tell them apart — the reason reflected light works is precisely that the sensor brings its own light and measures how much of it survives.
It is also the mode most at the mercy of the room. A reading taken by a window in the morning will not match the same spot in the afternoon, so anything built on ambient light needs measuring on the day, in the place, with the lights as they will be.
Light and height matter
Even the two lamp-on modes are affected by room lighting — a reading taken by a sunny window differs from one taken in a corner. The sensor must also sit close to the surface and at a constant height, because lifting it changes the reading even though the surface has not changed.
Build it 15 min
Build from your own sketch. There is no manual, and that is the point. Work in this order — it is the order that avoids taking things apart again.
- The drive frame first. Two Large Motors, facing the same way, held rigidly relative to each other. Wobble here ruins everything later.
- Wheels and the third contact point. Check the robot sits flat and does not rock.
- The Brick, over the drive axle. Weight where the traction is.
- The Colour Sensor, facing down, 5–10 mm above the mat, at the distance forward you decided.
- The attachment mounting points — the two beams and two pins, even though nothing bolts on yet.
- Cables last, routed so nothing catches a wheel. B and C to the drive motors, 3 to the Colour Sensor.
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.
Model-specific note. Nothing on this robot is fixed by a manual, so the cable lengths are your choice. Use the shortest cable that reaches without stretching — a loop of spare cable hanging near a wheel will eventually be pulled in during a run.
The program — drive one rotation 10 min
when program starts :: events hat set movement motors to [B v] and [C v] :: movement clear display :: display write [ONE ROTATION] at line (1) :: display [B v] reset motor rotation count :: motors move [forward v] for (1) [rotations v] at (30) % speed :: movement stop moving :: movement write ([B v] motor rotation count) at line (3) :: motors play beep (60) for (0.2) seconds :: sound
Put a pencil mark on the mat at the front edge of the robot, run the program, and mark where it stops. Measure the gap with a ruler.
Before you measure, write down your prediction. You calculated 176 mm — write that down, then measure, then write the real number next to it.
Tune it — why the numbers disagree 10 min
Almost every team measures less than they calculated. Three reasons, and they are all real engineering:
- The tyre squashes. A loaded rubber tyre has a smaller rolling radius than a measured one. Heavier robot, bigger gap.
- The wheels slip at the start and when braking. More speed, more slip.
- The motor overshoots slightly past its target and coasts.
Now run the experiment properly:
- Drive 3 rotations at 30% speed. Measure. Divide by 3.
- Drive 3 rotations at 70% speed. Measure. Divide by 3.
- Compare the two “real circumference” numbers.
The faster run almost always travels less per rotation. Record your robot’s real distance per rotation at the speed you intend to compete at, and use that number from now on rather than the textbook one.
Run it — drive to a station 6 min
Measure the distance from HOME to the solar panel at F on your branch’s mat. Divide by your real distance per rotation. Program that many rotations and run it once.
You get one attempt. Trial and error would defeat the purpose — the point is to find out whether your measured number is good enough to predict a real leg. Land within one robot length and the number is trustworthy.
The journal 2 min
Entry 3 is the robot’s specification sheet:
- A photograph of the built robot, from the side and above.
- Wheel diameter, calculated circumference.
- Measured distance per rotation at 30% and at 70%.
- The four Port View baseline readings.
- The one-attempt drive to F: predicted rotations, and how far off you landed.
Keep this page reachableBlocks 2, 3 and 4 all send you back to these numbers.Show meHide
Distance per rotation is used again for encoder maths in Block 2, for gyro move-straight in Block 3, and for the PID comparison runs in Block 4. Teams that have to re-measure it mid-competition lose a round to it. Put it on the first page of the journal, not the third.