Making a decision

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.