EV3 Robotics›Level 4 · WRO Prep›Lesson 38
Level 4 · Lesson 38 · EV3-L04-3860 minutes · Block 5 of 6 · Mat: WRO 2025 — The Future of Robots
Do two things at once — then make certain both have finished.
Every time your robot drives to a pad and then raises the module, it spends seconds doing one thing while it could be doing both. Today those seconds come back. And today you meet the bug that comes with them.
Two beams know nothing about each other. The main beam carries straight on the moment it starts the second one. It does not wait, it does not check, and it will happily begin the job at the pad while the arm is still moving.
Look at the bottom row. HOME to launch pad 1 at A is a decent drive, then A to pad 3 at B, then B to pad 5 at C, then the longer run out to the gantry at D.
Four travelling legs, and at the end of each one the module has to be in position. If it moves after the robot arrives, that is four waits. If it moves during the drive, that is none.
The crossing up to the satellite row at E is the best case of all, because it is the longest leg on the mat — there is easily enough travel time to reconfigure the module completely on the way.
Time one of those waits before you start. It is what today is worth.
On the EV3 canvas you make a second sequence beam by dragging a wire from a block’s sequence plug across to a new strip of blocks. From that point on, both strips run at the same time.
The main beam does not pause. It starts the helper and immediately continues, which is exactly what you want for the driving and exactly what causes the bug.
Rule one: one beam owns a motor. The main beam owns the drive motors on B and C. The helper beam owns the module on A. If both beams command the same motor, they fight, and the motor does neither thing properly. This rule has no exceptions.
Now the synch problem. The robot arrives at the pad; the arm is still travelling; the job starts anyway and misses. And the failure is intermittent — it works when the drive is slow, and fails when it is fast, because a slow drive gives the arm time by accident.
That is why this lesson exists before the milestone. An intermittent failure that depends on speed looks exactly like a mechanical fault or a bad gain, and a team that does not know about race conditions will spend lesson 39 retuning a follower that was never wrong.
The fix is a flag. EV3-G has no way to join two beams, so you build one:
Step one is the one that gets forgotten. If the flag is left true from last time, the wait passes instantly and the bug comes straight back — with the added cruelty that it now works on the first run of the day and fails on the second. That is the same stale variable problem as the menu in lesson 35 and the lists in lesson 37, wearing a third disguise.
Convert exactly one leg first. HOME to launch pad 1 at A:
One leg, then test it, then convert the rest. Converting the whole program at once and finding an intermittent fault leaves you with nothing to compare against.
Where not to use this. Never run the menu in parallel with anything — the choice must be finished before anything moves. Never put a line follower in a helper beam; it needs the drive motors, which belong to the main beam. Parallelism here is for module movement during travel, and very little else.
A wait that is never actually needed proves nothing, because the arm happened to finish first. To know the flag works, make the arm slow on purpose.
Drop the module motor’s power right down, so it takes clearly longer than the drive. Run the leg.
Then put the power back and confirm the wait now passes without a visible pause, which is what it should look like when everything is working: the arm finishes during the drive and the robot never stops.
Add one safety net while you are here. A helper beam that jams leaves the main beam waiting forever, and a robot frozen mid-round scores nothing. Set the wait to give up after a couple of seconds and carry on — a mission attempted with a half-raised arm may still score, and a robot standing still definitely will not.
Time the converted leg five times, and compare against the same leg before conversion. Five, not one — an intermittent fault will not show up in one run, and this is exactly the kind of bug that hides.
Three columns:
If the third column has a cross in it, stop and fix the synch before converting anything else. A leg that is half a second faster and occasionally misses the pad is a loss, not a gain — that is lesson 31’s reliability arithmetic again, and it has not stopped being true.
Convert the remaining legs the same way, one at a time, testing each before moving on.
Then run the full sequence from the menu — HOME, the pad, the gantry at D, back to HOME — five times, with the log from lesson 37 running.
All five must complete and the logs must match. Compare the total run time against your Block 4 figure: the difference is what parallelism bought, and it should be a second or more per module movement you hid inside a drive.
Today’s entry:
Three lessons, one bug. The stale menu variable, the log that kept last round’s stops, and the flag left true from the previous run are the same mistake three times: state that outlives the run that made it. Initialise everything at the top. Lesson 39 assembles all of it, and that is where it would bite hardest.
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 2025 RoboMission Elementary — The Future of Robots · official WRO game mat, 2362 × 1143 mm
The challenges name these places rather than distances, so the same challenge works on any mat:
Switch mats above and every route below is redrawn on the mat you chose.
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.
Convert ONE leg to run the module and the drive at once. Two rules, both absolute: one beam owns a motor — main beam drives B and C, helper owns A — and to wait for a beam you use a flag, because EV3-G has no join. Set the flag false BEFORE starting the helper.
Prove the wait actually works by turning the module motor's power right down so the arm is slower than the drive. The robot should arrive and visibly wait. If it starts the job immediately, the wait is not wired to the flag or the flag was left true from last time.
Time the converted leg five times against the same leg before conversion, with a third column for whether the job succeeded every time. A leg half a second faster that occasionally misses is a loss — lesson 31's arithmetic has not stopped being true. Then convert the remaining legs one at a time.
Run the full pad sequence from the menu five times with logging, and compare the total against your Block 4 figure — the difference is what hiding module movement inside a drive bought you. Add a timeout to the wait as well: a jammed helper leaves the main beam waiting forever, and a robot standing still scores nothing.