Challenge 1
Clear a lane. Put a line of loose material across the mat and push all of it past a line your teacher names, in one run, without the tracks slipping. Choose your speed by testing rather than habit and say what you chose and why.
What you are building 3 min
The Bulldozer: two Large Motors driving rubber tracks, with a wide blade across the front. It does not just travel — it shifts things.
Every robot you have driven so far has carried exactly one load: itself. It weighed the same at the start of the run as at the end, so once you found a speed that worked, it went on working.
A bulldozer is different. What it has to push changes from moment to moment — nothing at first, then a small pile, then a big one. The job gets harder as it goes, and at some point the machine will simply stop moving.
In the real world 5 min
Where you have seen it
On every construction site and every palm-oil plantation road in the country. A bulldozer is the machine that turns uneven ground into flat ground, and it does it by shoving earth from where it is to where it should be.
Why it is built that way
Look at what it stands on. Not wheels — tracks, and they are the reason it works at all.
A wheel touches the ground in a patch about the size of your palm. A track touches it along its whole length, so the machine’s weight is spread over a much bigger area. Two things follow: it does not sink into soft ground, and it has far more grip.
Grip is the point. A bulldozer has an enormous engine, but an engine is no use if the tracks just spin. Everything the machine can push is limited by how hard it can hold onto the ground.
What would go wrong without it
Put that same engine on wheels and the first serious pile of earth would stop it dead — not because it lacks power, but because the wheels would spin uselessly. You met exactly this on the Elastic Car in Lesson 14, where extra winding past a point just span the tyres.
A machine can only push as hard as it can grip. Power it cannot put through the ground is power wasted.
The main concept — the load is not a constant 6 min
Until now, one speed setting worked for a whole program. From today, the right setting depends on what the robot is being asked to move.
| What the blade is pushing | What the motors have to give |
|---|---|
| Nothing — driving across a clear floor | Very little. Any speed works. |
| A light pile | More force. High speed starts to slip the tracks instead of moving the pile. |
| A heavy pile | All the force there is — and if that is not enough, the motors stall and the program hangs, exactly as on the Push-up Robot in Lesson 32. |
Three ideas you already have meet here for the first time. The Large Motor gives force rather than speed (Lesson 11). A measured motor block waits for a movement that may never finish (Lesson 27). And tracks provide the grip that lets the force reach the ground at all.
There is a rule that falls out of the three, and it is not obvious: for pushing, slower is stronger. A motor asked for less speed has more left over as force. So a bulldozer that will not shift a pile at 80 % will often shift it at 30 %.
When a machine will not move a load, turning the speed up is the wrong instinct. Turn it down.
The Large Motor, and driving with two motorsThe full reference for the strong motor and for the pair blocks. 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.
Driving with two motors
A 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 CBlocks reference
| 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. |
The letters must match the sockets
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.
when program starts
set movement motors to B and C
move forward for 3 rotations
the same program on both robots
2wheels driven · matched1wheel driven · mismatched
B and C: both sockets fullB and C: C is empty
Two robots, and the very same program: drive the motors in ports B and C forward.
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.
Straight, curved, and on the spot
Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.
when program starts
set movement motors to B and C
move for 2 rotations at 50 50 % speed
50left wheel · B50right wheel · C
Equal speeds → a straight line
Both wheels are set to the same speed.
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.
- Both wheels the same speed — the robot goes straight.
- One wheel faster than the other — it curves towards the slower side. The bigger the difference, the tighter the curve.
- One wheel forward, the other backward — it spins on the spot, which is how a robot turns in a space no wider than itself.
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
How far is one rotation?
“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 rotations26.3 cm
1.5 — a half rotation past 1. Half a turn of the wheels is 8.75 cm, so halves matter.
cm=2rotations
35 ÷ 17.5 = 2. That is a number you can type straight into the block.
- 1 rotation = 17.5 cm. Two rotations is 35, three is 52.5.
- Halves are real. 1.5 rotations is a perfectly good thing to type into the block, and it is 26.25 cm — right between the 1 and the 2 you already tried.
- To go a distance you have chosen, divide by 17.5. The calculator does it, but do a few by hand first — 35 ÷ 17.5 = 2 is worth seeing.
- Measure your own wheels before trusting the number. A base built with different wheels travels a different distance per rotation, and every calculation on this page moves with it.
set movement motors to [B v] and [C v] :: movement set movement speed to (30) % :: movement move [forward v] for (2) [rotations v] :: movement
Turning on the spot
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.
Why it matters
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.
Say this back before moving on: “For pushing, slower is stronger.”
What’s in this build 4 min
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and its weight is what presses the tracks into the floor. On this model the Brick is part of the grip. |
| Large Motor ×2 | Ports B and C, one per track. Force, not speed. |
| The tracks and the blade (no cable) | The tracks turn force into grip; the blade turns grip into work. |
Check the tracks before you drive
- Turn one track by hand. Does it run round smoothly, or does it catch on a sprocket?
- Look at the tension. A loose track jumps off under load — which will look exactly like a program fault and is not one.
- Push the bulldozer across the table by hand. Does it run straight, or does one track drag?
- Is the blade square to the machine and low enough to catch things, without digging into the table?
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 track motor | B | B and C are the pair, and B is always left. |
| Right track motor | C | Sit behind the machine to decide which is which. |
| Sensors | none | The bulldozer cannot feel the pile. It finds out by stalling. |
Check your own build now:
- Left in B, right in C, both Large Motors.
- Cables up and over. A cable caught in a track will be pulled out and may be damaged.
- Something to push: a handful of LEGO, a bundle of paper, a small book. Agree with your group what your “earth” is, so your results can be compared.
- A clear run of floor, with the pile at the far end.
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 in reach of the stop button. This machine is built to push against things, so it is the most likely of any model so far to end up stalled with both motors straining.
Confirm the connection 2 min
- Check the Brick icon: connected, or not.
- A Large Motor on B and one on C.
- Turn the left track by hand and check tile B counts. Then the right, and C.
- Leave the port tiles on screen while you push. A degree counter that stops climbing while the program is still running is a stalled motor, and today you will see it.
Make it move 10 min
Five blocks: push out, reverse back. Start with the blade just touching the pile.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (35) % :: movement move [forward v] for (4) [rotations v] :: movement move [backward v] for (4) [rotations v] :: movement
Walk it in the order the Brick runs it:
- set movement motors to B and C — a setting. The two tracks are a pair and must stay in step, or the machine turns instead of pushing.
- set movement speed to 35 % — low on purpose, for the reason in section 4.
- move forward for 4 rotations — the push. Watch the tracks: are they gripping, or slipping under the machine?
- move backward for 4 rotations — reverse out, leaving the pile where you put it.
What success looks like: the pile moves, the tracks keep gripping, and the bulldozer reverses cleanly out. Mark where the pile started and where it ended — that distance is your score for the rest of the lesson.
If the tracks spin and the pile does not move, do not raise the speed. Lower it. If it still will not go, your pile is heavier than this machine can shift, and knowing that limit is a result too.
Change it and test 8 min
One change at a time, and predict before each run. Measure how far the pile moves every time and write it down.
- Set the speed to 90 % with the same pile. Predict whether it pushes further. Most groups find it pushes less far, and the tracks slip.
- Now 15 %. Slow and determined. Compare all three distances.
- Find the speed that shifts your pile furthest. Test at least four values. That number is a real engineering answer and it is specific to your machine and your floor.
- Keep the best speed and make the pile bigger, a bit at a time, until the bulldozer stalls. Stop the program the moment it does. Record the pile size that beat it.
- Now put something under the tracks that reduces grip — a sheet of smooth paper. Same speed, same pile. What happens, and why?
Step 5 separates the two things that look identical from outside. On paper the motors are turning and the machine is going nowhere: that is slipping. Against a heavy pile the motors are not turning at all: that is stalling. Watch the degree counters and you can tell them apart instantly.
Slipping is a grip problem. Stalling is a force problem. They need opposite fixes, so name which one you have before you change anything.