EV3 Robotics›Level 3 · Advanced›Lesson 17
Level 3 · Lesson 17 · EV3-L03-1760 minutes · Ages 9–16 · Model: Anti-aircraft gun
The Anti-aircraft gun: a barrel on two axes — a Large Motor swinging it left and right, a Medium Motor raising and lowering it — with an Ultrasonic Sensor measuring how far away the target is.
The sensor speaks centimetres. The motors speak degrees. Nothing in the machine converts between them, and until something does, a measured range cannot become an aimed barrel.
By the end of the lesson one measurement will drive two motors to the right angles, in one line of arithmetic each — and you will have the formula that does it for the rest of your robotics life.
Before computers, aiming a large gun was done by a mechanical fire-control computer — a box of gears, cams and shafts that took range and bearing in at one end and produced elevation and traverse at the other. The Royal Navy’s Admiralty Fire Control Table weighed several tonnes and did nothing but convert one set of numbers into another.
The shape of the cam was the formula. A gunner turned a handle until a pointer matched the measured range, and the gears did the rest. Change the ammunition and you changed the cam.
Because the thing you can measure and the thing you can command are almost never in the same units. A thermostat measures degrees and commands a valve position. A car’s pedal measures millimetres of travel and commands a fuel quantity. A volume knob measures rotation and commands loudness.
Every one of those is a mapping between two ranges, and every one has the same problem: the two ranges rarely start at zero and rarely have the same size.
A machine with no conversion can only work at one setting. It aims at one range, holds one temperature, plays at one volume — because the only relationship it has between input and output is a single number somebody typed.
Measuring is half the job. Turning the measurement into a command is the other half.
You know the input range: the ranges your sensor will actually see. You know the output range: the angles your barrel can actually reach. The formula puts one onto the other.
set [elevation v] to ((10) + (((range) - (20)) * ((50) - (10)) / ((90) - (20)))) :: variables
Written generally, and worth copying into a notebook:
| Piece | Means | Here |
|---|---|---|
in − inMin | How far along the input range you are. | range − 20 |
÷ (inMax − inMin) | Turn that into a fraction from 0 to 1. | ÷ 70 |
× (outMax − outMin) | Stretch the fraction to the output size. | × 40 |
+ outMin | Shift it to where the output starts. | + 10 |
The two subtractions are the part everyone forgets. Simply multiplying by a constant works only when both ranges start at zero. The moment your sensor starts at 20 cm or your barrel at 10 degrees, a bare multiply is wrong at every point except by accident.
A mapping is easy to get subtly wrong and easy to verify. Put the two extreme inputs in by hand:
10 + 0 × … = 10. The minimum. Correct.10 + 70 × 40 ÷ 70 = 50. The maximum. Correct.If both ends are right, the middle is right too, because the relationship is a straight line. Two arithmetic checks confirm the whole thing.
if <(elevation) > (50)> then set [elevation v] to (50) :: variables end if <(elevation) < (10)> then set [elevation v] to (10) :: variables end
The formula does not know your machine has ends. Feed it an out-of-range input and it produces an out-of-range output with complete confidence — and the mechanism, not the program, pays for it.
Sometimes bigger input should mean smaller output — a closer target needing a higher angle. Just swap the output ends: use outMin = 50, outMax = 10. The formula is unchanged and the maths handles the negative automatically.
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.
The Ultrasonic Sensor measures distance. It sends out a burst of sound too high for people to hear, listens for the echo, and works out how far away the surface is from how long the echo took — exactly how a bat finds a moth, and how a submarine uses sonar.
front
side| Block | What it does |
|---|---|
([4 v] distance in [cm v] :: sensors) | Reports how far away the nearest thing in front of the sensor is, as a number in centimetres. |
wait until <([4 v] distance in [cm v] :: sensors) < (15)> | Holds the program until something comes closer than 15 cm. |
This is the important step up from the Touch Sensor. Touch gives you true or false; the Ultrasonic gives you a number, and the deciding is left to you. Pick a threshold below and watch where the robot ends up.
The black line on the bar is the threshold; the blue fill is the reading. The robot stops the instant the fill crosses the line.
Three different robots, and only one number is different between them. That is what having a number rather than a yes-or-no buys you: the behaviour is tuned by editing one slot, not by rebuilding the program. It also means the sensor can never tell you it is “close” — close is a decision you make about a reading.
Car parking sensors, automatic doors at a shopping centre, and the sensor that stops a lift door closing on somebody all work this way. Reacting before contact is what makes a machine feel safe.
The Home/Retail EV3 set (31313) ships an Infrared Sensor and a Beacon in place of the Ultrasonic and Gyro sensors. The Infrared Sensor also measures distance, so the programs in this module work with it — but it reports a rough 0–100 proximity rather than real centimetres, and it is affected by sunlight and by dark surfaces in ways the Ultrasonic is not.
IR Sensor
BeaconSubtract the input start, scale, add the output start — then clamp. Four steps, and they never change.
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.
Say this back before moving on: “How far along am I, and how big is the other range?”
Move both axes by hand to their limits and write down the degrees at each end. Those four numbers are your output ranges, and the lesson cannot be done without them.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The mounting and the base. Its screen shows the measured range and both computed angles, which is how you check a mapping without a protractor. |
| Large Motor — traverse | Swings the whole gun left and right. Large because it turns the entire upper assembly. |
| Medium Motor — elevation | Raises and lowers the barrel. Medium because it moves only the barrel, and elevation wants fine control more than force. |
| Ultrasonic Sensor — range finder | Measures to the target. Mount it on the barrel so it looks where the gun looks — a sensor fixed to the base measures a different direction as soon as the gun traverses. |
| The elevation gearing (not electronic) | Has hard ends. Find them by hand now and note the safe travel — the program will command angles and the gearing will not argue. |
Write the four limits on a sticky note and keep it visible. Minimum and maximum elevation, minimum and maximum traverse, all in motor degrees from the centred position. Every mapping today uses two of them, and every clamp uses two of them.
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 |
|---|---|---|
| Traverse (Large) | A | The main axis, on the first motor port. |
| Elevation (Medium) | B | The second axis. |
| Range finder (Ultrasonic) | 4 | Ultrasonic stays on 4 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.
Either works — the gun stays put. If you use USB, keep the lead out of the traverse arc, which is wide.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
One mapping first, checked at both ends, and only then the second axis.
when program starts :: events hat
[B v] reset degrees counted :: motors
set [in min v] to (20) :: variables
set [in max v] to (90) :: variables
set [out min v] to (10) :: variables
set [out max v] to (50) :: variables
clear display :: display
forever
set [range v] to ([4 v] distance in cm) :: variables
set [elevation v] to ((out min) + (((range) - (in min)) * (((out max) - (out min)) / ((in max) - (in min))))) :: variables
if <(elevation) > (out max)> then
set [elevation v] to (out max) :: variables
end
if <(elevation) < (out min)> then
set [elevation v] to (out min) :: variables
end
write (range) at line (2) :: display
write (elevation) at line (4) :: display
endCheck the ends before you let it drive anything. Put the target at 20 cm — line 4 should read 10. Put it at 90 — line 4 should read 50. If either is wrong, the arithmetic is wrong, and no amount of motor tuning will fix it.
set [error v] to ((elevation) - ([B v] degrees counted)) :: variables
if <([abs v] of (error)) > (3)> then
[B v] start motor at ((error) * (2)) % speed :: motors
else
[B v] stop motor :: motors
end set [traverse v] to ((-60) + (((range) - (in min)) * (((60) - (-60)) / ((in max) - (in min))))) :: variables
set [t error v] to ((traverse) - ([A v] degrees counted)) :: variables
if <([abs v] of (t error)) > (3)> then
[A v] start motor at ((t error) * (2)) % speed :: motors
else
[A v] stop motor :: motors
endrange — a single source of truth, from Lesson 11.What success looks like: move the target closer and further, and both axes track it smoothly, stopping at their limits rather than pushing through them.
If the barrel jumps to a limit and stays, your input range is wrong — the sensor is reading outside 20–90, so the clamp is doing all the work. Print range and see what it actually reads.
One change at a time. Predict, then run, then look.
out min and out max so a closer target aims higher. Predict which way the barrel moves before you run it.elevation = range × 0.55. Check both ends. It is wrong at both, and now you know why the two subtractions matter.Check a mapping at both ends on paper before you let it drive a motor. Two sums beat an afternoon of adjusting.
Your gun computes the right angle and goes there as fast as the error allows. For a barrel, that is fine. For anything with balance, it is not.
A motorbike commanded to jump from 0 to 80% speed does not accelerate — it wheelies, or falls over. The same is true of anything tall, anything carrying a load, and anything with wheels that can slip.
Changing a value smoothly over time — a ramp — is the standard answer, and it is one loop with a step size. You have seen it before in Level 2’s power ramps; the next lesson makes it a tool you reach for deliberately.
Today: what value should I command? Next: how fast am I allowed to change it?
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.
Check your mapping at both ends, on paper. Before running anything, work out by hand what elevation your formula gives at your minimum range and at your maximum. Then put a target at each and check the screen agrees. If both ends are right, everything between them is too.
Reverse it. Make a closer target aim HIGHER by swapping the two output limits. The formula does not change at all — only the numbers. Be ready to explain why no extra "if" was needed.
Prove the clamps earn their place. Delete both clamps and put a target well outside your input range. Watch the commanded angle go past what the machine has, then stop it before the mechanism does. Put them back, then say in one sentence what the formula does not know about your machine.
Track a moving target on both axes. A partner walks a target slowly across the front of the gun, changing distance as they go. The barrel must follow on both traverse and elevation, smoothly, stopping at its limits rather than straining against them. Two rules: 1. Every range limit — input and output, both axes — is a named variable at the top. No number buried inside the arithmetic. 2. You must be able to state, for any target position, what angle the gun should be at, and check it against what the gun actually does. Then the honest test: move the target quickly. The gun will lag, and no amount of mapping fixes that — the mapping decides WHERE to go, and something else decides how fast. Say which lesson that something else came from, and try raising the gain to compensate. Note what you lose when you do.
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.
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.