The Two-State Line Follower

The Colour Sensor

The Colour Sensor looks down at a surface and can answer three quite different questions: what colour is this?, how bright is this? and how light is the room? Choosing the wrong one is the usual reason a line-following robot refuses to work.

front

side

Blocks reference

([3 v] color :: sensors)

([3 v] reflected light intensity :: sensors)

<[3 v] is color [red v]? :: sensors>

([3 v] ambient light intensity :: sensors)

Which colour, exactly?

The sensor does not describe a colour — it picks one from a list of eight, and that list is the whole of what it can ever say:

Anything you put under it is forced into one of those eight. There is no orange and no purple: an orange brick comes back as red or as yellow, and often as red one moment and yellow the next as the robot creeps along. Light blue and grey are the other classic pair to avoid — grey is neither black nor white, so it flips between them.

This is why colour mode is a good fit for a task you control and a bad fit for one you do not. Sorting the LEGO bricks that come in the set works, because they are made in exactly these colours. Reading a printed sheet, a coloured tile from another set, or anything pastel is asking the sensor to answer a question it does not have a word for.

Two practical points follow from how it decides. It shines its own lamp and looks at how much red, green and blue comes back, so it must be close — about half a centimetre, and no more than a centimetre. Lift it and the answer decays to 0. And because it takes those three readings before it can answer, colour mode is the slowest thing this sensor does; a robot driving quickly can pass right over a small patch without ever reporting it.

When a colour must be recognised reliably, test it. Drive the robot slowly over the real surface with color shown on the screen and watch what it actually says — including what it says at the edges between two colours, which is where the wrong answers live.

Colour, or brightness?

Both questions are asked of the same surface at the same moment. Watch the two answers travel across a strip of colours and then over the edge of a black line.

Over the patches, both read-outs are useful. Over the edge of the line they part company: the colour name has only two answers to give and jumps between them, while the number slides smoothly from 88 down to 8. Every value in that slide tells you how far onto the line the sensor is — which is information the name simply does not carry.

• Use colour when the answer really is a name — sorting red bricks from blue ones, stopping on a green square.
• Use reflected light when the answer is a matter of degree — following the edge of a black line, where the useful readings are all the greys between black and white.

A line follower built on colour names only knows “black” or “not black”, so it can only lurch. Built on reflected light it can tell how far onto the line it has drifted, which is what makes smooth following possible.

The third mode: ambient light

The first two modes both switch the sensor’s own lamp on and measure what bounces back off the surface. Ambient light intensity does the opposite: the lamp goes off, and the sensor simply reports how much light is arriving from wherever — 0 in the dark, up to 100 in bright light.

That makes it the only one of the three that is not really about the floor. A number between 0 and 100 means very little on its own, so watch the same sensor sit through five different rooms — nothing underneath it changes at any point.

Those are the shape of the scale rather than exact figures, but the shape is the useful part: a lit room is nowhere near 100, and the top of the range is reserved for a light pointed straight at the sensor. Cover it with your hand and the number drops to near zero — which is the easiest way to check the sensor is doing what you think.

Point it at the ceiling and it tells you whether the room lights are on; point it forwards and a torch will spike the reading, which is a way of signalling to a robot without touching it.

Do not reach for it as a substitute for reflected light. Room light falling on a black line and on white paper is almost the same, so ambient mode can barely tell them apart — the reason reflected light works is precisely that the sensor brings its own light and measures how much of it survives.

It is also the mode most at the mercy of the room. A reading taken by a window in the morning will not match the same spot in the afternoon, so anything built on ambient light needs measuring on the day, in the place, with the lights as they will be.

Light and height matter

Even the two lamp-on modes are affected by room lighting — a reading taken by a sunny window differs from one taken in a corner. The sensor must also sit close to the surface and at a constant height, because lifting it changes the reading even though the surface has not changed.

Making a decision

Up to now a robot has been able to wait for a sensor. Deciding is different: the robot checks the sensor and does one thing or another depending on the answer — and then carries on either way.

Blocks reference

if <> then
end

if <> then
else
end

Deciding again and again

A decision made once, at the start, is almost never what you want. Here are two robots with the identical if-else, testing the identical sensor against the identical number — one inside a loop and one not.

Nothing is wrong with the right-hand program’s decision. It asked the question, got a truthful answer, and acted on it correctly. It simply never asked again, and the world moved on. Decisions belong inside a loop, so the robot keeps re-deciding as things change.

when program starts :: events hat
forever
  if <([4 v] distance in [cm v] :: sensors) < (15)> then
    stop moving :: movement
  else
    start moving [straight: 0] :: movement
  end
end

Four shapes, and how to choose

Once there is more than one question, decisions can be arranged in four ways. They look nearly identical stacked up in the editor, which is exactly why they get muddled — the thing that differs is not what the blocks say, it is which routes through them exist.

One question sorts them almost completely:

Separate ifs — independent questions

Each if is asked no matter what the others answered, so any number of them can fire on the same pass. That is the right shape when the conditions genuinely have nothing to do with each other.

forever
  if <[3 v] is ambient light intensity [< v] (20) %? :: sensors> then
    [A v] start motor [clockwise v] :: motors
  end
  if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
    [D v] start motor [clockwise v] :: motors
  end
end

if / else — one question, two answers

Exactly one branch runs, every time. Reach for this whenever the robot must do something either way — and in preference to two ifs testing opposite conditions, which is the same idea written twice and can drift apart.

Nested if — a follow-up question

Putting one if inside another means the inner question is only ever asked when the outer one is true. Use it when the second question is meaningless otherwise: there is no point asking which side an obstacle is on when there is no obstacle.

if <[4 v] is distance [< v] (15) [cm v]? :: sensors> then
  if <([2 v] angle :: sensors) < (0)> then
    start moving [right: 50] :: movement
  end
end

When not to nest. If you only want “both true” and nothing happens at the outer level, an and says it in one block and reads better:

if <<[4 v] is distance [< v] (15) [cm v]? :: sensors> and <([2 v] angle :: sensors) < (0)>> then
  start moving [right: 50] :: movement
end

Nesting earns its place when something happens at the outer level too, or when there is an else at each level and the two mean different things.

Chained if / else — one winner out of several

This is the shape for a list of cases where exactly one should win: colour bands, distance bands, speed ranges. EV3 Classroom has no else-if block, so you build a chain by putting the next if inside the else of the last one.

And here is why it matters, because this is the single commonest bug in this whole module. Three bands written as three separate ifs are each perfectly correct, and together they are wrong: a reading of 20 is under 30 and under 60 and under 90, so all three run and the last one to run is the one that sticks.

The rule to carry away: if the cases are meant to be exclusive, they must be made exclusive. Chaining does it by construction. Separate ifs only work if you are careful to write non-overlapping bands yourself — light < 30, 30 to 60, 60 and over — which is more to get right and easy to break later.

Why it matters

This is the point at which a machine stops following a script and starts responding. A thermostat, an automatic door, a robot vacuum — all of them are a decision inside a loop.

Repeating

Machines repeat. A wiper sweeps, a conveyor runs, a ride goes round — and none of that should mean copying the same blocks over and over. A loop says “do this again” once.

Blocks reference

repeat (10)
end

forever
end

repeat until <>
end

Forever really does mean forever

Anything placed after a forever loop will never run. Not “runs late” — never. Both programs below end with the same block: set the status light green.

The repeat loop counts its three passes, stops, and moves on to the block underneath, so its light turns green. The forever loop reaches the bottom of its own blocks and jumps straight back to the top, so the block underneath is never reached — however long you leave it. If a program seems to stop half way through, look for a forever loop above the blocks that are not happening.

Why a sensor program needs a loop at all

A program is a list, and the Brick works down it once. Every block runs, in order, and when the last one is done the program is over. That is fine for a list of instructions — drive, turn, beep, stop — because each is a thing you do once.

A sensor is not a thing you do once. Asking is 1 pressed? gives you an answer about this instant, and an instant later it may be wrong. Checking a sensor once tells you what the world was like at the moment the program started — which is almost never what you wanted to know.

So a program that has to react must ask again, and again, for as long as it is running. That is the whole job of the loop: not to repeat an action, but to keep the question being asked.

Read, decide, act — and then do it again

Wrap a sensor check and the motor it controls in a forever loop and you have built a closed-loop control system — the pattern behind every line follower, thermostat and cruise control:

1. Read the sensor.
2. Decide what that reading means.
3. Act on the motors.
4. Go back to 1 — immediately, thousands of times a minute.

It is called closed because the output feeds back round to the input: the motors move the robot, moving the robot changes what the sensor sees, and what the sensor sees changes the motors. Break the circle at any point and the robot stops responding.

when program starts :: events hat
forever
  if <[1 v] is pressed? :: sensors> then
    [A v] start motor [clockwise v] :: motors
  else
    [A v] stop motor :: motors
  end
end

Read it as a sentence and it is almost too simple to need explaining: for ever, if the button is pressed run the motor, otherwise stop it. The motor now follows the button for as long as the program is running.

The same program without the loop

This is the mistake nearly everybody makes first, and it is a hard one to spot because nothing about it looks wrong:

when program starts :: events hat
if <[1 v] is pressed? :: sensors> then
  [A v] start motor [clockwise v] :: motors
else
  [A v] stop motor :: motors
end

The logic is perfect. The ports are right. Nothing is misspelled. And the robot will ignore the button completely — because the Brick reaches that if/else a few milliseconds after you press Run, finds the button not pressed, takes the else branch, stops the motor, runs out of blocks and ends. By the time a finger arrives, there is no program left to notice it.

Both programs contain exactly the same if/else. The counter is what gives it away: one keeps checking for as long as it runs, the other is stuck on the single check it made before anybody touched anything. A student who has seen this once stops writing it.

The tell on a real robot is a program that ends the instant you start it — the Brick returns to its menu almost immediately. If a sensor program finishes rather than waits, the loop is what is missing.

Choosing the right loop

• Known number of times — repeat (n). A wiper that sweeps five times.
• Until something happens — repeat until. Drive until the wall is close.
• For as long as the machine is on — forever. A fan, a ride, a monitor.

Driving with two motors

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 B

port C

Blocks reference

set movement motors to [B v] and [C v] :: movement

move [forward v] for (2) [rotations v] :: movement

move for (1) [rotations v] at (75) (25) % speed :: movement

set movement speed to (50) % :: movement

The letters must match the sockets

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.

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.

Straight, curved, and on the spot

Everything a driving base can do comes from those two speed numbers. Try each button below and watch the trail the robot leaves.

• Both wheels the same speed — the robot goes straight.
• One wheel faster than the other — it curves towards the slower side. The bigger the difference, the tighter the curve.
• One wheel forward, the other backward — it spins on the spot, which is how a robot turns in a space no wider than itself.

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

How far is one rotation?

“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.

• 1 rotation = 17.5 cm. Two rotations is 35, three is 52.5.
• Halves are real. 1.5 rotations is a perfectly good thing to type into the block, and it is 26.25 cm — right between the 1 and the 2 you already tried.
• To go a distance you have chosen, divide by 17.5. The calculator does it, but do a few by hand first — 35 ÷ 17.5 = 2 is worth seeing.
• Measure your own wheels before trusting the number. A base built with different wheels travels a different distance per rotation, and every calculation on this page moves with it.

set movement motors to [B v] and [C v] :: movement
set movement speed to (30) % :: movement
move [forward v] for (2) [rotations v] :: movement

Turning on the spot

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:

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.

Why it matters

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.