Challenge 1
Make the animal swim out and come back to where it started. It must finish on the same spot it began, facing the same way, and you may not touch it. Mark the starting position before you run it so there is no arguing about the result.
What you are building 3 min
The Plesiosaurus: a long-necked sea reptile with a broad body and four wide paddle-limbs, one at each corner. It rolls forward on hidden wheels, and as it goes the four paddles sweep through the air as though it were swimming.
There is one motor in the whole animal, and it only ever turns one way.
By the end of the lesson you will be able to say exactly where the back-and-forth of the paddles comes from — because it is not in your program.
In the real world 5 min
Where you have seen it
Plesiosaurs lived in the sea at the same time as the dinosaurs walked on land. They were not dinosaurs themselves. They breathed air, and they swam with four enormous flippers — which is unusual. Almost every big swimmer alive today, from tuna to dolphins, drives itself with its tail.
Why it is built that way
A flipper does not push water backwards like an oar. It works like an underwater wing: the animal sweeps it down and forward, and the shape of the flipper turns that sweep into a push. Four of them, beating in a steady rhythm, gave a very large animal a very steady cruise.
Notice what the animal actually does. Its muscles pull the flipper through a stroke — out and back, out and back — over and over. No muscle spins. Nothing in an animal goes round and round.
What would go wrong without it
A steady beat is what makes it work. If the four flippers moved at random the pushes would fight one another and the animal would wallow. Real swimmers keep a rhythm, and they keep the same rhythm for hours, because it costs less energy than starting and stopping.
Animals stroke. Motors spin. Somewhere between the two, something has to do the converting.
The main concept — the mechanism does the reversing 6 min
A linkage can turn a motor that only ever goes one way into a movement that goes back and forth.
Cast your mind back to the Wipers in Lesson 19. To sweep a wiper across a windscreen and back, you wrote two motor blocks: one clockwise, one counterclockwise. The program did the reversing.
The Plesiosaurus reaches the same result from the other direction. The motor turns the wheels one way, forever. A rod from the wheel axle to the flipper means that as the wheel goes round, the far end of the rod is pushed forward, then back, then forward again — once per turn of the wheel. The build does the reversing.
This is one of the most useful mechanisms ever invented, and it is everywhere. The pistons in a car engine, the needle on a sewing machine, the pump on an oil field, the pedals on your bicycle turning your up-and-down legs into a spin — all the same idea, some of them running it backwards.
| Job | Lesson 19 — the Wipers | Lesson 45 — the Plesiosaurus |
|---|---|---|
| What reverses the movement | The program | The linkage |
| Motor direction | Changes every sweep | Never changes |
| Blocks needed for ten strokes | A loop with two motor blocks in it | One motor block. The mechanism repeats itself for free. |
| How you change the rhythm | Edit the numbers in the program | Change the speed — but the shape of the stroke is fixed by the build. |
When you need something to repeat back and forth, you can write it or you can build it. Building it is usually fewer blocks and always more reliable.
The Medium Motor and motor speedThe full reference for the motor and the speed setting. Open it if either is not clear yet.Show meHide
The Medium Motor
The Medium Motor is the smaller of the two EV3 motors. It is quick and light rather than strong, which makes it the right choice for anything that has to move a part of the robot rather than the whole robot — a gate arm, a pair of jaws, a winch, a pointer.
side
from aboveBlocks reference
| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Turns the motor a measured amount, then stops. One rotation is one full turn of the motor shaft. |
[A v] run [clockwise v] for (90) [degrees v] :: motors | The same idea, but in degrees — useful when a quarter or a half turn is what the mechanism needs. 360 degrees is one rotation. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Turns the motor for a length of time and then stops, whatever the shaft managed to do in it. The one measurement that always finishes. |
[A v] set speed to (50) % :: motors | Sets how fast the motor will run from now on. It does not start the motor by itself. |
[A v] start motor [clockwise v] :: motors | Starts the motor turning and moves straight on to the next block. It keeps going until something stops it. |
[A v] stop motor :: motors | Stops the motor. |
Measured, or not measured
These two look similar and behave completely differently, and almost every early EV3 bug comes from picking the wrong one. Watch both run the same job, over and over.
when program starts
A run clockwise for 1 rotations
versus
A start motor clockwise
wait 1 seconds
A stop motor
0°measured0°timed1run
Measured: on the mark, againTimed: 48° off the mark
Both programs begin. Both shafts are on the black target mark.
Let it loop a few times. The left dial keeps landing on the same mark; the right one leaves a new mark almost every run — that scatter is what “not repeatable” means.
The black mark is where the shaft should finish. The measured motor hits it every single run, because the program waits at that block until the motor has turned exactly that far. The timed motor is only running for a second — and a second covers a different amount depending on the battery, the friction and whatever the mechanism is carrying. Each orange dash is a run that finished somewhere it was not asked to.
- run for () rotations is measured. Run it twice and you get the same movement twice.
- start motor is not measured. It hands the motor its instruction and moves straight on, so how far the motor gets depends on how long it happens to be left running.
If a mechanism has to end up in a particular place — a gate that must finish upright, a jaw that must close fully — use the measured block.
The third one: run for () seconds
The dropdown at the end of the run block has a third setting, and it is the one that saves lifting mechanisms. for () seconds switches the block off a distance and onto a duration: it drives the motor for that long and then stops, whatever the shaft managed to do in the time.
That sounds strictly worse than a measured turn, and for most jobs it is. It matters because of what the measured block actually waits for. run for (90) degrees does not finish when 90 degrees’ worth of time has passed. It finishes when the shaft has turned 90 degrees — and if the mechanism runs out of travel first, the shaft never will.
Stalling, and the program that never moves on
Every arm, jaw and lift has a physical limit: a point where the mechanism reaches the top of its travel, or something in the build gets in the way. Push a motor into that limit and it stalls — the shaft stops turning and the motor sits there straining. The motor is fine and the program is spelled correctly. But the encoder has stopped counting, so a measured block that was told a bigger number is still waiting, and it will wait until the Brick is switched off.
Nothing after that block ever runs. Not the next motor block, not the sound, not the display, not the rest of the program. That is the whole failure, and it looks like a crash even though nothing has crashed.
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [clockwise v] for (90) [degrees v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
0°degrees counted90°what the block asked for0.0swaiting at that block
60° reached, 90° asked — waits for everrest of the program never runs
Same arm, same end stop at 60°. One number is different: this program asks for 90.
Watch the Brick screen, not the arm. HOME SET is the block after the motor block, so a blank screen means the program never got past it.
Compare the first two. The only difference between them is 45 and 90, the mechanism is identical, and one of them is a working program while the other locks up on the third block. Nothing in the listing distinguishes them — the end stop is a fact about the build, and the program has never heard of it.
This is the mistake almost every student makes the first time a Medium Motor lifts something. A lifting arm has a lowest position and a highest one; ask it to turn past either and the program hangs. It is worse than an ordinary bug, because the robot looks alive — the motor is still being driven, still buzzing, still hot — and the next block never comes.
Finding a home position by stalling on purpose
The fix turns the problem into the technique. You often do not know how many degrees it is to the top of an arm’s travel — it depends on the build, and it changes the moment somebody rebuilds it. So do not measure it. Drive the arm gently into its own end stop for a couple of seconds, and then declare that position to be zero:
when program starts :: events hat [A v] set speed to (30) % :: motors [A v] run [counterclockwise v] for (2) [seconds v] :: motors [A v] reset degrees counted :: motors write [HOME SET] at line (1) :: display
Three things make that work, and all three are deliberate:
- Slowly. 20–30% is enough to reach the stop and gentle enough not to strain the gears or shake the build apart while it sits there.
- Long enough. Pick a time comfortably longer than the arm needs — one to three seconds for most mechanisms. It stalls partway through and spends the remainder pressed against the stop, which is exactly what you want.
- Then reset. reset degrees counted makes this position 0, so every measured move afterwards is measured from a place you know. Now run for (120) degrees is safe, because you know where it is starting from.
After that, use measured blocks for everything inside the travel and timed blocks whenever you are driving to a limit. The rule of thumb: if the movement ends against something solid, run for seconds.
Ports
A Medium Motor is normally plugged into port A or D, which leaves B and C free for the Large Motors that drive wheels. The letter in the block must match the port the cable is actually in — this is the single most common reason a program appears to do nothing at all.
Speed and power
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
Blocks reference
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
Set it first
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
A set speed to 25 %
A run clockwise for 2 rotations
speed last — does nothing
A run clockwise for 2 rotations
A set speed to 25 %
0.00rotations · slow0.00rotations · fast
Speed first: the movement was slowSpeed last: it only affects the NEXT movement
Two programs. Same two blocks in each — only the order is different.
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
Slow is often better
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
Say this back before moving on: “A pin off the centre of a turning wheel moves back and forth. That is where the stroke comes from, not from my program.”
What’s in this build 4 min
Look at your animal. Four flippers, a long neck, wheels underneath — and how many things with a cable?
Medium — in this build
Large — not used here| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and is the body of the animal. Most of the weight sits over the wheels, which is what stops it tipping on to its neck. |
| Medium Motor, port A | Turns the wheels. The flippers are along for the ride — everything you see them do comes from the wheels going round. |
| Sensors | None. It cannot see the edge of the table. That is worth remembering before you set it going. |
Push the animal along the table by hand, slowly. The flippers should sweep as it rolls, and each one should complete a full stroke for each turn of the wheel. If a flipper stays still, its rod has come off — find that now. With the motor running it will look exactly like a program fault.
Ports — and the rule 4 min
Sensors go in ports 1, 2, 3, 4. Motors go in ports A, B, C, D. They are not interchangeable, and nothing will tell you politely if you swap them.
This model drives along the table, and you might expect ports B and C — the driving pair. It is not a driving pair. There is one motor turning one axle, and no way to steer. Port A is right, and the reason is worth holding on to: the port follows the arrangement of motors, not whether the model happens to move.
| Part | Port | Why this one |
|---|---|---|
| Medium Motor (wheels and flippers) | A | A single motor with a job of its own. B and C are for a steerable pair, and one motor cannot steer. |
| Sensors | none | Ports 1–4 stay empty. |
Check your own build now:
- One cable, from the Medium Motor to port A. A letter, not a number.
- Tuck the cable along the body so it does not trail under the wheels. A trapped cable makes an animal that pulls to one side.
- Turn one wheel by hand through a full turn and count the flipper strokes. It should be exactly one.
- Clear a long straight run on the table, and put a book at the far end. It has no sensors and it will not stop.
Connect the Brick 4 min
Two routes, and either is fine. USB is the reliable one and the one to fall back on when a room’s Bluetooth is busy; Bluetooth leaves the robot free to move, which some models need.
How to connect the BrickUSB and Bluetooth, step by step, with a photograph of every screen. Open it if you have not done this before — or if pairing is not working.Show meHide
USB — the reliable one
- Switch the Brick on with the dark grey centre button.
- Cable into the Brick’s PC port — the small square socket beside the numbered ports, not one of the numbered ones.
- Other end into the computer.
Bluetooth — name it first
Do these in order. Naming the Brick after you go looking for it in the list is how groups end up driving each other’s robots.
- Name your Brick. On the Brick: Settings (the spanner) → Brick Name. Type something nobody else will pick, then press the tick. Every Brick is called
EV3until somebody changes it. - Turn Bluetooth on. Settings → Bluetooth. Tick Bluetooth and Visibility. Leave iPhone/iPad/iPod unticked.
- Connect from EV3 Classroom. Click the Brick icon at the top of the programming area, find your Brick by name, and click Connect.
- Say yes on the Brick. It asks “Connect?” with the computer’s name — choose the tick, then accept the passkey, which is already 1234.
EV3.The two failures, every class, every time. The Brick has gone to sleep while you were building — press the centre button to wake it. Or you have paired with the group at the next table, which is why the name matters.
The long version, including Port View and how to read the port tiles, is in the Brick & Bluetooth guide.
Bluetooth is the better choice for this one. The animal travels, and a USB cable will either stop it short or drag it off course — which looks convincingly like a build fault and is not one.
Confirm the connection 2 min
- Check the Brick icon: connected, or not. A plugged-in cable is not a connected Brick.
- Port A shows a Medium Motor. Nothing on B, C or D, and nothing on 1 to 4.
- If A shows a Large Motor, the wrong motor went in at step 1 of the manual.
- Roll the animal along the table and watch tile A count. Note how many degrees pass during one complete flipper stroke — that number is the animal’s stroke, measured.
Make it move 10 min
Five blocks. It is the shortest program in a long while, and that is the point of the lesson.
when program starts :: events hat play sound [Animals / T-rex roar v] until done :: sound [A v] set speed to (40) % :: motors [A v] run [clockwise v] for (5) [rotations v] :: motors play sound [Communication / Goodbye v] until done :: sound
Walk it in the order the Brick runs it:
- play sound … until done — the animal announces itself. Until done means the program waits here, so the call finishes before it moves off.
- [A] set speed to 40 % — a setting. Nothing turns yet. Middling speed: fast enough for the flippers to look alive, slow enough to watch one stroke at a time.
- [A] run clockwise for (5) rotations — measured, so it stops itself. Five turns of the motor, and the block waits until they are done.
- play sound … until done — and the animal signs off.
Count the blocks that mention a flipper. It is none. Four limbs are stroking in rhythm and your program has no idea they exist. Everything they do was decided by whoever placed that pin off the centre of the wheel.
What success looks like: the animal swims forward in a straight line while all four flippers sweep in a steady beat, and stops on its own. If it curves, one side is dragging — look at the cable and the flipper rods, not at the program.
Change it and test 8 min
One change at a time, and predict before each run. Watch the flippers rather than the body — the body only ever goes in a straight line.
- Change set speed to (40) % to 15 %. Predict what happens to the flippers. They stroke more slowly — but through exactly the same arc, because the arc is built in.
- Now 90 %. Predict whether the strokes get bigger. They do not. Speed changes the rhythm; only a rebuild changes the size of the stroke.
- Change [clockwise v] to [counterclockwise v]. The animal reverses — and so does each flipper stroke, running backwards through the same path.
- Change (5) rotations to (1) rotations and count the flipper strokes carefully. Now you know the gearing between the motor and the wheel without taking anything apart.
- Try to make one flipper stroke further than the others, using the program. Give it two minutes and then stop. There is no block for it, and finding that out yourself is the exercise.
Step 5 is the lesson, and it is the same lesson as the Apache two lessons ago from a different angle. What the linkage decides, the program cannot argue with.
The program owns the speed and the direction. The build owns the shape of the movement.