EV3 Robotics›Level 1 · Beginner›Lesson 29
Level 1 · Lesson 29 · EV3-L01-2960 minutes · Ages 9–16 · Model: Tricycle
The Tricycle: two driven wheels at the back, one wheel at the front, and a motor for each rear wheel. It is the first model since Lesson 1 that genuinely drives around a room.
And it has no steering wheel. There is no servo, no rack, no linkage — nothing that points the front wheel anywhere. So how does it turn?
By running one rear wheel faster than the other. That is the whole mechanism, it is how almost every robot you will ever build steers, and today you learn to control it as a number rather than a guess.
The trishaw — the beca in Melaka and Penang, and its cousins all across South and Southeast Asia. Three wheels, a rider, and passengers. Still working, still everywhere.
Three wheels always sit flat. Three points define a plane, so a tricycle never rocks on an uneven road the way a four-wheeled cart does — which is worth a lot on a street that has never been level.
A trishaw steers with handlebars, turning the front wheel. Your robot cannot. But watch what happens when a trishaw turns: the outside rear wheel travels further than the inside one, because it is going round a bigger circle. Every turn is one wheel outrunning the other — the trishaw just gets there by pointing the front, and your robot gets there by driving the back.
A robot that can only go straight is a robot that has to be picked up and re-aimed every time it needs to change direction. Useless on any course, and useless for anything that has to find its way.
Turning is not a separate skill from driving. It is driving, with the two wheels doing different amounts of it.
One block, two numbers: the speed of the left wheel and the speed of the right. The difference between them is the steering.
move for (1) [rotations v] at (50) (50) % speed :: movement
| Left / right | What the robot does |
|---|---|
| 50 / 50 | Straight ahead. Both wheels travel the same distance. |
| 50 / 25 | A gentle curve to the right — towards the slower wheel. |
| 50 / 0 | A tight turn about the stopped wheel, which stays where it is and acts as the pivot. |
| 50 / −50 | A spin on the spot. The wheels go opposite ways and the robot turns without going anywhere. |
Read that table as one idea rather than four cases. The robot always curves towards the slower wheel, and the bigger the gap between the two numbers, the tighter the curve. Straight is not a special mode — it is just the case where the gap happens to be zero.
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.
Drag the two numbers in the lab and watch the trail. Nothing in there is a “turn” command; there is only ever a left speed and a right speed.
A note about Lesson 25. On the Toddle Bot, two different speeds would have broken the model, because its motors were joined by one axle. Here the two motors drive separate wheels with the floor between them, so disagreeing is safe — the wheels just travel different distances. Same blocks, opposite advice, and the difference is in the build.
The robot curves towards the slower wheel. Everything else about steering follows from that one sentence.
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.
Say this back before moving on: “It turns towards whichever wheel is going slower.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and rides on the chassis. Where its weight sits decides how much grip each wheel gets. |
| Large Motor ×2 | One per rear wheel, ports B and C. Separate wheels, so they are allowed to disagree. |
| The front wheel (no cable) | Not steered and not really driven — it goes where the back end sends it. Check it rolls and swivels freely. |
A tricycle that will not drive straight is nearly always a build problem, not a program one.
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 rear motor | B | B is left, always. Today this matters more than it ever has: the first number in the block is B, so if B is on the right your robot will turn the wrong way every time. |
| Right rear motor | C | C is right, and it is the second number in the block. |
| Sensors | none | The tricycle drives blind. Everything it does, you planned in advance. |
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, if you possibly can. A USB cable on a driving robot is a rope tied to one side of it: the tricycle will curve towards the cable and you will spend the lesson trying to correct a steering fault you did not write.
Five blocks: straight, curve, straight. Watch the numbers rather than the block names — they are the same block three times.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement move for (3) [rotations v] at (40) (40) % speed :: movement move for (2) [rotations v] at (40) (10) % speed :: movement move for (3) [rotations v] at (40) (40) % speed :: movement
Walk it in the order the Brick runs it:
What success looks like: a clean straight run, a smooth curve to the right, and another straight — a path shaped like a wide letter L drawn with a curve at the corner.
If it curves the wrong way, your B and C are swapped. Go back to section 8 rather than changing the numbers — swapping the numbers hides the fault instead of fixing it, and every program you write afterwards will be mirrored too.
One change at a time, and predict before each run — and today, predict which way it will go before you predict how far.
Step 5 is the one worth keeping. Forward, spin, forward is how almost every robot on a competition table gets from one place to another — and it is easier to plan than a curve, because a spin does not move the robot anywhere while it happens.
Curves are pretty. Straights and spins are predictable. On a course with things to hit, predictable wins.
This model drives, so its challenges are run on a mat. Mats differ between branches — check you are looking at the one in your room.
WRO 2026 RoboMission Elementary — Robot Rockstars · official WRO game mat, 2362 × 1143 mm
The challenges name these places rather than distances, so the same challenge works on any mat:
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.
Drive from the start position to a station your teacher names on the mat, and stop with the whole tricycle inside it. Straights and curves only. Work out your speeds by testing rather than guessing, then prove it with three runs that all finish inside the station.
Reach a station that is not in a straight line from the start — one that needs a genuine change of direction. Then do it a second way: once using a curve, and once using a straight, a spin on the spot, and another straight. Say which was easier to get right, and why.
Make a repeatable turn. Find the numbers that spin your tricycle exactly a quarter turn on the spot, and prove it by driving a square: four straights and four quarter turns, finishing facing the way it started. Report how far off it ends up and what you think caused the drift.
Drive a route somebody else chooses, first time. Your teacher will name three stations on the mat in an order you have not practised. Your tricycle must visit them in that order without being picked up, repositioned or nudged, starting from HOME. Plan on paper before you drive. Work out your route as a list of straights and turns first, and note beside each one the numbers you will use. Programming a route you have not planned is how robots end up in the wrong half of the mat. Two questions when you demonstrate it. Which wheel is slower during your turn, and how does that match the direction it goes? And where does your error build up most — in the straights or the turns — and what is your evidence?
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.