EV3 Robotics›Level 1 · Beginner›Lesson 26
Level 1 · Lesson 26 · EV3-L01-2660 minutes · Ages 9–16 · Model: Mechanical Frog
The Mechanical Frog: two motors, one for each back leg. Swing both legs back together and the frog shoves itself forward; bring them back and it is ready to go again.
The Walking Bot in Lesson 10 had one motor and stepped along. This has two, and they are not taking turns — they have to move at the same instant, or the frog does not go forward at all. It turns.
An honest warning: it will not actually leave the ground. The motors are not fast enough to throw the whole model into the air, and the catalogue says so plainly. It shuffles forward in hops. That is a real limit of real hardware, and getting it as close to a jump as it can go is the mission at the end.
Malaysia is full of frogs — you can hear them from any drain after rain. A frog can clear twenty times its own body length in one jump, which for a person would be most of a football pitch.
Look at the photograph. Both legs are doing exactly the same thing at exactly the same time. That is not a coincidence — it is the only way a jump works.
A frog’s back legs are long, which lets them push against the ground for a long time, building speed all the way. And they fire together. If one leg pushed a fraction before the other, the frog would spin off sideways instead of going where it was looking.
Now think about your two motors. If your program drives one and then the other — even a tenth of a second apart — the frog gets a shove on one side, then a shove on the other. It does not go forward. It waddles, and it slowly turns.
You have felt this yourself. Rowing a boat with one oar at a time takes you in a circle; both together take you across the lake.
Two pushes, one after the other, is not the same as one push twice as big. Together is a different movement, not just a faster one.
This model has no step-by-step manual, and the video below is not one. It is a film of a finished frog moving — worth watching closely for how far the legs actually swing, and for how modest the hop really is. Then build from the model your teacher has. You are not missing a page; the page does not exist.
EV3 has a whole category of blocks for driving two motors as a pair. You met them on the Driving Base in Lesson 1. They are not only for wheels.
| Block | What it does |
|---|---|
set movement motors to [B v] and [C v] :: movement | Says which two ports are the pair. A setting — it moves nothing, exactly like set speed in Lesson 21. |
move [forward v] for (90) [degrees v] :: movement | Turns both motors, the same amount, starting and stopping together. |
set movement speed to (100) % :: movement | Sets the speed for the pair. Another setting. |
Because they would run one after the other. A [B v] run for (90) degrees block waits until B has finished before the next block starts — so C has not even begun moving yet. Two motor blocks in a row give you a left kick, then a right kick. That is a waddle.
One move block is a single instruction to a pair. Both start on the same tick and both stop on the same tick, and the Brick keeps them level while they run.
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.
The demo is a driving base, because that is the easiest place to see the effect — equal speeds go straight, unequal speeds curve towards the slower side. Your frog has exactly the same problem with different scenery: legs out of step means a frog that veers.
Two motors that must stay in step are a pair, not two motors. Tell the Brick that once, and it does the keeping-in-step for 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.
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: “Two motor blocks happen one after the other. One move block happens to both at once.”
Three parts with cables. There is no manual, so you tell us which motors these are — but you can already say something useful about them without knowing: there are two, and they are the same as each other.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and is the frog’s body — most of the weight the legs have to shift. |
| Two motors, one per back leg | Ports B and C. They must be the same kind as each other, or one leg will be stronger than the other and the frog will curve however carefully you program it. |
Step 3 is the one that bites. If the two motors face opposite ways, a move forward block will drive one leg back and the other forward. The fix is in the build: mount them so both legs sweep the same way, or flip which motor is B and which is C.
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 is the first time in ten lessons that the motor is not in port A — and there is a reason. B and C are the pair. The Movement blocks default to them, every driving base in this course uses them, and a motor pair anywhere else has to be declared.
| Part | Port | Why this one |
|---|---|---|
| Left leg motor | B | Left is B by convention across the whole course. Keep it, and another group’s program will run on your frog. |
| Right leg motor | C | Right is C. The pair is always B and C, in that order. |
| Sensors | none | The frog cannot see where it is going. |
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 if you can. This model travels, and a USB lead dragging behind it pulls on one side — which will look exactly like the legs being out of step. Do not spend the lesson debugging a cable.
Step 4 catches a swapped pair. On a frog, swapped legs are almost invisible until you notice it is turning the wrong way.
Six blocks. Two settings, then a loop of kick-and-return. Notice there is not a single [B v] run block in it — the whole program talks to the pair.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (100) % :: movement repeat (5) move [forward v] for (90) [degrees v] :: movement move [backward v] for (90) [degrees v] :: movement end
Walk it in the order the Brick runs it:
What success looks like: five hops in a reasonably straight line, both legs visibly moving as one, and a frog that ends up somewhere ahead of where it started. It will be a shuffle rather than a leap — that is the hardware, not your program.
If it turns instead of going forward, work through these in order: are both motors the same kind, are the legs mounted symmetrically, is a cable dragging on one side, and is one leg catching on the frame? Every one of those is a build problem, and none of them can be fixed in the program.
One change at a time, and predict before each run. Mark the start line with tape and measure how far five hops carry it.
Step 2 is the demonstration this lesson is built around. Same motors, same degrees, same speed, same number of hops — and a completely different animal, because four blocks in a column cannot do what one block does to a pair.
“At the same time” is something you have to ask for. A program does one thing after another unless you say otherwise.
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.
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 it hop straight. Mark a start line and a finish line a metre apart with a lane the width of your frog, and get it from one to the other without leaving the lane. Three runs, all three inside the lane, with no adjustment between them.
Find the best kick. Test at least four different kick angles, measuring the distance covered in five hops each time, and report which angle went furthest. Then explain why the biggest angle is not automatically the best one.
Make it turn on purpose. Using the Movement blocks, make the frog hop forward three times, turn to face a new direction, and hop three more. The turn must be deliberate and repeatable — the same amount every time — rather than the accidental veering you have been trying to eliminate.
Get it as close to a real jump as this hardware allows, and say honestly how close that is. The catalogue says these motors are not fast enough to lift the model off the ground. Your job is to find out how true that is. Change anything you like about the build and the program — leg length, kick angle, speed, where the weight sits, how the legs meet the ground — and get the frog to travel as far as possible in five hops. Plan on paper before you rebuild. A jump needs the legs to still be pushing when the body is already moving fast, so work out which change gives you a longer push rather than just a harder one. Two questions when you demonstrate it. Did any part of your frog leave the ground, and how do you know rather than think? And which of your changes made the biggest difference, with the measurements to back it up?