EV3 Robotics›Level 1 · Beginner›Lesson 21
Level 1 · Lesson 21 · EV3-L01-2160 minutes · Ages 9–16 · Model: Hexapod Walking Robot
The Hexapod: a six-legged walker with the Brick as its body, one motor, and a crank that swings all six legs in step. It walks across the table like an insect.
Every robot you have built so far has begun the moment you pressed play on the computer. This one waits. It stands still, tells you what it wants, and does nothing at all until a person presses a button on the Brick itself.
That is a real change. Up to now your programs have talked to motors. This one listens to a human.
Six-legged robots are used where wheels give up: collapsed buildings, rubble, pipework, the surface of another planet. Engineers did not invent the design — they copied it from ants, beetles and cockroaches, which have been solving rough ground for a very long time.
Six legs, not four, and the reason is arithmetic. A six-legged walker can always keep three feet on the ground while the other three swing forward — and three points of contact make a tripod, which cannot rock. So it is stable at every single moment of its stride, without balancing and without ever thinking about it.
A two-legged robot has to catch itself on every step. A hexapod never falls over in the first place. Watch your own model from the side as it walks and count the feet that are down.
A machine that starts the instant it is powered is a machine nobody can be ready for. Real equipment — lifts, presses, rides, power tools — waits for a deliberate human action first, and the wait is the safety feature.
A robot that starts when you say so is safer, and easier to use, than one that starts when it is switched on.
The Brick’s five buttons are not only for finding files. A running program can read them, which makes them the first input in this course that needs no sensor and no extra wire.
wait until stops the program dead until something becomes true. Everything below it is frozen; nothing above it is undone.
You have met a wait before, but it was a wait for time — the ten seconds that set the length of the Ferris Wheel ride. Time always passes. This kind of wait might never end, and that is exactly what makes it useful: the robot is not counting down, it is watching for you.
the other way to do it
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The Brick has five buttons of its own — up, down, left, right and centre. They need no sensor, no cable and no port, which makes them the easiest way to let a person tell the robot to do something.
| Block | What it does |
|---|---|
when [center v] button [pressed v] :: events hat | Starts a whole stack when that button is pressed. |
wait until <is [center v] button pressed? :: sensors> | Holds an existing program until the button is pressed. |
A program sitting on a wait block looks exactly like a program that has crashed. Watch one wait — including through two presses of the wrong button.
the other way to do it
A program parked on a wait block looks identical to a crashed one. This is why the status light or a line on the screen is worth setting before you wait.
The wait is watching one button. Up and right change the (button) reading, and the program does not care. That reading is a number rather than a name: 0 for nothing, then 1 left, 2 centre, 3 right, 4 up, 5 down.
Nearly every machine has a start button that is deliberately separate from switching the power on. A robot that begins moving the instant it is powered up is hard to set down and hard to test — one that waits for a press can be positioned first.
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: “wait until holds my program until something is true. It does not check the clock — it checks the world.”
Look for the parts with cables. There is only one motor — which should surprise you, because the robot has six legs.
EV3 Brick × 1
Large Motor × 1The motor turns a crank — an axle with an offset arm on it. As the crank goes round, the arm rises, swings forward, drops and swings back, and beams carry that same movement out to every leg. Round-and-round at the motor becomes step-step-step at the feet.
The legs are not all at the same point in the cycle. That is deliberate, and it is what keeps three feet down at all times.
Turn the crank slowly by hand and watch one leg. Follow it through a full turn: lift, forward, down, back. Then look at the leg on the opposite side and notice it is doing the opposite half of the same cycle.
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.
Today there is a second thing worth saying about that rule: the buttons have no port at all. They are built into the Brick, so there is nothing to plug in and nothing to get wrong — which is exactly why they are a good first input.
| Part | Port | Why this one |
|---|---|---|
| Large Motor (drives the crank) | A | A single working motor conventionally takes A. Every program on this page says A. |
| Brick buttons | none | Part of the Brick. Nothing to plug in. |
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.
Use Bluetooth today if you can. This robot walks away from where it started, and a USB cable will either stop it short or drag it sideways — which looks like a broken program and is not one.
If the number does not move when the crank does, stop here. The cable is in the wrong port or not pushed fully home.
There is nothing to check for the buttons — that is the point of them. If the Brick is on, they work.
Six blocks. The robot asks, waits, and then walks — and it will wait all day if nobody presses anything.
when program starts :: events hat write [PRESS CENTRE] at line (1) :: display wait until <is [center v] button pressed? :: sensors> clear display :: display [A v] set speed to (50) % :: motors [A v] run [clockwise v] for (5) [rotations v] :: motors
Walk it in the order the Brick runs it:
What success looks like: the screen asks, the robot stands perfectly still for as long as you leave it, and on the press it walks forward in a straight-ish line and stops on its own.
One change at a time, and predict before each run. Mark the start position on the table so you can measure how far it actually gets.
Step 4 is the same shape of mistake as putting a speed block after the movement it was meant to change, back in Lesson 3. Blocks do not reach backwards. Order is meaning.
If the robot shuffles on the spot instead of walking, the feet are slipping rather than gripping. Try a lower speed, a surface with more grip than a polished table, and check that all six feet are actually touching when it stands still.
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.
Make the robot walk only while somebody is asking for it: press the up button and it takes five strides, and it must show a different message on the screen while walking than while waiting. A person across the room should be able to tell which state it is in.
Give the robot two buttons that do different things. One button makes it walk forward, the other makes it walk backward. It must be ready for a press again after each walk, so a person can send it back and forth without restarting the program.
Make the robot count its own strides on the screen — 1, 2, 3 — as it walks, and stop by itself after eight. The number must go up as it steps, not appear all at once at the end. You will need to think about what has to happen inside the repeating part and what belongs outside it.
A hexapod is built for ground that wheels cannot cross. Prove yours is. Set up a short course with an obstacle a wheeled robot would fail on — a ruler laid flat, a book cover, a slope of stacked paper. Your robot must wait for a person to start it, cross the obstacle, and stop on its own on the far side. Plan on paper first. Decide what your robot needs in order to climb rather than shuffle, and remember that not all of the answer is in the program: stride speed, how many strides, and where the feet grip are all yours to choose. Two questions when you demonstrate it. Why does six legs get across something four wheels would not? And what is the largest obstacle yours can manage — measured, not guessed?
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.