EV3 Robotics›Level 1 · Beginner›Lesson 25
Level 1 · Lesson 25 · EV3-L01-2560 minutes · Ages 9–16 · Model: Toddle Bot
The Toddle Bot: a robot with no wheels that walks by rocking. Two Large Motors swing its body from side to side, and each rock shuffles it a little further forward.
It is a LEGO Official model, and it is one of the neatest walkers in the set — there are no legs to speak of, just a body that leans left, leans right, and somehow ends up across the table.
This is the first model in the course where a perfectly legal program can break the hardware. Not fail. Not fall over. Break. The two motors are joined by one axle, and if your program tells them to turn opposite ways they will fight each other through solid plastic until something gives.
Read section 4 before you write a single block.
A penguin. They have short legs set far back and they cannot take a long stride, so they walk by rolling their whole body from one foot to the other — and it works well enough that a king penguin will cross kilometres of ice like that.
Rocking walking is genuinely efficient. Instead of lifting a leg and carrying it forward — which costs energy every step — you lean, let the foot on the light side swing through, and lean back. Gravity does some of the work.
Waddling looks comical and is nothing of the sort. It is a way of walking that needs almost no leg mechanism at all, which is exactly why it suits a robot built from a Brick and two motors.
Now the part that matters today. A penguin’s two legs are joined — by its hips, by its spine, by one rigid body. They cannot decide to go in opposite directions, because they are physically part of the same animal.
Your Toddle Bot is the same. The two motors are joined by an axle, and an axle does not negotiate. If one motor turns clockwise while the other turns counterclockwise, all that force has nowhere to go except into the plastic between them.
Two motors bolted to one shaft are not two motors. They are one shaft — and the program has no way of knowing that.
The Brick has no idea what your model is made of. It will run whatever you write, and it will keep running it while the gears strip.
So which blocks are safe? The rule is short:
| Block | Safe on this model? |
|---|---|
move [forward v] for (1) [rotations v] :: movement | Yes. Both motors, same direction, same speed. |
move for (1) [rotations v] at (75) (25) % speed :: movement | No. Two different speeds on one shaft is a fight, just a slower one. |
[B v] run [clockwise v] for (1) [rotations v] :: motors | No. Driving one motor of a joined pair means the other is a brake. |
Notice what has changed. Everything in that table is a normal, correct EV3 block, and two of them will damage this particular model. The block is not wrong. It is wrong here.
Before you write a program, find out what your machine cannot survive. The Brick will never tell you.
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 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.
Some models have no motors and no sensors at all. They are not lesser lessons — they are where the physics lives. A build that stores energy, changes a force, or turns one kind of motion into another explains why the powered models later need the gearing and the speeds they do.
Gears, pulleys and levers look like three different topics and are three shapes of the same deal: whatever you gain in force, you pay for in distance. Halve the effort and you move twice as far; move half as far and you need twice the effort. No arrangement of anything gives you both, and recognising that saves a great deal of time hunting for one.
What a mechanism actually does is let you spend the same effort in a form you can manage — a little at a time instead of all at once, or all at once instead of a little at a time.
| Tutorial | The question it answers |
|---|---|
| Gearing up and gearing down | How do I trade turns for force? |
| Changing the direction of a turn | Why is it going backwards, and how do I drive an axle at 90°? |
| Pulley systems | How does a rope let a small motor lift a big load? |
| Levers — effort, load and pivot | Where should the pivot go? |
| Elastic and stored energy | How much further does pulling back twice as far actually get me? |
| Scissor mechanisms | How do I make something extend a long way — and why won’t it start? |
| Oscillatory motion | How do I turn going round into going back and forth? |
| Centre of gravity | Why does it keep falling over? |
| Biomimetic mechanisms | How does a machine walk without ever being told to? |
Friction is what makes wheels grip and also what wastes effort. Every mesh, pin and rope turn loses a little to it, so a mechanism with more parts delivers less than the arithmetic promises. A build that binds — that is stiff to move by hand — is losing far more than that, and no amount of extra motor power fixes a mechanism that is rubbing.
Before measuring anything, turn the mechanism by hand. It should move smoothly and coast a little. If it does not, fix the build first; numbers taken off a binding mechanism describe the binding, not the idea you were trying to test.
Since there is nothing to program, the work is measuring. Change one thing, keep everything else the same, and record what happened — pull the car back 5 cm, then 10, then 15, and measure how far each one travels. Three readings at each setting, not one, because a single run is not evidence.
That is genuinely how engineers test, and it is the same discipline that makes debugging a program work: change one thing at a time.
Say this back before moving on: “Both motors, same direction, same speed — always, on this model.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program, and is the body that gets rocked. Its weight is what the rocking has to throw about. |
| Large Motor ×2 | Ports B and C — and the manual itself says so, which is rare in this course. Joined by one axle. |
| The shared axle (no cable) | The part that makes this lesson necessary. Find it before you go further. |
Brick off. This is a thirty-second test with a big payoff.
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 |
|---|---|---|
| Large Motor (one side) | B | B and C are the pair, always. The manual’s last step labels the two cables B and C — follow it. |
| Large Motor (other side) | C | Which motor is B and which is C matters less here than usual, because they are joined — but write down which is which anyway. |
| Sensors | none | The Toddle Bot walks where it is pointed. |
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 is the better choice today. This robot travels, and a trailing USB lead pulls on one side of a machine whose whole method is leaning evenly from side to side.
Two counters moving as one is the clearest proof you will get that these are not two independent motors.
Four blocks, and every one of them talks to the pair rather than to a motor. That is not a style choice today — it is the safety rule.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (40) % :: movement move [forward v] for (10) [rotations v] :: movement
Walk it in the order the Brick runs it:
What success looks like: a steady side-to-side rock with the whole body leaning, and the robot travelling — slowly, and not necessarily straight. Toddle Bots wander. That is honest to how they work.
If it buzzes and stays put, stop the program at once and check: is one cable in A or D instead of B and C? A pair with only one motor connected is one motor driving against a dead one, and that is the fight you are trying to avoid.
One instruction for this whole section: do not make the motors disagree. No steering, no two different speed numbers, no single-motor blocks. Everything below keeps the pair in step on purpose.
Somewhere in this lesson you will have wondered what actually happens if the motors disagree. It is a fair question and the answer is worth knowing: the motors stall, the Brick keeps pushing current into both of them, and the weakest thing in the chain gives way — usually a gear tooth or the axle’s cross-hole.
Do not test it. You would learn one fact and lose a model, and the fact is in this paragraph for free.
Knowing what would break, and choosing not to do it, is engineering. Finding out by breaking it is just breakage.
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.
Walk it to a line. Put tape one metre away and find the number of rotations that lands the Toddle Bot on it. Every block must drive the pair — no single-motor blocks, no steering, no two different speeds. Three runs that all reach the line with no adjustment in between.
Find its best speed and prove it. Test at least four speeds, measuring how far ten rotations carries it each time, three runs per speed. Report the winner with your numbers. A rocking walker has a speed where it grips best, and it is not the fastest one.
Make it walk out, pause, and walk back to its start line. It will not land exactly — legs slip — so first measure how far off it typically is over five attempts, then adjust your return distance to compensate and show that your correction actually helps.
Write a safety note another class could follow. Your Toddle Bot must complete a journey you design — at least two metres, with at least one pause — driven entirely by pair blocks. Alongside it, produce a written note for whoever builds this model next, explaining what they must never do to it and why. Plan on paper before you build. Go through every movement block EV3 offers and sort them into two lists: safe on this model, and not safe on this model. That list is your note. Two questions when you demonstrate it. Point at any block in your program and say how you know it keeps both motors in step. And what exactly would break first if they disagreed — the motor, the axle, or something else?
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.