Building a Test Course

One-sentence summary

To test a robot reliably, we build a safe course that offers the same conditions every time, write the test down as a scenario, and measure and record the results.

Why it matters

You have written your robot's code, the motors are turning, and the sensor is reading something. But is the robot actually working *correctly*? The only way to find out is to try it. Yet trying it in the middle of a table, tangled in cables, starting from a different spot each time, teaches you very little. It works once, fails the next time, and you never learn why.

This is why robot builders prepare a separate test course: a safe area with clear boundaries where you can watch the robot's behaviour under the same conditions every time. A good course gives you two things: repeatability (running the same test the same way again and again) and safety (a moving robot not harming you, your surroundings, or itself).

This lesson brings together ideas you already know. From autonomous systems you know that the robot makes its own decisions; the next lesson, Fault Analysis, shows how to locate a problem when the robot misbehaves. But good fault analysis rests on good testing. Without a proper test course, we cannot honestly answer the question, "Why did the robot struggle?"

Setting up a safe, repeatable test area

A robot is not code on paper; it moves, turns, and sometimes darts off in an unexpected direction. So the first rule of testing is to prepare the area in advance.

Clear and enclose the area

Set up the test area on a flat, empty surface. Do not leave cables to trip on, loose parts, or breakable objects on the floor. To stop the robot from leaving the area and falling off a table, place a low barrier (books or foam strips, for example) along the edges. Even for a small robot, a clear area of one metre by one metre is usually enough.

Start every test from the same place

The secret to repeatability is to fix the starting conditions. Release the robot from exactly the same point, facing the same direction, every single time. To make this easier, you can mark a start line on the floor and a point to align the front of the robot with.

Think about it: if you start the robot once from the left corner and once from the middle, and the behaviour comes out different, is that because of the code or the starting point? You cannot tell. When the start is fixed, the only thing that changes is the setting you are testing.

Short rule: change only one thing at a time in a test. If you change the start point, the speed, and the surface all at once, you cannot tell which one caused the result.

Designing the course: line and obstacle layouts

What your course looks like depends on what your robot is meant to do. Let's look at two common examples.

Example 1: A line-following robot course

A line-following robot follows a dark strip on the ground. For this robot, you can build the course like this:

• On a flat, light-coloured surface, stick down a path using dark (for example, black) electrical tape.
• The tape width should suit the robot's sensor spacing; around 2–3 centimetres usually works well.
• Increase the difficulty step by step: first a straight line, then a wide bend, and finally sharp turns and a fork.

This lets you see where the robot struggles. If it runs smoothly on the straight line but loses the line on a sharp turn, you know the problem lies in its turning behaviour.

Example 2: An obstacle-avoiding robot arena

An obstacle-avoiding robot detects objects in front of it with a distance sensor and changes direction before hitting them. For this:

• Build a box-shaped arena with barriers around the edges.
• Place light, stable obstacles inside (boxes, cylinders). Do not use heavy or breakable objects.
• Put the obstacles in the same places for every test. To make this easier, you can mark the obstacle positions on the floor.

When you run repeated tests with the same layout, you can see whether the robot gets stuck on the same obstacle each time. That information is the starting point for the fault analysis in the next lesson.

Writing a test scenario and measuring

Building the course is not enough; the test itself also needs to be written down like an algorithm. This is called a test scenario. A good scenario states three things clearly: the starting condition, the action to perform, and the expected result.

Planning the scenario with a table

This table is the testable form of the sense–decide–act logic from the autonomous systems lesson. You cannot run a test without the "expected result" column: if you do not know in advance what "correct" looks like, you cannot say whether your result is right or wrong.

Turning observation into measurement

"The robot did well" is an observation, but not a measurement. A measurement is a number you can compare. For example:

• In how many seconds did the robot finish the course?
• In how many of 5 attempts did it finish without losing the line?
• On average, how many centimetres before the obstacle did it stop?

You can also use the robot's own measurements. In Arduino, by printing the sensor values to the serial port, you can watch what the robot is *seeing* in the moment:

void loop() {
  int distance = readDistanceSensor();  // value from the sensor, cm
  Serial.print("Distance: ");
  Serial.println(distance);             // to watch on the computer

  if (distance < 15) {                  // decision threshold
    stopMotors();
    turnRight();
  } else {
    goForward();
  }
  delay(100);                           // short wait each loop
}

While watching the numbers on the serial port, you can see whether the robot stops at the obstacle when it reads "15 cm" or "8 cm." These numbers make it much easier to find the source of a problem in the next lesson.

Hands-on activity

Imagine you have a line-following robot (or picture one in your mind). Follow these steps:

1. Choose a start line and a mark for the robot to align with.
2. Use tape to build a three-part course: a straight section, a wide bend, and a sharp bend.
3. Write a test scenario table like the one below. Include at least three rows, and put an expected result in each one.

| Test | Starting state | Action | Expected result |
| 1    | ...            | ...    | ...             |

1. Repeat the same test 5 times and note one result each time (for example: "lost the line / did not lose the line").
2. Write, as a number, how many of the 5 attempts were successful.

At the end, ask yourself: in which section did the robot struggle most? That section is the first place for you to work on.

Common mistakes

Running every test in different conditions

If you start the robot once on a carpet, once on parquet, and from different points, the results cannot be compared. Keep the conditions fixed and change only the setting you are testing.

Testing without writing the expected result

"Let's see what happens" is not a test; it is an observation. First write down what you expect to happen; only then can you say whether the result is right or wrong.

Trusting a single attempt

Saying "it works" because the robot succeeded once is misleading. In moving systems, small differences change the outcome. Repeat the same test several times and count how many attempts succeed.

Noting impressions instead of measurements

Words like "nice" or "fast" cannot be compared. Write a number such as time, distance, or success count, so you can compare it with the next attempt.

Safety note

A moving robot can pinch a finger, hair, or cable between its wheels and gears, fall off a table, or crash into an object. So:

• Clear the test area beforehand and place a low barrier along the edges so the robot cannot fall off.
• Keep your fingers, hair, and loose cables away from the spinning wheels and gears.
• Always run the first attempts at low speed; increase the speed gradually only after you see how the robot behaves.
• Never power the motors directly from an Arduino pin. Use a separate low-voltage battery pack and a motor driver, and connect the two circuits to a common GND (common ground).
• If motors, cutting tools, or soldering are involved, ask an adult for help. Never run the robot from mains (wall) electricity.

Lesson summary

• A test course is a bounded area that lets you watch the robot's behaviour under the same, safe conditions every time.
• For repeatability, fix the starting conditions and change only one thing per test.
• The course design depends on the task: a taped path for line following, an arena with fixed obstacles for obstacle avoidance.
• A test scenario states, in writing, the starting state, the action, and the expected result.
• Note measurements rather than impressions (time, distance, success count) so you can compare results.

Check questions

1. What are the two basic things a test course should provide?
2. What does a "repeatable test" mean, and what do we keep fixed at the start to achieve it?
3. What three parts must a test scenario always contain?
4. Is "the robot did well" a measurement? What kind of information should we note instead?
5. Why do we power the motors from a separate battery and motor driver rather than directly from an Arduino pin?

Answers

1. Repeatability (being able to run the same test the same way again and again) and safety (the moving robot not harming anyone, the surroundings, or itself).
2. It means running the test under the same conditions each time and getting a comparable result. To achieve it, we keep the start point, the robot's facing direction, and the surface fixed, and change only the setting we are testing.
3. The starting state, the action, and the expected result. Without the expected result, we cannot say whether the result we got is right or wrong.
4. No, "did well" is an impression, not a measurement. Instead we should note a comparable number: completion time, stopping distance, or how many of 5 attempts succeeded.
5. Motors draw far more current than an Arduino pin can safely supply; pulling that current straight from the pin would damage the Arduino. The motor driver passes power from the separate battery to the motors safely, while the Arduino only sends the control signal. The two circuits must share a common GND.

Source and verification note

For “Building a Test Course”, verification focuses on whether the relationship between Setting up a safe, repeatable test area and Start every test from the same place remains consistent across examples. Robot behaviour cannot be explained by code alone; mechanical structure, power system, sensor placement and surface conditions must be evaluated together. Test results should be recorded over several runs on the same course.

Next lesson

Fault Analysis: When the robot behaves unexpectedly in a test, locating the source of the problem by narrowing it down step by step.