EV3 Robotics›Level 3 · Advanced›Lesson 27
Level 3 · Lesson 27 · EV3-L03-2760 minutes · Ages 9–16 · Model: EV3 Repeating Crossbow Tank
The Crossbow Tank: a tracked vehicle with a repeating crossbow on top and an Ultrasonic Sensor looking straight ahead.
Every sensing model you have built has been passive. The gate waited for a passenger. The chicken waited for something in front of it. The flower waited for a hand. If nothing came, nothing happened.
By the end of the lesson your tank will sweep an area looking for a target, stop when it finds one, and only then commit — and you will know how fast it can sweep before it starts missing things.
A radar antenna turns because its beam is narrow. It cannot see everywhere at once, so it looks at one direction at a time and sweeps through them all — and the display you have seen in films, with a line going round and blips lighting up, is literally a picture of where it has just looked.
The rotation speed is a genuine engineering compromise. Turn slowly and you get a good look at each direction but a stale picture of the whole sky. Turn quickly and the picture is fresh but each direction gets less attention.
Anything with a narrow field of view has this problem. A lighthouse sweeps. A security camera pans. A bat sweeps its sonar by turning its head. A supermarket barcode scanner throws its laser through a fan of angles because it cannot know which way you are holding the packet.
A scanning machine trades “seeing everything badly” for “seeing one thing at a time well” — and the sweep rate is where that trade is set.
A sensor that only looks one way finds only what happens to be in front of it. Everything to the side might as well not exist — and the machine has no way to know the difference between “nothing there” and “not looking”.
If you can only look one way at a time, look everywhere in turn — and know how fast you may do it.
A search is a loop that moves and looks at the same time, and leaves the loop the moment it finds something. Two numbers define it: how far it sweeps, and how fast.
// sweep right until something is found or the limit is reached turn [right v] at (15) % speed :: movement wait until <<([4 v] distance in cm) < (50)> or <([abs v] of ([B v] degrees counted)) > (400)>> :: control stop moving :: movement
Every search needs a give-up condition. Without the second half of that or, a tank in an empty room turns until its battery dies. “I looked everywhere and found nothing” is a legitimate and necessary outcome.
This is the real question, and it is the same one Level 2’s minesweeper asked. The sensor is read between blocks, not continuously. Sweep too fast and the target passes through the beam between two readings — the machine looked, and looked again, and the target was there in the gap.
| Sweep speed | Finds things? | Cost |
|---|---|---|
| Very slow (5%) | Reliably. | Takes an age to cover the area. |
| Moderate (15–25%) | Usually. Start here. | Reasonable. |
| Fast (60%) | Misses things — and worse, misses them sometimes. | Covers ground quickly and cannot be trusted, which is the worst combination. |
An intermittent miss is far worse than a consistent one. A machine that never finds anything is obviously broken; one that finds things four times in five looks like it works, and will be trusted.
| Pattern | What it does | Use when |
|---|---|---|
| Sweep and return | Left to right, then back. Simple and complete. | The target could be anywhere in the arc. |
| Expanding sweep | Small arc first, widening. Finds nearby things fastest. | The target is probably close to where you are pointing. |
| Full rotation | All the way round, once. | No idea at all which way to look. |
Once something is found, the search must end. A machine that keeps sweeping while it aims is aiming at where the target was a moment ago — and after Lesson 22 you know that a committed action fired while still moving is wasted.
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
BeaconA 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 C| 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. |
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.
the same program on both robots
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.
Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.
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.
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
“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 — a half rotation past 1. Half a turn of the wheels is 8.75 cm, so halves matter.
35 ÷ 17.5 = 2. That is a number you can type straight into the block.
set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement move [forward v] for (2) [rotations v] :: movement
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.
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.
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.
| 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. |
Those two are not always the same. Here are two identical motors, running the same program, with only their mechanisms different.
the same program, on two identical motors
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.
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.
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.
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.
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.
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.
Sweep, with a limit and a give-up. Slowly enough to see. Then stop sweeping before you do anything about it.
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.
frontside| 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 SensorBeaconSay this back before moving on: “Look everywhere in turn — and stop when you find it.”
Turn the tank on the spot by hand and watch where the sensor points. How wide an arc does one full turn of the tracks cover?
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | The hull. Its screen reports what the sweep is doing — the angle searched and whether anything was found — which is how a search becomes debuggable. |
| Large Motor ×2 — the tracks | Turn the whole tank, which is how the sensor sweeps. Tracks slip on turning, so the encoder count and the real angle disagree — which matters for knowing how much has been searched. |
| Medium Motor — the crossbow | The committed action, from Lesson 22. It fires; nothing after that can be changed. |
| Ultrasonic Sensor — the eye | Narrow field of view, which is exactly why sweeping is necessary. Mounted facing dead ahead so the tank’s heading is also the sensor’s. |
| The tracks (not electronic) | Turn on the spot by scrubbing sideways, so they slip. Check both are tensioned the same — one loose track makes the tank sweep further one way than the other, and the search becomes lopsided without anybody noticing. |
The sensor must point where the crossbow points. If they are not aligned, the tank will find a target, stop, and fire past it — and the fault will look like bad aiming rather than bad mounting.
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 |
|---|---|---|
| Crossbow (Medium) | A | The committed action, on its own port. |
| Left track (Large) | B | The movement pair, which is also the sweep mechanism. |
| Right track (Large) | C | The other half. |
| The eye (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.
Bluetooth — this one turns on the spot repeatedly. A USB lead wraps round a rotating vehicle within about two sweeps, and the drag will make one direction slower than the other.
Stuck? The long version, with a photograph of every screen, is in the Brick & Bluetooth guide.
Search, then commit. Build the search first and make it report what it found before you let it fire anything.
define search (sweep speed) set [found v] to (0) :: variables [B v] reset degrees counted :: motors turn [right v] at (sweep speed) % speed :: movement wait until <<([4 v] distance in cm) < (50)> or <([abs v] of ([B v] degrees counted)) > (400)>> :: control stop moving :: movement if <([4 v] distance in cm) < (50)> then set [found v] to (1) :: variables end when program starts :: events hat set movement motors to [B v] and [C v] :: movement clear display :: display search (15) :: custom if <(found) = (1)> then write [TARGET FOUND] at line (1) :: display write ([4 v] distance in cm) at line (3) :: display set status light to [red v] :: display else write [NOTHING THERE] at line (1) :: display set status light to [green v] :: display end
when program starts :: events hat
set movement motors to [B v] and [C v] :: movement
clear display :: display
forever
search (15) :: custom
if <(found) = (1)> then
// the search has STOPPED. now, and only now, commit.
write [ENGAGING] at line (1) :: display
wait (0.5) seconds :: control
[A v] run [clockwise v] for (360) [degrees v] at (100) % speed :: motors
wait (1) seconds :: control
else
// nothing in that arc — sweep back the other way
write [SEARCHING] at line (1) :: display
turn [left v] for (2) [rotations v] at (25) % speed :: movement
end
endsearch. You will be changing it repeatedly in step 10, and an input beats editing the definition each time.stop moving comes before anything else happens. Searching and acting are separate phases and must not overlap.What success looks like: the tank sweeps, stops crisply when the target enters its view, pauses, fires, and resumes searching — and in an empty room it sweeps one way, gives up, and sweeps back.
If it fires at nothing, it found a wall — narrow the detection range from 50 cm to something inside your room. If it sweeps past the target, it is sweeping too fast, which is step 10’s first experiment.
One change at a time. Predict, then run, then look. Run each setting five times — a search that works once has told you nothing.
stop moving. Watch where the bolts go, then put it back — Lessons 22 and 27 meeting.A search that finds things most of the time is worse than one that never does, because it will be believed.
Your tank turns on the spot to look around. It moves by driving two tracks, and that is the only way anything in this course has moved.
The next model has no wheels and no tracks. A snake moves by passing a wave along its body — each part doing the same thing as the part in front, but a moment later.
The same motion, delayed, is a completely different idea from two motions coordinated. One signal and an offset produces a travelling wave, and it is how snakes, fish, caterpillars and millipedes all get about.
Today the machine looked around. Next it moves by doing the same thing twice, slightly late.
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.
Find your fastest reliable sweep. Run the search five times at 15% and count the finds. Then five at 60%. If the fast one finds it three times in five, you have built the worst kind of machine — one that mostly works. Write down the fastest speed that found it five times out of five.
Give it something to give up on. Run your search in an empty room. It must sweep, reach its limit, report that it found nothing, and stop. Then remove the limit and watch it turn for ever. Say in one sentence why "I looked and found nothing" has to be a real outcome.
Fire while still sweeping. Move the crossbow block to before the "stop moving" and watch where the bolts go. Put it back, then explain how this connects to Lesson 22 — what exactly is being decided before the point of no return?
Sweep a room and report what is in it. The tank must search a full rotation, and instead of firing, record every direction in which it found something — and how far away it was. At the end it reports how many objects it found and reads back each one: the angle and the distance. Three rules: 1. The sweep speed is a named value you have tested, and you can state how you chose it. 2. Two objects close together must be reported as two, not one. Work out what makes them separate — this is the hard part, and it is a real problem for real radars. 3. The same room, searched twice, must give the same answer. If it does not, your sweep is too fast, and you now have proof rather than opinion. Then run it in a room somebody else set up, and check its report against what is actually there.
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.