EV3 Robotics›Level 1 · Beginner›Lesson 42
Level 1 · Lesson 42 · EV3-L01-4260 minutes · Ages 9–16 · Model: EV3 Ricksaw
The Rickshaw: a three-wheeled passenger cart driven by a single Large Motor, with a screen that says where it is going and a beep when it arrives.
A rickshaw driver does not think in seconds. Nobody has ever asked to be taken “forward for four seconds”. They ask to be taken to the end of the road — a distance.
Your robot has been measuring in seconds for most of Level 1 without you noticing the difference. Today you find out what that has been costing you.
The beca — the trishaw — still working in Melaka and Penang, decorated to within an inch of its life and usually playing music. Three wheels, a rider pedalling, and one or two passengers sitting up front.
A trishaw is geared low — the pedals turn a lot for a little movement. That makes it slow, and it makes it able to start from a standstill with two passengers and a hill in front of it.
It also means the rider can tell you exactly how far they have gone without looking up. Every turn of the pedals is the same distance along the road — a full turn might be two metres, whether the rider is fresh or exhausted, whether the load is one passenger or two. Tiredness changes how long the journey takes. It does not change how far one pedal stroke goes.
Imagine a driver who measured in time instead: “the museum is four minutes away”. Fine on an empty road at midday. Useless in traffic, useless uphill, useless with a heavy passenger — and they would put you down in a different place every single trip.
Time tells you how long you tried. Rotations tell you how far you got.
One block, one little dropdown, three completely different promises.
[A v] run for (3) [rotations v] at (40) % speed :: motors
| Unit | What the Brick actually promises | Reach for it when… |
|---|---|---|
| seconds | “I will keep the power on for this long.” It makes no promise about distance at all. | The duration is the point — a fan that runs for a minute, a light that stays on. |
| rotations | “I will turn the shaft round this many times, however long that takes.” | Distance matters. This is the everyday choice for anything that drives. |
| degrees | The same promise as rotations, in smaller pieces. 360 degrees is one rotation. | You need part of a turn — a quarter, a third, an arm lifted to an angle. |
Rotations and degrees are the same unit wearing different clothes. The real split is between them and seconds, because seconds is the only one that is not measuring the shaft at all.
Set a motor to run for 3 seconds at 40% and it does not always travel the same distance:
Set it to 3 rotations and none of that matters. A heavy rickshaw takes longer to do 3 rotations, and then it has still done 3 rotations. The Brick counts the shaft going round and does not stop until the count is reached.
There are two ways to tell an EV3 motor how much to move: give it a length of time, or give it an amount of turn. Only the second one is repeatable, and that difference decides whether a machine works reliably or only sometimes.
| Block | What it does |
|---|---|
[A v] run [clockwise v] for (1) [rotations v] :: motors | One full turn of the motor shaft, then stop. The program waits for it. |
[A v] run [clockwise v] for (180) [degrees v] :: motors | Half a turn. 360 degrees is one rotation. |
The counters below tick up in step with the shaft, so you can watch a rotation being counted rather than take it on trust.
the same movement, written in degrees
The two motor read-outs are the same measurement — 1 rotation is 360°. Use whichever makes the number easier to read.
Notice that the two motor counters finish together: 2.00 rotations and 720° are the same instant, because they are the same measurement in different units. So pick whichever makes the number easier to read. A winch that needs eight full turns is clearest in rotations. A gate that lifts a quarter turn is clearest in degrees — 90 rather than 0.25.
The third counter is the one that catches people out. The block counts turns of the motor, not of the thing it drives — and the gear in the demo is three times the size, so two motor rotations move it only 0.67 of a turn. Ask for two rotations and the mechanism does not move two rotations’ worth unless the gearing is one to one.
That is why a number that works on one build has to be retuned when the gearing changes — the program is right, the mechanism is different.
A printer feeds paper an exact distance; a lift stops level with the floor; a robot arm returns to the same place a thousand times. None of that is possible by timing a motor — they all count turns.
Seconds measure your effort. Rotations measure the result. Level 2 is about results.
Everything so far has been relative: move 90 degrees from wherever you are now. Sometimes what you actually want is absolute: go to the 90-degree position, whatever position you happen to be in at the moment.
Both pointers below do the same job over and over: swing out a quarter turn, then come home. The only difference is the block that brings them back. Watch one trip and they look identical — so let it run for several.
relative — by an amount
absolute — to a place
Let it loop. Nothing about the left program is wrong — it is just that every trip starts from wherever the last one finished, so a small error is never corrected, only added to.
A pointer moved relatively slowly wanders: each movement starts from wherever the last one finished, so any small error is carried forward and added to. Each orange dash is a trip that called a slightly different place “home”. Nothing about that program is wrong — it is simply that a relative move has no idea where it is supposed to end up.
An absolute movement has no memory of the error. Told to go to position 0, it goes to position 0 — the same place every time, however wrong it was beforehand. That makes it the right tool for a home position: the known place a mechanism returns to before it starts work.
This is possible because an EV3 motor counts its own turning all the time. Its position can be read back, and can be reset to zero — which is how you tell the motor that here is what you mean by zero, usually at the start of a program with the mechanism held at its resting place.
A clock hand returns to twelve; a car’s steering returns to centre; a 3D printer homes its head before every print. All of them go to a position rather than moving by an amount.
Say this back before moving on: “Seconds is how long. Rotations is how far.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Rides on the cart and counts the motor’s rotations. That counting is what makes today’s program reliable. |
| Large Motor — the drive | One motor, driving the rear axle. Because there is only one, the rickshaw goes where its wheels are pointed and cannot steer itself. |
| Ultrasonic Sensor | Faces forward. Today it is only used as a safety stop at the end of the run — you will do far more with it in Lesson 9. |
| The Brick screen and speaker | The rickshaw’s way of telling a passenger what is happening. Not decoration — it is how you check the program reached the end. |
One rotation of the motor moves the rickshaw a fixed distance. Find out what that distance is and rotations stop being an abstract number.
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 |
|---|---|---|
| Drive motor (Large) | A | A single drive motor is a job, not a steering pair — so it takes a Motor block on A rather than the Movement blocks you would use for a two-motor base. |
| Ultrasonic Sensor | 4 | Ultrasonic is always port 4 in this course, in every lesson, every level. |
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 for this one. A USB cable on a driving model drags, and drag is exactly the variable this lesson is trying to prove does not matter. Prove it without a rope attached.
A rickshaw journey: announce it, drive a measured distance, arrive, say so.
when program starts :: events hat clear display :: display write [Jalan!] at line (1) :: display [A v] run for (5) [rotations v] at (40) % speed :: motors play beep (60) for (0.3) seconds :: sound write [Sampai] at line (3) :: display
What success looks like: mark the start and finish with two pieces of tape. Run it three times from the same start line and it should stop at the same finish line every time.
If it stops in a different place each run, the wheels are slipping. The motor has honestly turned five times; the wheel just did not take the rickshaw with it. Rotations measure the shaft, and they cannot see a skid.
The point of today is a comparison, so run these in pairs and mark where the rickshaw stops each time with a strip of tape. Two lines of tape close together is a reliable robot; two far apart is not.
[4 v] wait until distance [< v] (15) [cm v] before the motor block, and hold your hand in front of the sensor. The rickshaw waits for a clear road, then drives its five rotations.Step 3 is the evidence. The two rotation marks should be close enough to touch, and the two seconds marks should not be — same robot, same floor, same battery, and only the dropdown changed.
If your robot has to end up somewhere, never measure it in seconds.
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.
Stop on the line, three times running. Put a strip of tape on the floor, choose a starting point, and make the rickshaw stop with its front wheel on the tape. Then do it twice more from the same start without changing the program. All three stops must be within a tyre's width of each other.
Run two different fares. The rickshaw must make a short trip and a long trip, one after the other, announcing each one on the screen before it sets off and beeping when it arrives. The two distances must be visibly different and both must be repeatable.
Carry a passenger the same distance. Run your trip empty and mark where it stops. Load the seat with something heavy, run exactly the same program, and mark it again. The two marks must be close enough to touch. If they are not, the wheels are slipping — say what you did about it.
Turn your rickshaw into a machine that takes an order in centimetres. A passenger does not think in rotations. They say "take me forty centimetres down the road". Your machine has to do the conversion. Start from the measurement you took in section 5: one rotation moves the rickshaw a fixed number of centimetres. Build a small table on paper — 20 cm, 40 cm, 60 cm, 80 cm — and work out the rotations each one needs. Show your working. Then build the trips and prove the table. Mark each target distance on the floor with tape before you run it, so the machine is being tested against a prediction rather than being measured afterwards. Two questions when you present it. Which distance came out worst, and is the error a fixed amount every time or does it grow with the distance? And if somebody swapped your wheels for larger ones, exactly which number in your table would still be right and which would all be wrong?
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.