EV3 Robotics›Level 1 · Beginner›Lesson 10
Level 1 · Lesson 10 · EV3-L01-1060 minutes · Ages 9–16 · Model: Walking Bot
The Walking Bot: a machine that crosses the table on legs instead of wheels. One motor, at the front, and a linkage that turns going round into stepping forward.
It only does two things — forward and backward. It cannot steer. That is not a shortcoming, it is the whole point: everything the motor gives is spent on the hard part, which is picking the machine up and putting it down again, over and over.
You have plugged a Large Motor into a model before, with the Hexapod. Nobody told you why it had to be that one. Today you find out — and you will be able to feel the answer, because the wrong motor in this build does not go slowly. It stops dead.
Almost nothing humans build walks. We build wheels, because wheels are simple and roads are flat. Legs turn up where the ground will not cooperate: rescue robots over rubble, machines that cross sand, and the animals that got there first.
A wheel holds the body up the whole time it turns. A leg does not. It has to lift the machine, swing it forward and set it down — so once every step the entire weight is being raised by one motor through one linkage.
That is a job that needs force, not speed. Jansen’s beach beasts are pushed along by wind, which is a very weak power source, so he made the legs long and geared them so that a slow, steady turn becomes a strong step. Slow is not the compromise here. Slow is the design.
Put a fast, weak motor on a legged machine and it does something students find genuinely confusing: it makes a noise and goes nowhere. The motor is turning as hard as it can and the load will not shift.
It looks like a flat battery, or a jammed gear, or a bug. It is none of those. It is the wrong motor.
A motor that whines and does not move is not broken. It has been asked for more force than it has.
The EV3 has two motors. One is fast and one is strong, and you cannot have both.
Large Motor — strong
Medium Motor — fast| Motor | Turning force | Top speed | Use it for |
|---|---|---|---|
| Large Motor | High | Lower | Driving wheels, walking legs, lifting — anything shifting the weight of the whole robot. |
| Medium Motor | Lower | High | Arms, gates, jaws, launchers — light things that need to react quickly. |
The word for turning force is torque. It is not the same as speed, and it is worth being fussy about the difference: speed is how fast the shaft turns, torque is how hard it can push while turning. Inside the Large Motor is a longer gear train, and gearing down trades speed away to buy torque — exactly the trade you met with the Ferris Wheel and the Gear Shooter, only this time it is built into the part.
and on the Large Motor, only the port changes
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.
Choose the motor by the job, not by which is bigger. Heavy and slow is the Large Motor. Light and quick is the Medium 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 MotorMedium Motor| 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. |
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.
and on the Large Motor, only the port changes
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.
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.
The blocks are identical apart from the port letter, so swapping one motor for the other is a build change, not a programming change.
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.
Biomimetics is copying a solution from nature. Not the look of an animal — the mechanism. Wheels are a human invention and a very good one, but nothing in nature has them, and there are places a walking machine goes that a wheeled one cannot.
Nothing in a walking robot walks. There is a motor going round and round at a perfectly steady rate — the same motion that drives a car — and a linkage: a set of bars pinned together whose shape turns that circle into a footstep.
Push down, lift, swing forward, put down. No sensor decides when to do each part, and no block in the program says step. The bars do it, because of how long they are and where they are pinned.
The faint circle is the crank pin. The green outline is where the foot goes. They are driven by the same axle and they are not remotely the same shape — that difference is the linkage.
The two paths on that stage are the whole module. The crank pin travels a perfect circle. The foot travels something flat along the bottom and arched over the top — and they are driven by the same axle at the same speed. Everything between them is link lengths.
The famous designs are worth looking up by name: Jansen linkages (the strandbeest walkers), Klann linkages, and the four-bar “Chebyshev” walker. All of them are the same trick with different numbers.
| In nature | As a mechanism |
|---|---|
| A caterpillar or inchworm | Anchor one end, contract, anchor the other, extend. Slow, and it climbs anything. |
| A fish tail or a snake | A chain of segments swung out of phase — a travelling wave that pushes backwards. |
| A bird wing | A four-bar linkage that flaps and feathers at once, from one rotation. |
| A hand or a claw | Linked fingers driven from a single input, so they close around a shape rather than onto a fixed position — a lever chain that adapts by itself. |
Be honest about the trade, because it is the engineering content of the whole topic. Wheels are far more efficient, far simpler and far faster on anything flat. Legs are worth their complexity when the ground is not flat: steps, rubble, soft sand, gaps. A walking machine chooses where to put its feet; a wheel has to roll over everything in between.
Robots that copy animals are how machines reach places wheels cannot: search and rescue in collapsed buildings, inspection inside pipes, planetary rovers over loose ground. Studying the mechanism instead of the appearance is what turns an interesting animal into a working machine.
Say this back before moving on: “Torque is how hard a motor can push. The Large Motor has more of it and less speed.”
Two electronic parts again — and this time you have just learned enough to say why it is this motor and not the other one.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program — and is most of what the legs have to carry. This machine is mainly walking its own battery around. |
| Large Motor | Drives the front legs through a linkage. Lifting the whole model once per step is the heaviest job any model has given a motor so far. |
Look at the back of your model. The rear legs are fixed and joined to nothing, and they end in a small wheel. Only the front legs are driven.
That linkage is the clever part of this model, and it contains no electronics at all. One turning shaft, several bars of different lengths, and the circle comes out the far end as a step.
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 (drives the front legs) | A | One motor doing a job of its own takes A. Note this is not B or C — those are the pair used for a driving base with two wheels, and this machine has neither. |
| Sensors | none | The Walking Bot cannot see, feel or steer. It 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 worth the trouble today. This machine walks away from you, and a USB cable becomes a leash that drags it off course after about twenty centimetres. If you must use USB, leave plenty of slack and re-run the test when a walk looks crooked.
If the tile says Medium Motor, you have the wrong part in your hand. Swap it now — no amount of programming will fix it later.
Five blocks: walk out, pause, walk back. Rotations, not degrees — this movement goes round and round rather than stopping somewhere, so rotations is the natural unit.
when program starts :: events hat [A v] set speed to (40) % :: motors [A v] run [clockwise v] for (6) [rotations v] :: motors wait (1) seconds [A v] run [counterclockwise v] for (6) [rotations v] :: motors
Walk it in the order the Brick runs it:
What success looks like: a slow, deliberate walk in a roughly straight line, the body rocking a little with each step, and a return trip that ends up near the start. “Near” is honest — legs slip, and a walking machine is never as repeatable as a wheeled one.
If it buzzes but does not walk, do not turn the speed up. That makes it worse. Lift the model — do the legs move freely in the air? If they do, the linkage is fine and the problem is load: check nothing is catching, and check the tile really does say Large Motor.
One change at a time, and predict before each run. Mark the start position with a piece of tape so you can measure how far it actually gets.
Step 2 is the surprise. Faster is not further. Somewhere between 40 % and 100 % there is a speed where the feet stop gripping, and past that everything extra is wasted on slip. Real walking robots run into exactly the same wall.
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.
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.
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 to a mark and stop there. Put a piece of tape on the table one metre from the start line and find the number of rotations that lands your bot on it. You may run as many times as you like to find the number, but the last three runs must all reach the tape without a change in between.
Out and back to the same place. Your bot must walk away, pause, and return so that it finishes on the start line rather than somewhere near it. Legs slip, so this is harder than it looks — choose your speed from evidence rather than habit, and say which speed you chose and why.
Find your motor's limit and prove it. Load the bot with more and more weight until it stops walking, testing at three different speeds. Record what load stopped it at each speed. Then answer, with your numbers as evidence: does a slower speed let it carry more, or less?
Make the bot earn its keep: a delivery walk. Your Walking Bot must carry a load of at least the weight of a spare Brick from a start line to a target you set at least a metre away, put nothing down but arrive still walking, and then return under its own program without being repositioned. Plan on paper before you build. A loaded machine does not behave like an empty one — it walks shorter steps and slips more — so work out how you will find the right number of rotations for the loaded trip rather than reusing the empty one. Two questions when you demonstrate it. Why is a Large Motor the right choice here, in your own words and with something you measured to back it up? And what happened to your distance per rotation when you added the load, and why?
