Challenge 1
Cross a bump and stay straight. Lay an obstacle across the route, drive over it, and finish within a hand's width of the line you started on. Three runs, all three inside that width, with the suspension doing the work rather than luck.
EV3 Robotics›Level 1 · Beginner›Lesson 31
Level 1 · Lesson 31 · EV3-L01-3160 minutes · Ages 9–16 · Model: Shock Absorber Car
The Shock Absorber Car: a four-wheeled car driven by two Large Motors, with each wheel hung on its own rubber band so it can move up and down independently of the body.
The Tricycle in Lesson 29 had its wheels bolted straight to the chassis. Fine on a table. Put it on anything bumpy and it hops, and a hopping wheel is a wheel that is not driving.
This car has suspension, and today you find out what that is actually for. It is not about comfort — there is nobody inside. It is about keeping all four wheels touching the floor.
Under every car on the road. A coil spring at each wheel, and a damper inside or beside it, letting the wheel move up and down while the body stays roughly level. Malaysian roads being what they are after a monsoon, they get a workout.

Here is the bit that surprises people. Suspension is not mainly there to stop the passengers being shaken. It is there to stop the wheels leaving the road.
A wheel bolted rigidly to a car hits a bump and the whole car is thrown upwards. For the moment it is airborne, that tyre is touching nothing — so it cannot drive, cannot brake and cannot steer. Springs let the wheel jump on its own while the heavy body carries on, and the wheel is pushed back down onto the road almost at once.
Grip is not something a car has. It is something a car has while the tyre is on the ground, and only then. Everything else — the engine, the brakes, the steering — is useless in the fraction of a second a wheel is in the air.
A wheel off the ground does nothing at all. Suspension exists to make that fraction of a second as short as possible.
A rubber band between the wheel and the body does two jobs at once: it lets the wheel move, and it pushes the wheel back.
Your rubber bands are doing exactly what the coil springs in the photograph do. They stretch as the wheel rides up, store that energy — the same elastic energy you measured on the Elastic Car in Lesson 14 — and give it back by pulling the wheel down again.
There is a real difference worth naming. A car has a damper as well as a spring, which soaks up the energy so the car does not bounce for the rest of the journey. Your model has springs and no dampers, so it will bounce a few times after each bump. That is not a fault in your build; it is a part you have not got.
Springs are not for the passengers. They are for the tyres — and a tyre that stays down is a tyre that still works.
A stretched rubber band is a store. Pull it and you put energy in; let go and it gives the energy back. Nothing about that is obvious from looking at the band, and two things about it are genuinely surprising.
While it is stretched and held, the energy is not doing anything — it is potential energy, stored in the shape of the material. Release it and that becomes kinetic energy: the energy of something moving. A pull-back car is a machine for making that swap at a moment of your choosing.
The same store shows up all over a LEGO set:
This is the first surprise. Energy stored in a spring or a band goes as the square of how far it is stretched — pull back twice as far and you have stored four times as much, not twice.
Which sounds like excellent news, and leads directly to the second surprise: the car does not go four times as far. Find out where the two part company.
Drag the car back, or use the arrow keys. Watch the two curves come apart.
Every bit of the extra stretch is still turning into distance. Double this stretch and you store four times the energy — energy goes as the SQUARE of how far you pull.
Find the place where the green curve stops rising as fast as the orange one. That is the setting worth building for — and it is a number you measure, not one you can reason out.
Past a certain stretch the wheels can no longer grip hard enough to turn all that force into movement, so they spin. The energy still leaves the band — it goes into noise, heat and rubber marks on the table instead of into distance.
That ceiling is a property of your car on that surface: its weight, its tyres, how much of it is over the driven wheels. It is not something to look up. It is something to measure, and finding it is one of the most satisfying things a mechanical build has to offer.
Three things move the ceiling up, and all of them are build changes rather than bigger bands: more weight over the driving wheels, grippier tyres, and gearing the launch down so the same energy arrives as more force over more time.
Change one thing at a time and run each setting three times, not once. Pull back 5 cm, then 10, then 15, measuring from the same starting line every time and recording every run. Three readings tell you whether a difference is real; one reading tells you nothing at all.
That is the discipline the whole of Mechanisms without motors is built around, and it is the same habit that makes debugging a program work.
Bows, clockwork, suspension springs and the recoil mechanism in a car door all store energy and give it back on demand. Storing energy slowly and releasing it quickly is how a small muscle — or a small motor — produces a large, brief force.
Some models have no motors and no sensors at all. They are not lesser lessons — they are where the physics lives. A build that stores energy, changes a force, or turns one kind of motion into another explains why the powered models later need the gearing and the speeds they do.
Gears, pulleys and levers look like three different topics and are three shapes of the same deal: whatever you gain in force, you pay for in distance. Halve the effort and you move twice as far; move half as far and you need twice the effort. No arrangement of anything gives you both, and recognising that saves a great deal of time hunting for one.
What a mechanism actually does is let you spend the same effort in a form you can manage — a little at a time instead of all at once, or all at once instead of a little at a time.
| Tutorial | The question it answers |
|---|---|
| Gearing up and gearing down | How do I trade turns for force? |
| Changing the direction of a turn | Why is it going backwards, and how do I drive an axle at 90°? |
| Pulley systems | How does a rope let a small motor lift a big load? |
| Levers — effort, load and pivot | Where should the pivot go? |
| Elastic and stored energy | How much further does pulling back twice as far actually get me? |
| Scissor mechanisms | How do I make something extend a long way — and why won’t it start? |
| Oscillatory motion | How do I turn going round into going back and forth? |
| Centre of gravity | Why does it keep falling over? |
| Biomimetic mechanisms | How does a machine walk without ever being told to? |
Friction is what makes wheels grip and also what wastes effort. Every mesh, pin and rope turn loses a little to it, so a mechanism with more parts delivers less than the arithmetic promises. A build that binds — that is stiff to move by hand — is losing far more than that, and no amount of extra motor power fixes a mechanism that is rubbing.
Before measuring anything, turn the mechanism by hand. It should move smoothly and coast a little. If it does not, fix the build first; numbers taken off a binding mechanism describe the binding, not the idea you were trying to test.
Since there is nothing to program, the work is measuring. Change one thing, keep everything else the same, and record what happened — pull the car back 5 cm, then 10, then 15, and measure how far each one travels. Three readings at each setting, not one, because a single run is not evidence.
That is genuinely how engineers test, and it is the same discipline that makes debugging a program work: change one thing at a time.
Say this back before moving on: “A wheel in the air is not driving. Springs push it back down.”
| Part | What it is doing here |
|---|---|
| EV3 Intelligent Brick | Runs the program and is the car’s body — the weight the springs are holding up. |
| Large Motor ×2 | One drives the front pair, one the rear, ports B and C. They are mounted facing each other, which matters below. |
| Four rubber bands (no cable) | The springs, one per wheel. The manual’s own photo points at where they go. |
Pick the car up and look at the two motors. They are mounted head-to-head, so “clockwise” on one of them and “clockwise” on the other send the car in opposite directions.
This is how nearly every driving robot is built, and the move blocks already know about it — that is part of what “a pair” means. Use them and it just works. Use two separate run blocks and you must reverse one of them yourself, or the wheels will fight.
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 |
|---|---|---|
| One Large Motor (front pair) | B | B and C are the pair. On this car they are front and rear rather than left and right, but the block does not care — it just drives both together. |
| Other Large Motor (rear pair) | C | Same reason. Write down which is which. |
| Sensors | none | The car cannot feel a bump. You are the one who has to notice. |
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 the same reason as the Tricycle. A trailing cable pulls one side of a driving car — and today you are measuring how straight it stays, so a cable would corrupt the very thing you are trying to measure.
Do that check in the air, not on the floor. Wheels fighting each other on a table will drag the tyres and can pop a suspension arm.
Six blocks: out, pause, back. Deliberately simple, because the programming is not what this lesson is testing — the driving over a bump is.
when program starts :: events hat set movement motors to [B v] and [C v] :: movement set movement speed to (60) % :: movement move [forward v] for (5) [rotations v] :: movement wait (1) seconds move [backward v] for (5) [rotations v] :: movement
Walk it in the order the Brick runs it:
What success looks like: a straight run out and back on flat floor, with the body sitting level and all four wheels down throughout.
If the car judders and goes nowhere, the two ends are fighting. Check you are using the move blocks and not two separate motor blocks — that is the mounting problem from section 5, and the Movement block is the fix.
This is an experiment, so it has rules. Change one thing, run it three times, use the middle result. Predict before each set.
Set up a bump: a ruler or a pencil taped across the middle of the run, and a tape start line so every run begins in the same place.
Step 5 usually surprises people. Stiffer is not better. A very stiff spring behaves more and more like no spring at all — the wheel cannot move up easily, so the whole car gets thrown again.
Too soft and the car wallows. Too stiff and it may as well be bolted together. The right answer is in the middle, and you find it by measuring.
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.

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.
Cross a bump and stay straight. Lay an obstacle across the route, drive over it, and finish within a hand's width of the line you started on. Three runs, all three inside that width, with the suspension doing the work rather than luck.
Measure what the springs are worth. Run the same course over the same bump with the bands on and with the bands off, three runs each, measuring how far sideways the car ends up. Report all six numbers and the difference between the two averages.
Find the best stiffness. Try one band per corner, then two, then two on one axle and one on the other. Test each over the bump three times. Report which was best and explain why stiffer stopped helping at some point.
Build a car that can be trusted on a rough route. Your car must drive a route on the mat that includes at least two obstacles to cross, arrive at a station your teacher names, and finish inside it. It has to work on the rough route as reliably as it does on a flat one — that is the whole test. Plan on paper before you build. Decide what you are going to change about the suspension and why, and predict what difference it will make, before you touch the model. Two questions when you demonstrate it. What does suspension actually do for a robot that has no passengers? And which part of your route costs you the most accuracy, and what did you change to fix it?