EV3 Robotics›Level 2 · Intermediate›Lesson 34
Level 2 · Lesson 34 · EV3-L02-3460 minutes · Ages 9–16 · Model: EV3 Electronic Balance
The Balance: a pan on a beam that deflects when something is put on it, with a sensor measuring how far it has tilted.
The sensor reports degrees. Nobody wants degrees. They want grams — and no sensor in the kit measures grams, because grams depend on this beam, this spring and this arrangement.
By the end of the lesson your balance will report a real weight, in real units, after being shown two things whose weight is known — and it will tell you when it does not trust its own answer.
A beam balance does not measure weight at all — it compares. Put the thing on one side and known masses on the other until it levels, and you know the weight because you know the masses. There is no scale to trust, only the reference weights.
An electronic scale has no such luxury. Inside is a strain gauge producing a tiny voltage that means nothing on its own — and the manufacturer turns it into grams by putting known weights on it in the factory and recording what it reads.
Because a sensor measures its own quantity, not yours. A strain gauge measures stretch; a thermocouple measures voltage; your Gyro measures degrees. Every one of them needs somebody to establish what its numbers correspond to in the world.
Shops in Britain have their scales checked and sealed by Trading Standards precisely because the conversion can drift — and a scale that is wrong by two per cent is invisible to everybody until it is tested against a known mass.
A machine reporting raw sensor units gives a number that only means something to the person who built it. Rebuild the beam and every reading changes. Nobody can compare two machines, and nobody can check either one is right.
A sensor gives you a number. Only a known reference turns it into a measurement.
Lesson 12 took two samples — bright and dark — and found the midpoint between them. Today you take two samples and keep the whole line, which converts any reading into a real unit rather than just splitting them in two.
set [zero reading v] to (-14) :: variables set [known reading v] to (46) :: variables set [known grams v] to (100) :: variables set [per unit v] to ((known grams) / ((known reading) - (zero reading))) :: variables set [grams v] to (((reading) - (zero reading)) * (per unit)) :: variables
per unit — how many grams one unit of sensor reading is worth. Everything afterwards is one multiplication.This is Lesson 17’s range mapping, with the output range supplied by reality rather than by you. There you decided both ends; here the world decides one of them and a known weight decides the other. Same arithmetic, and now the answer has a unit.
Put a bowl on a kitchen scale and press Tare: the display returns to zero and now weighs only what you add. That is one line — take the current reading and make it the new zero:
// TARE: whatever is on the pan now counts as nothing set [zero reading v] to (reading) :: variables
Two points define a straight line, and using them assumes the relationship is a straight line. Springs are nearly linear over a small range, and noticeably not near their limits.
So test it with a third weight you did not calibrate on. If a known 50 g reads 50, the line holds. If it reads 43, the beam is not behaving linearly and two points are not enough for that range.
| Third weight reads | Means | Do |
|---|---|---|
| Close to its true mass | The line holds across your range. | Nothing. It works. |
| Off by a similar amount every time | A zero error. | Re-tare with an empty pan. |
| Off more at heavy weights than light | Not linear. | Use a smaller range, or calibrate at more points and pick the nearest pair. |
A balance that reports 37.4213 g is claiming a precision it does not have. If repeated weighings of the same object vary by two grams, report whole grams — the extra digits are noise dressed as knowledge.
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from above
front| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
no reset
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
stop 4° early
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
A sensor that reports a number cannot be used to make a decision on its own — 23 is neither true nor false. An operator turns that number into an answer by comparing it with something.
| Block | What it does |
|---|---|
<(x) > (50)> | True when the left value is bigger than the right. |
<(x) < (50)> | True when it is smaller. |
<<> and <>> | True only when both conditions are true. |
<<> or <>> | True when at least one of them is. |
Forget the symbols for a moment. A comparison is a question about position on a number line: is x to the left of the other number, or to the right? Left is smaller, right is bigger — and that is the whole of it.
Drag the orange x and the black marker, and change the comparison. The green stretch is every position of x that would make the answer true — so you can see where the answer flips before you get there. Turn not on and watch the green jump to the other side.
Drag either marker, or use the arrow keys.
is x to the LEFT of it?
The lab above asks one question at a time: is this x true? A robot never has just one x, though — a sensor reading slides up and down all the time, so what really matters is which stretch of the line makes the condition true. This one draws the whole answer at once.
Drag the circle to move the number you are comparing against, and change the comparison. Everything shaded green is a value of x that would make it true.
Drag the circle, or use the arrow keys. It moves in steps of 0.2.
Every number to the left of 0.2 — but not 0.2 itself, so the circle is hollow.
Watch the circle, because it carries the part everyone gets wrong:
Now turn not on with x > 2 selected and watch two things happen together. The shading jumps to the other side, and the circle fills in — because “not greater than 2” means 2 or less, and 2 has to be part of it. That pairing is the whole reason a hollow circle is worth drawing.
Why a robot cares. Two conditions that look almost identical — light < 30 and not (light > 30) — differ by exactly one value, the reading of precisely 30. A robot sitting right on its threshold behaves differently under the two, and that is the sort of bug that only shows up occasionally and looks like a broken sensor.
These three join answers together rather than numbers. The trap is that English is looser than a program: “stop if it is close and the bumper is pressed” sounds like it covers both situations, when it covers neither on its own.
Flip the two conditions and watch the table. There are only four possible situations in total, and and and or differ on exactly two of them.
| close | bumper | and | or |
|---|---|---|---|
| true | true | true | true |
| true | false | false | true |
| false | true | false | true |
| false | false | false | false |
and is fussy: it wants both. Three of the four rows are false.
Two sensors are running below: an Ultrasonic reporting a number, and a Touch Sensor reporting true or false. Watch the comparison turn the number into an answer, and watch and and or disagree.
and was true in one row out of four. or was true in three. That is the whole difference, and it is why one of them makes a robot look broken.
The comparison is doing one job: it takes a reading that is neither true nor false and, by holding it against a number you chose, produces something a decision can use. The moment the blue fill crosses the black marker is the moment the answer changes.
The number you compare against is a design decision, not a fact. “Close” for a parking sensor might be 15 cm; for a robot arm it might be 3. Pick it by measuring what the sensor actually reads in the situation you care about, then leave a margin.
and narrows: both must hold, so the robot acts less often but more certainly — stop only if something is close and the bumper is pressed. or widens: either will do, so the robot acts more readily — stop if something is close or the bumper is pressed.
In the four situations above, and was true in one of them and or in three. That is the practical difference: swapping one for the other does not adjust a robot slightly, it changes how often it reacts at all.
Long before there were computers, people had exactly this problem. A shepherd counting sheep through a gate, a trader counting sacks of grain, a builder counting days — none of them can hold the number in their head while they get on with the work. So they scratched a mark on a wall, cut a notch in a stick, or wrote a number on a piece of paper. The number lived outside the person, in a place they had agreed on, and they could go back to it, read it, and change it.
Better still, once the number is written down somebody else can use it. Watch these two: one of them counts and writes, the other never sees a single animal and simply reads the wall.
Notice what never happens: Ben never asks Abby. He does not need to — the number is not in her head, it is on the wall, and the wall is there for anyone who needs it.
Neither Abby nor Ben is holding the number — the wall is. And notice what never happens: Ben does not ask Abby. He does not need to, because the count is not in her head. It is in a place they both agreed on, which is what makes it useful to more than one of them.
That is all a variable is. The robot cannot hold a number in its head either, so you give it a wall of its own, write a name at the top so everyone knows which wall is which — score, count, degree_turn — and the program can read what is on it and write something new. One part of the program writes; another part reads. Exactly Abby and Ben.
Say we are counting rotations of a motor. Before we start we write 0 on the paper. Every time the motor completes a turn we cross out what is there and write one more: 0 becomes 1, then 2, then 3. That is change — it has to read the old number to work out the new one.
set is the other thing you can do, and it is completely different: rub the whole paper out and write the number you want. It does not care what was there. Press the buttons and watch what happens to the crossings-out.
The paper starts blank, so we write 0 on it. That is what a variable is: a place to keep a number while the robot works.
| Block | What it does |
|---|---|
set [count v] to (0) | Puts a value in, replacing whatever was there. |
change [count v] by (1) | Adds to what is already there. |
(count) | Reports the current value, for use in a comparison or on the display. |
set replaces; change adds. Counting things needs change. Starting a count needs set. Both programs below have both blocks — the only difference is whether the set block is inside the loop or above it.
set before the loop
set inside it
Both programs contain both blocks. Only the position of set [count] to 0 is different.
The count on the right is not broken; it is being told to start again on every pass. Each time round the loop it is wiped back to zero and then changed by one, so the honest answer is always 1 — while the motor cheerfully turns four times. A counter stuck at 1 almost always means a set block that has slipped inside the loop.
EV3 Classroom tells you what a block does by its shape, and once you have noticed that, a whole set of questions answers itself:
So when a slot is oval, any oval fits it — and it does not matter in the least where that number came from. You can take the motor’s own A degrees counted and keep it in a variable you named degree_turn, then compare that with a number later. Pick an oval below and watch the same one drop into all three kinds of slot.
pick an oval
the same oval fits all three
Every one of those slots is oval-shaped, and A degrees counted is an oval — so it drops in. Nothing about where the number came from matters.
This is what makes a variable more than a counter. A sensor reading is true only at the instant you read it; copying it into a variable freezes it, so the robot can compare where it is now against where it was when something happened:
when program starts :: events hat [A v] reset degrees counted :: motors set [degree_turn v] to ([A v] degrees counted :: sensors) start moving [right: 30] :: movement wait until <(([A v] degrees counted :: sensors) - (degree_turn)) > (400)> stop moving :: movement
Read the condition aloud: how far the motor has gone now, minus where it was when we started, is more than 400. Both are ovals, so both can go into a subtraction, and the subtraction is an oval too — which is why it can go into a comparison. Ovals nest inside ovals as deep as you need.
A variable keeps its value after the program ends. Run the program again without setting it back and the second run begins where the first left off — the count starts at 14, the robot thinks it has already done the job. Every variable a program changes must be set to its starting value at the top.
A variable is the difference between a machine that repeats a fixed routine and one that responds to how things have gone — counting parts, tracking a score, remembering where it started.
Two known points make a scale. A third, unused one tells you whether to believe it.
The Gyro Sensor measures how far the robot has turned, in degrees. Wheels slip and floors vary, so counting wheel rotations is a poor way to turn accurately — the gyro measures the turn itself rather than inferring it.
from abovefront| Block | What it does |
|---|---|
([2 v] angle :: sensors) | Reports how far the robot has turned since the angle was last reset. |
[2 v] reset angle :: sensors | Sets the current heading as zero. |
The angle is measured from wherever it was last zeroed — not from where this turn started. Here are two robots given the same instruction, one with a reset block and one without.
reset first
no reset
Both programs are correct about what they asked for. Only the left one asked the question from a known starting point.
Both programs did exactly what they said. Both gyros stopped at 90. But the robot on the right had 34 degrees already on the clock, so it only turned 55 — and nothing about the program looks wrong. Watch the first step too: neither robot is moving and the reading is still climbing. That is drift, and it is why the reset belongs immediately before the turn.
Reset with the robot completely still, as late as you can.
when program starts :: events hat [2 v] reset angle :: sensors start moving [straight: 0] :: movement wait until <([2 v] angle :: sensors) > (90)> stop moving :: movement
That program is the obvious one to write, and it will not give you a 90 degree turn. The next section is why.
Asking to stop at 90 does not stop the robot at 90. Between the gyro reaching 90 and the wheels actually standing still there is a delay — the sensor has to be read, the next block has to run, and the motors have to physically brake. The robot is still turning through all of it, so it ends up past where you asked.
The fix is to ask for less than you want. Aim for a 90 degree turn by waiting for 86: the robot coasts the last few degrees on its own and settles at roughly 89 to 91.
ask for exactly 90
stop 4° early
The tolerance has to match the speed. At 50°/s the number that lands this turn on 90° is 86 — let it loop, and watch that number change when the speed does.
The size of that gap is not a fixed property of the robot — it is the delay multiplied by how fast you are turning. The delay stays about the same whatever you do, so a turn at double the speed carries you about double the distance past the mark.
| Turn speed | Carried past the stop | Wait for | Ends up at |
|---|---|---|---|
| slow | about 4° | 86 | about 90° |
| fast | about 10° | 80 | about 90° |
So the tolerance and the speed have to be chosen together. Turn faster and you must give up more; if you speed a turn up and forget to lower the number, the robot starts overshooting every corner and the program that worked last week no longer does.
when program starts :: events hat [2 v] reset angle :: sensors start moving [right: 30] :: movement wait until <([2 v] angle :: sensors) > (86)> stop moving :: movement
Find your own number rather than copying this one — it depends on your robot’s weight, its wheels and the speed you turn at. Run the turn, measure where it actually stops, and move the number by however far it missed. Two or three tries is usually enough.
The other half of the answer is to slow down. A slower turn overshoots less, so it needs less guessing and repeats more reliably — which is why a turn worth getting right is rarely worth rushing.
A gyro slowly loses its zero even when nothing is moving. Leave a robot sitting still for a minute and the angle may have wandered several degrees all by itself. That is drift, and it is a property of the hardware, not a bug in your program.
Two habits deal with it: reset the angle as late as possible before a turn, and keep the robot dead still while the reset happens. Resetting while the robot is rolling bakes the error in permanently.
Aircraft, ships and phones all use gyros to know their orientation — it is how a phone knows you have turned it sideways. A robot that can turn exactly 90 degrees on any surface is far more reliable than one that guesses with wheel rotations.
Say this back before moving on: “What is zero, and what does one unit weigh?”
Press the pan down gently and let go. Does it return to exactly where it started? If not, no calibration will save it — the zero moves on its own.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The base and the display. It shows grams, and — importantly — how confident it is entitled to be about them. |
| Gyro Sensor — the tilt | Measures how far the beam has deflected. It reports degrees, and degrees are not grams. Turning one into the other is the entire lesson. |
| Large Motor — the beam | Holds and returns the beam. Its own encoder is a second, independent measure of deflection — useful for cross-checking, which is Lesson 13. |
| Touch Sensor — tare / calibrate | The user’s way of saying “this is zero” and “this is the known weight” — the teaching idea from Lesson 26, applied to measurement. |
| The beam and spring (not electronic) | Where accuracy is won or lost. It must return to the same place every time and deflect smoothly. Friction in the pivot is the enemy: it makes the reading depend on which direction the beam last moved. |
Set the balance down and leave it alone while it works. The Gyro zeroes itself when the program starts and drifts if the whole model is moved — so a balance that is picked up mid-weighing is reporting a number that includes your hands.
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 |
|---|---|---|
| Beam (Large) | A | The only motor. |
| Tilt (Gyro) | 2 | Gyro stays on 2 across the course. |
| Tare (Touch) | 1 | Touch stays on 1 across the course. |
Check your own build now:
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.
USB, and do not lean on the table. A balance this sensitive responds to the table being knocked, so keep the cable slack and everything still while a reading is being taken.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Calibrate first, weigh second. The second half never mentions a number you typed.
when program starts :: events hat
[2 v] reset gyro sensor :: sensors
set [known grams v] to (71) :: variables
clear display :: display
// ---- 1. empty pan ----
write [EMPTY PAN, PRESS] at line (1) :: display
wait until <[1 v] is pressed? :: sensors>
set [total v] to (0) :: variables
repeat (10)
set [total v] to ((total) + ([2 v] angle)) :: variables
end
set [zero reading v] to ((total) / (10)) :: variables
play sound [Mechanical / Blip 1 v] :: sound
wait until <not <[1 v] is pressed? :: sensors>> :: control
// ---- 2. the known weight ----
write [ADD KNOWN, PRESS] at line (1) :: display
wait until <[1 v] is pressed? :: sensors>
set [total v] to (0) :: variables
repeat (10)
set [total v] to ((total) + ([2 v] angle)) :: variables
end
set [known reading v] to ((total) / (10)) :: variables
play sound [Mechanical / Blip 1 v] :: sound
wait until <not <[1 v] is pressed? :: sensors>> :: control
// ---- 3. the scale ----
set [per unit v] to ((known grams) / ((known reading) - (zero reading))) :: variables
write [READY] at line (1) :: display
// ---- 4. weighing ----
forever
set [total v] to (0) :: variables
repeat (10)
set [total v] to ((total) + ([2 v] angle)) :: variables
end
set [reading v] to ((total) / (10)) :: variables
set [grams v] to (((reading) - (zero reading)) * (per unit)) :: variables
write ([round v] of (grams)) at line (3) :: display
write (reading) at line (6) :: display
if <[1 v] is pressed? :: sensors> then
set [zero reading v] to (reading) :: variables
write [TARED] at line (1) :: display
play sound [Mechanical / Blip 4 v] :: sound
wait until <not <[1 v] is pressed? :: sensors>> :: control
write [READY] at line (1) :: display
end
endper unit is computed once, from the two references. Nothing after that mentions the known weight — the scale is established and the machine just uses it.What success looks like: calibrate with an empty pan and a known 71 g, then put a different known object on and read a sensible number of grams — one you can check against a real scale.
If everything reads zero, your two calibration readings were the same, so per unit divided by nothing — use a heavier reference. If the sign is inverted, the beam tilts the other way; swap the two terms in the subtraction.
One change at a time. Predict, then run, then look.
Calibrate on two, check on a third. And never show more digits than you can repeat.
Everything in this course has been built to be predictable. The same input gives the same output, and when it does not, you have found a bug.
The last model of this set wants the opposite. A ball conveyor that always delivered the same colour in the same order would be a poor game — it needs to be unpredictable on purpose.
Deliberate randomness is easy to add and surprisingly easy to get wrong — random is not the same as fair, an unlucky run is not a broken machine, and there are parts of any machine that must never be random. That is the last lesson of this twelve.
Today the machine told the truth about a number. Next it learns when not to be predictable.
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.
Work through the challenges in order — each is harder than the last. The mission comes after all three, and it is meant to make you plan before you build.
Test with a third weight. Calibrate on an empty pan and one known mass. Then weigh a different object whose true mass you know and did NOT calibrate on. Report its real mass and what your balance said. That difference is your accuracy, and it is the only honest measure of it.
Tare with a container. Put a small pot on the pan, press tare, then add contents. It should report only the contents. One line of code. Say why tare does not require recalibrating.
Find where the line breaks. Weigh something much heavier than your calibration weight and check the error. Then something much lighter. Springs go non-linear near their limits. Report the range over which your balance is trustworthy, and say how you found the edges.
Build a balance somebody could actually weigh with. It must report grams, be usable by a stranger, and be honest about its own accuracy. Requirements: - a calibration routine a stranger can follow from the screen alone - tare, working, on a button - the result rounded to a number of digits you can justify — weigh the same object five times and let the spread decide - a stated working range, tested at both ends with known masses - it refuses to calibrate if the two readings are too close together, and says so Then the real test: weigh five household objects and check each against a kitchen scale. Report your errors as a table. Finally, answer this in two sentences: your balance reports grams, but nothing in the kit measures grams. Where did the grams actually come from?