Challenge 1
Make the robot report properly. It must write READY before it starts, count each press-up on screen as it happens, and write DONE at the end. If it stalls part-way, the last number on screen must tell you which rep it died on.
What you are building 3 min
The Push-up Robot: the Brick lying flat as a body, with a Large Motor on each side working an arm. It presses itself up off the table and lowers itself back down, over and over.
Every model so far has moved something else — a fan blade, a barrier, a wheel. This one lifts itself, and a Brick is the heaviest thing in the kit.
Which means this is the model that will genuinely run out of strength. And when an EV3 motor runs out of strength, it does something you have not seen yet: it does not stop, and it does not carry on. The program simply stays where it is, for ever.
In the real world 5 min
Where you have seen it
A press-up is the standard test of whether you can move your own body weight. No equipment, no weights — just you, the floor, and however many you have got left.
Why it is built that way
Two arms, working together, lifting a load that does not change. That is why press-ups are a good test: the weight is always exactly you, so the only thing that varies is how much strength you have left.
And there is a point — everybody has one — where the arms are pushing as hard as they can and the body does not rise. Not slowly. Not at all. You are working flat out and nothing is happening.
What would go wrong without it
Now think about that moment from the outside. Somebody watching sees a person lying still, apparently doing nothing, straining.
A robot in that state looks even less dramatic. A stalled EV3 motor makes a faint buzz and holds still, and the Brick shows no error, no message, no light. It has not crashed. It is following your program exactly, waiting for a movement that is never going to finish.
The most confusing failure in robotics is not a crash. It is a machine doing precisely what it was told, for ever.
The main concept — the stall 6 min
A measured motor block waits until the movement is finished. If the movement can never finish, the block never finishes either — and everything below it never runs.
You have relied on this behaviour since Lesson 5 without noticing it. A block like run [clockwise v] for (2) [rotations v] does not just start the motor — it holds the program there until two rotations have actually happened. That is what makes measured movement useful.
It is also the trap. The block is not counting seconds. It is counting degrees the shaft has actually turned. Jam the shaft and the count stops, and the block waits.
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.
Look at what the demo uses as proof: a block after the motor block, and a screen that stays blank. You cannot see “the block has not finished” — a stalled motor looks exactly like a stopped one. What you can see is that the next thing never happened.
| Block | What it does if the shaft jams |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | Hangs. Waits for a rotation that will not come. |
[A v] run [clockwise v] for (2) [seconds v] :: motors | Finishes. Two seconds pass whether the shaft moves or not. |
wait until <(timer) > (5)> | Finishes. The escape hatch from Lesson 20 — the clock runs regardless. |
So there are two honest fixes, and they are the same fix in different clothes: measure something that cannot get stuck. Time always passes. Rotations do not always happen.
To find out whether a program is stuck, put a block after the suspect one and watch for it. Silence is not information; a missing message is.
The Large Motor, and measured movementThe full reference for this motor and for rotations and degrees. Open either if it is not clear yet.Show meHide
The Large Motor
The Large Motor is the bigger of the two EV3 motors. It turns more slowly than the Medium Motor but pushes far harder, which is why it drives wheels and lifts loads. If a mechanism struggles or stalls with a Medium Motor, this is usually the answer.
Large Motor
Medium MotorBlocks reference
| Block | What it does |
|---|---|
[B v] run [clockwise v] for (3) [rotations v] :: motors | Turns the motor a measured amount, then stops. |
[B v] run [clockwise v] for (2) [seconds v] :: motors | Turns it for a length of time rather than a distance, then stops — however far the shaft actually got. |
[B v] set speed to (40) % :: motors | Sets how fast the next movement will be. |
[B v] start motor [clockwise v] :: motors | Starts it turning and carries straight on. |
Watch them race, then watch them lift
Give both motors the same program and the same arm. With nothing on the arm the Medium Motor wins easily — which is why it is tempting to treat it as simply the better motor. Then the demo hangs a weight on both arms and runs it again.
when program starts
A run clockwise for 1 rotations
and on the Large Motor, only the port changes
B run clockwise for 1 rotations
0%medium lifted0%large liftednoneload
Medium: not enough forceLarge: slower, but it lifts
) : clock.step === 1 ? (With nothing to lift, the Medium Motor is quicker
The same program, the same arm, one on each motor. Nothing to lift yet.
Turning the speed up would not rescue the Medium Motor here — a stalled motor needs more force, which means gearing it down or using the Large Motor.
That is the whole difference. The Medium Motor is quicker; the Large Motor is stronger. A motor that cannot produce enough force does not move slowly — it stops altogether and strains, which is the buzzing, going-nowhere failure almost every LEGO builder meets sooner or later.
A stalled Large Motor hangs the program too
Being stronger buys the Large Motor a bigger load, not an infinite one. Every winch runs out of cable and every lift reaches the top of its rails, and when a motor arrives at a limit it stalls: the shaft stops turning and the motor sits there straining.
That is a problem for the program, not just the mechanism. run for (3) rotations does not finish when three rotations’ worth of time has gone by — it finishes when the shaft has actually turned three times. A winch that reaches the top after two and a half will never report three, so the block waits, and every block after it is unreachable. Nothing crashes. The motor keeps pushing and the rest of the program simply never happens.
The third setting in that dropdown is the way out. for () seconds drives the motor for a duration and then stops regardless, so it always finishes and the program always moves on. Drive into a limit slowly, for a comfortably long time, and then call that position zero:
when program starts :: events hat [B v] set speed to (30) % :: motors [B v] run [counterclockwise v] for (3) [seconds v] :: motors [B v] reset degrees counted :: motors
The lift ends up against its own stop, the encoder is zeroed there, and every measured move afterwards starts from a place you know. The rule is the same for both motors: if the movement ends against something solid, run for seconds; if it ends somewhere in the middle, measure it. The Medium Motor module has the animation for it — see The Medium Motor, which is where this bites hardest, because a Medium Motor is usually the one doing the lifting.
Which motor for which job
- Large Motor — wheels, winches, anything lifting weight. Strong, slower. Normally ports B and C.
- Medium Motor — arms, gates, jaws, pointers. Quick, lighter. Normally ports A and D.
The blocks are identical apart from the port letter, so swapping one motor for the other is a build change, not a programming change.
Why it matters
Real machines match the motor to the load. A lift uses a powerful, slow motor; the button panel beside it uses tiny ones. Choosing the wrong size is the most common reason a LEGO mechanism whines but does not move.
Rotations and degrees
There are two ways to tell an EV3 motor how much to move: give it a length of time, or give it an amount of turn. Only the second one is repeatable, and that difference decides whether a machine works reliably or only sometimes.
Blocks reference
| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | One full turn of the motor shaft, then stop. The program waits for it. |
[A v] run [clockwise v] for (180) [degrees v] :: motors | Half a turn. 360 degrees is one rotation. |
Count it as it turns
The counters below tick up in step with the shaft, so you can watch a rotation being counted rather than take it on trust.
when program starts
A run clockwise for 2 rotations
the same movement, written in degrees
A run clockwise for 720 degrees
0.00motor rotations0°motor degrees0.00gear rotations
The program begins. Nothing has turned yet, so both counters read zero.
The two motor read-outs are the same measurement — 1 rotation is 360°. Use whichever makes the number easier to read.
Rotations or degrees?
Notice that the two motor counters finish together: 2.00 rotations and 720° are the same instant, because they are the same measurement in different units. So pick whichever makes the number easier to read. A winch that needs eight full turns is clearest in rotations. A gate that lifts a quarter turn is clearest in degrees — 90 rather than 0.25.
Gearing changes the answer
The third counter is the one that catches people out. The block counts turns of the motor, not of the thing it drives — and the gear in the demo is three times the size, so two motor rotations move it only 0.67 of a turn. Ask for two rotations and the mechanism does not move two rotations’ worth unless the gearing is one to one.
That is why a number that works on one build has to be retuned when the gearing changes — the program is right, the mechanism is different.
Why it matters
A printer feeds paper an exact distance; a lift stops level with the floor; a robot arm returns to the same place a thousand times. None of that is possible by timing a motor — they all count turns.
Say this back before moving on: “A run-for-rotations block waits for the shaft. If the shaft stops, the program stops with it.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program — and is the load. Everything the arms lift is this. |
| Large Motor ×2 | The two arms, ports B and C. The strong motor, and this model needs every bit of it. |
Feel the load before you power it
- Lift the whole model by its arms with your fingers, gently. That is the weight the two motors have to shift, and it is more than anything you have asked a motor to move so far.
- Turn one arm through its full sweep by hand. Where in the sweep does it feel hardest? That is where a stall will happen if one is going to.
- Check both arms sweep the same amount. An arm mounted one hole differently will hit the table before its partner and jam the pair.
- Look at where the arms meet the table. Are they flat, or on a corner? A corner digs in and turns a push-up into a stall.
The hardest point is at the bottom. Just like a real press-up: the moment of pushing off from the lowest position is where it either goes or does not.
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.
| Part | Port | Why this one |
|---|---|---|
| Left arm motor | B | B and C are the pair, as on the Frog in Lesson 26. Two motors doing the same job at the same time is exactly what the pair is for. |
| Right arm motor | C | Right is C. Sit behind the robot to decide which is which. |
| Sensors | none | Worth noticing: the robot cannot feel that it is stuck. That is the whole problem. |
Check your own build now:
- Cables in B and C.
- Both must be Large Motors. A Medium on one arm will stall while the Large one is still pushing, and the robot will twist.
- Clear space around it. It moves itself about more than you expect.
- A hard, flat surface — not a book, not a folder. A soft surface lets the arms sink in and stall at the bottom.
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.
Stay connected today, whichever you choose. You are deliberately going to make this program hang, and the stop button on the computer is how you get out of it. A stalled motor left pushing gets hot.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Large Motor on B and one on C.
- Move the left arm by hand and check it is tile B whose degrees counted changes. Then the right, and C.
- Leave the port tiles on screen while you run today’s programs. A stalled motor shows up there as a degree counter that has stopped climbing while the program is still running — which is the clearest live evidence of a stall you can get.
Make it move 10 min
Seven blocks. Five press-ups, and then a word on the screen — and that last block is the most important one in the program.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (50) % :: movement repeat (5) move [forward v] for (120) [degrees v] :: movement move [backward v] for (120) [degrees v] :: movement end write [DONE] at line (1) :: display
Walk it in the order the Brick runs it:
- set movement motors to B and C — the two arms are a pair, so they push together. Two separate motor blocks would give you a lopsided press-up.
- set movement speed to 50 % — a setting. Steady: lifting a weight is not a job for full speed.
- repeat (5) — five press-ups.
- move forward for 120 degrees — the push up. Measured, so the block waits until 120 degrees have actually happened. This is the block that can hang.
- move backward for 120 degrees — back down.
- write DONE at line 1 — outside the loop, after the end. It runs once, when all five are complete. If you never see DONE, the robot never finished.
What success looks like: five clean press-ups, the body clearly rising off the table each time, and DONE appearing on the screen at the end. All three parts matter — especially the third.
If DONE never appears, the robot is stalled. Stop the program from the computer, then check: is the surface hard, are both arms flat, are both motors Large, is 120 degrees more than the arms can actually sweep?
Change it and test 8 min
Today you are going to cause a stall on purpose, so you can recognise one for the rest of the course. Keep the stop button within reach, and never leave a stalled motor pushing for more than a couple of seconds.
- Run the program and, while it is going, hold the body down gently with one finger. The motors buzz, the arms stop, and the screen stays blank. Let go after two seconds and watch it carry on.
- Do it again and watch the port tiles. The degree counters freeze while the program is still running. That is a stall, seen as a number.
- Now hold it down and keep holding. The program does not give up, does not report anything and does not move on. Stop it from the computer after five seconds.
- Change both 120 degrees to 1 second — the seconds unit, not degrees. Run it and hold the body down again. Predict what happens to DONE this time.
- Step 4 is the fix, and it has a cost. Time-based press-ups do not stall, but they also do not go the same distance every rep. Which would you rather have on a machine like this?
Step 4 is the trade this whole lesson is about. Measured movement is exact and can hang. Timed movement always finishes and is not exact. Neither one is the right answer everywhere.
Rotations promise a distance and can wait for ever. Seconds promise an ending and cannot promise a distance. Pick the promise your machine actually needs.