EV3 Robotics›Level 1 · Beginner›Lesson 8
Level 1 · Lesson 8 · EV3-L01-0860 minutes · Ages 9–16 · Model: Gear Bot
The Gear Bot: a LEGO Official driving base built so that its gear train can be taken apart and rebuilt. It exists to be changed.
You have been saying “speed” since Lesson 3, and you have always meant a number between 0 and 100 in a block. That number is not a speed. It is a setting — a request for how hard the motor should try.
Today you find out how fast the robot actually goes, in centimetres every second, measured with a tape and a clock. And then you change the gears and watch the real number move.
The dial in front of every driver. It does not say “70 %” — it says kilometres per hour, a distance and a time joined together.
A speed is always two measurements divided: how far, and how long it took.
Speed = distance ÷ time. Travel 90 centimetres in 3 seconds and you were doing 30 centimetres per second. It works at any scale — the same arithmetic gives you the reading on a lorry’s dashboard and the reading on your Gear Bot.
The accelerator pedal is not a speed either. It is a request, exactly like your speed block, and how fast the car actually goes depends on the hill, the load and the gear it is in.
Two robots can both be set to 50 % and travel at completely different speeds — different wheels, different gears, different battery charge. So “50 %” tells another group nothing at all about your robot.
“Thirty-two centimetres per second” tells them everything. It is a fact about the machine rather than a setting inside it, and it can be compared, predicted from, and checked.
A percentage is what you asked for. A speed in centimetres per second is what you got.
Two numbers and one division. The robot can measure the time for you; the distance is yours to measure with a tape.
| What you need | How you get it |
|---|---|
| Distance, in centimetres | A tape measure on the floor. Mark the start, mark where it stopped, measure between them. |
| Time, in seconds | The Brick’s own clock, from Lesson 20: reset timer before the run and read timer after it. |
| Speed, in cm per second | Divide the first by the second. On paper, not in a block. |
You are doing the division, not the robot. EV3 can do arithmetic, but the blocks for it belong to a later level. That is no loss today: writing the sum out yourself is what makes it stick, and a calculator is fine.
Because the speed you measure is not fixed. It depends on three things, and this model lets you change all of them:
Change the middle one and the same program, at the same percentage, gives you a different measured speed. That is the experiment.
Measure it before you argue about it. Distance divided by time settles what an opinion cannot.
Two meshed gears are a bargain. Whatever one of them gains in turns it loses in force, and whatever it loses in turns it gains in force. There is no arrangement of gears that gives you more of both, and no amount of building will find one.
Count the teeth on the gear you are turning (the driver) and the teeth on the one being turned (the follower). That is the whole calculation:
turns out = turns in × driver teeth ÷ follower teeth
An 8-tooth gear driving a 24 gives ⅓ of a turn out for every turn in — and three times the turning force. Turn the pair round and you get three turns out and a third of the force. Count the turns yourself below.
The number of teeth is the whole story. 8 teeth driving 24 means 8 ÷ 24 of a turn out for every turn in — and the force changes by exactly the opposite amount.
| Arrangement | Turns | Force | What it is for |
|---|---|---|---|
| Gearing down — small driving large | fewer | more | winches, lifts, robot arms, anything that has to move a weight |
| Gearing up — large driving small | more | less | fans, spinners, launchers, wheels on a light fast robot |
| 1 : 1 — same size | same | same | moving the drive to a different axle, or fixing a direction |
The names are worth getting right because they are backwards from what people expect: gearing down makes the output slower, not smaller, and it is the setting that makes a weak motor able to lift things.
Put several pairs in a row and the ratios multiply. Two 1:3 reductions in series give 1:9 — which is how a Medium Motor ends up able to raise something it could never shift directly. This is also how a gearbox with a sensible number of parts reaches a ratio that a single pair never could: a 40-tooth gear driven by an 8 is 1:5, and doing it twice is 1:25.
Only the first and last gear affect the ratio. Anything in the middle passes the motion along and changes nothing but the direction — which is a whole idea of its own, in Changing the direction of a turn.
Every mesh loses a little to friction, so a long train is less efficient than a short one. Gearing down far enough to lift a heavy load also makes the mechanism slow, and slow is not always acceptable. And a gear train that is geared down hard is very hard to turn backwards by hand, which is either a useful brake or a nuisance depending on what you are building.
A bicycle is the same idea with a chain instead of teeth in mesh: the low gear that gets you up a hill is turning the back wheel slowly and pushing hard, and the high gear you use going downhill does the opposite. Cars, drills, cranes and clocks are all making the same trade.
Speed is set separately from movement. You tell the motor how fast it should go, and then you tell it to go — two blocks, in that order.
| Block | What it does |
|---|---|
[A v] set speed to (25) % :: motors | Sets the speed for this motor from now on. Nothing moves — it only changes what the next movement will do. |
[A v] run [clockwise v] for (2) [rotations v] :: motors | Now moves, at whatever speed was last set. |
when program starts :: events hat [A v] set speed to (25) % :: motors [A v] run [clockwise v] for (2) [rotations v] :: motors
Swap those two blocks round and the program still contains a speed of 25 % — it just never gets used. Both shafts below are asked for exactly 2 rotations; watch how long each one takes.
speed first — works
speed last — does nothing
Both shafts turn exactly 2 rotations. Only the time they take is different — and the right-hand program never gets the slow movement it was written to have.
The right-hand movement is over before the left is a third of the way round, because it ran at the default speed. Its set speed to () block does run — you can see it light up — but by then the movement it was meant to slow down has already happened. A speed block only ever affects the movements after it. This catches people out constantly.
A high speed is not a better program. Slow movements are gentler on the gears, easier to watch and debug, and look more like the real machine — a barrier that snaps up in a fraction of a second reads as broken rather than fast.
A wait pauses for a length of time. The timer is different: it runs in the background and can be read at any moment, so the robot can know how long something has taken while it is still happening.
| Block | What it does |
|---|---|
(timer) | Reports the seconds since the timer was last reset. |
reset timer | Sets it back to zero, so the next reading counts from here. |
The most valuable use of a timer is escaping a wait that might never end. A robot told to drive until it sees a wall will drive for ever if the wall is not there. Combined with a timer, it can give up:
Repeat until the wall is close or five seconds have passed. That one change turns a program that can hang into one that always finishes. Both robots below are looking for a wall that is not there.
no way out
with a timeout
The sensor is not faulty and the program is not wrong. There is simply no wall, and only one of these two programs has a way of noticing that.
The left-hand robot is not broken, and neither is its sensor. Its condition is simply one that will never come true, so the program sits on that block for ever — with nothing on the Brick to say so. The right-hand program asks the same question with an escape route bolted on, and finishes every time.
Real systems time themselves out constantly — a lift that cannot close its doors eventually gives up and beeps rather than trying for ever. A robot with no timeout simply stops responding, and there is nothing on screen to say why.
Say this back before moving on: “Speed is distance divided by time.”
The catalogue says this model has one Large Motor. It has two. The manual’s last step shows two cables labelled B and C. Trust the manual — and get into the habit, because this is the second row in nine lessons whose parts list is wrong.
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and times the run. |
| Large Motor ×2 | Ports B and C, driving through the gear train. |
| The gear train (no cable) | The part this model exists for. Built to be taken off and rebuilt. |
Three numbers, and you will use all three today.
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 drive motor | B | The manual itself labels the cables B and C — follow it. |
| Right drive motor | C | The standard pair, as on every driving model. |
| The clock | none | The timer is inside the Brick and has been running since it was switched on. 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.
Bluetooth, because a cable changes the answer. You are measuring a speed to the nearest centimetre per second, and a USB lead dragging behind the robot slows it down by a real, measurable amount.
Six blocks. Start the clock, drive a fixed number of rotations, and put the elapsed time on the screen. You supply the tape measure.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (50) % :: movement reset timer move [forward v] for (5) [rotations v] :: movement write (timer) at line (1) :: display
Walk it in the order the Brick runs it:
What success looks like: a straight run, a sensible time on the screen, and a speed you can state in cm/s. Write it on the board next to the other groups’ — they will not all be the same, and that is the interesting part.
Keep a table: what you changed, the distance, the time, and the speed you worked out. Three runs per setting, and use the middle one.
Step 5 brings the whole run of gearing lessons together. The Gear Shooter (5) traded force for speed, the EV3 Fan (18) hit the limit of what a program could do, and here you can finally put a number on both sides of the trade.
Gearing does not create speed. It moves it from one column to the other, and now you can measure both columns.
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.
Measure your robot's speed in centimetres per second, at three different speed settings, three runs each. Report the nine measurements and the three speeds you calculated. Then answer one question: is a setting of 100 twice the real speed of a setting of 50?
Predict before you measure. Using your gear ratio and your wheel size, work out on paper how far the robot should travel for eight motor rotations. Write the prediction down, then run it and measure. Report both numbers and explain any difference.
Change the gearing and measure again. Rebuild the gear train for more speed, recount the ratio, and measure the new speed with the identical program. Report the old ratio, the new ratio, the old speed and the new speed — and say whether the speed changed by the amount the ratios predicted.
Build the fastest Gear Bot in the room, then prove it can still work. Two parts, and they pull against each other. First, gear your robot for the highest measured speed you can achieve in centimetres per second, and prove it with measurements rather than a race. Then make it climb a gentle slope. If your fastest gearing cannot, gear it back until it can — and report both the speed you lost and the slope you gained. Plan on paper before you rebuild. Predict what each gearing change will do to the measured speed, then check whether you were right. Two questions when you demonstrate it. What is your robot's speed, in units, and how do you know? And what exactly did you trade away to get it?