Fault Analysis

One-sentence summary

When a robot does not work, we learn to stay calm and move layer by layer, from power up to code, to find where the fault actually is.

Why it matters

A robot rarely works the way you expect on the first try. The motors stay silent, the wheels spin backwards, a sensor always shows the same value, or the robot suddenly spins in place. This is normal; a large part of engineering is not "making it run" but "understanding why it does not run."

Here is the challenge: a robot has five different layers working at the same time. Power, wiring, sensors, code and mechanics. One symptom (for example, the robot not moving) can come from any of these layers. Instead of trying things randomly, if we follow a systematic path we can narrow the fault down in minutes.

The method you learn here is not only for robots; it works for any system that breaks. The idea of "check the simplest, most likely cause first" is useful everywhere in life.

Thinking in five layers

You can picture a robot as five layers stacked on top of each other. When you meet a symptom, you want to find which layer is responsible.

What are the layers?

1. Power: Batteries, power source, on/off switch. With no energy, nothing works.
2. Wiring: Cables, jumper wires, breadboard, solder joints, common ground (GND).
3. Sensor: Parts that give input, such as distance, line or touch. A wrong reading means a wrong decision.
4. Code: The program you uploaded to the Arduino. A logic mistake hides here.
5. Mechanics: Chassis, wheels, gears, motors. Even if the electronics are correct, the mechanics can jam.

One important rule: start from the bottom. Power and wiring are the simplest but most common causes. Before you start hunting for a code bug, make sure the battery is really charged. Even experienced engineers find that, most of the time, the problem is a loose cable.

A symptom tells you little; the layer tells you more

The same symptom can come from different layers. Example: "The robot does not go straight, it drifts to the right."

• It could be mechanical: one wheel is loose or a gear is rubbing.
• It could be power: the batteries are weak, one motor gets less power than the other.
• It could be code: the two motors are given different speed values.

That is why, instead of guessing the "why," we test each layer one by one and eliminate possibilities.

The layer-by-layer checking method

Now let us build a practical checking order. At each step, change only one thing and try again. If you change two things at once, you will not know which one worked.

Step-by-step checklist

1. POWER
   - Is the switch on?
   - Are the batteries charged? (Swap in fresh ones and try)
   - Is the power LED lit?

2. WIRING
   - Are all cables in place, any loose ones?
   - Do the motor driver and Arduino share a COMMON GROUND (GND)?
   - Are they connected to the correct pins?

3. SENSOR
   - What value does the sensor read on the serial monitor?
   - Does the value change when you put your hand in front?

4. CODE
   - Did the program upload? (Watch for the upload confirmation)
   - Are the correct pin numbers written?

5. MECHANICS
   - Do the wheels turn freely?
   - Is a gear or cable rubbing?

Serial monitor: seeing inside the robot

The serial monitor lets you read on screen what the robot is "thinking." It is where you follow the sensor values you cannot see with your eyes, and check whether your decisions really run.

For example, to print the value of a distance sensor:

void setup() {
  Serial.begin(9600);          // Start serial communication
}

void loop() {
  int distance = readDistance(); // Read the sensor
  Serial.print("Distance: ");
  Serial.println(distance);      // Print the value to the screen
  delay(200);
}

When you open the serial monitor, you see a steady stream of numbers. If the number does not change when you place your hand in front of the sensor, the problem is not in the code but in the sensor or the wiring. This one line instantly narrows down which layer holds the fault.

Print the decision too

You can print not only the sensor value but also the decision the robot makes. This shows you the case where "the sensor reads correctly but the motor does not respond."

if (distance < 15) {
  Serial.println("Decision: STOP");
  stopMotors();
} else {
  Serial.println("Decision: FORWARD");
  moveForward();
}

If the screen says "Decision: STOP" but the wheels keep turning, now you know: the code works correctly, so the problem is in the motor driver or the mechanics. We have found the layer.

Example fault-and-fix table

The table below shows, for common symptoms, which layer to start checking from. Use it as a starting map.

Note: the most common cause of the "motors do not turn" symptom is a missing common ground. If the Arduino and the motor driver are fed from separate power sources, their GND lines must be connected to each other. This connects to the safety note in the next section.

Mini practice

Ask a friend or your teacher to place a small, easily reversible "fault" in the robot. For example, they might unplug one motor cable or change a pin number in the code. Then you try to find it.

1. Turn the robot on and write the symptom in one sentence. Example: "The right motor does not turn."
2. Following the layer map, start from the bottom: power, wiring, sensor, code, mechanics.
3. Open the serial monitor and watch the sensor and decision lines.
4. At each step, change only one thing and try again.
5. When you find the fault, write a note on which layer it was and how you found it.

The goal of this exercise is not to find the fault fast, but to find it systematically. Instead of randomly tugging cables, follow the map.

Common mistakes

Changing several things at once

If you swap two cables together and the robot works, you will never learn which one was the problem. One variable per try.

Starting from the top layer

Most people dive straight into the code. Yet the biggest share of problems lies in power and loose cables. Check the simplest thing first.

Not using the serial monitor

If you cannot see inside the robot, you are only guessing. Printing the sensor value and the decision with Serial.println is like turning on a torch in the dark.

Forgetting the common ground

If the Arduino and the motor driver run on separate batteries and their GND lines are not joined, the motors will not work or will behave randomly. It is one of the most common hidden faults.

Not writing the symptom clearly

"The robot is broken" is not a symptom. "The robot moves forward but does not stop at an obstacle" is a testable symptom. A clear symptom leads you to the right layer.

Safety note

While hunting for a fault, the robot can move unexpectedly. So be careful:

• Clear the test area. Try the robot on empty ground where it cannot fall off a table or hit something. Keep the edges safe.
• Keep fingers, hair and cables away. Spinning wheels and gears can catch hair and cable; a trapped finger can hurt.
• Test at low speed. While fixing the code, keep the motor speed at its lowest value; if the robot runs off, it is easy to catch.
• Use a motor driver and a separate battery. Never power the motors directly from an Arduino pin; motors draw high current and damage the board. Use a motor driver (for example an L298N) with a separate, low-voltage battery pack, and connect the common ground.
• Never use mains electricity. Only low-voltage batteries. Do not connect to any circuit that runs from a wall socket.
• Cut the power when plugging or unplugging cables. Before changing a connection, turn off the switch to prevent a short circuit.
• Get an adult to help with motors, soldering and cutting tools.

Lesson summary

• A robot fault can come from five layers: power, wiring, sensor, code, mechanics.
• Start from the bottom; power and a loose cable are the most common and simplest causes.
• Change only one thing per try so you know what actually worked.
• The serial monitor shows sensor values and decisions; it narrows the fault down to a layer.
• Motors need a separate battery, a motor driver, a common ground and a clear test area for safety.

Check questions

1. Why do we start looking for a robot fault from the bottom layer (power)?
2. Which layers does the serial monitor help narrow down, and how?
3. For the symptom "Arduino runs but motors do not turn," what is the most likely cause to check first?
4. Why should we change only one thing per try?
5. Why do we use a separate battery with a motor driver instead of powering motors directly from an Arduino pin?

Answers

1. Because power and wiring faults are the most common and easiest to check. If the battery is dead or the switch is off, hunting in the upper layers is a waste of time.
2. It narrows down the sensor and code layers. If you print the sensor value with Serial.println and it does not change, the problem is in the sensor/wiring; if the decision line prints correctly but the motor does not respond, the problem is in the motor/mechanics.
3. A missing common ground (GND). If the Arduino and motor driver use separate power sources and their GND lines are not joined, the motors will not run. An empty motor battery is also possible.
4. If we change two things at once and the robot works, we cannot tell which change fixed the problem. One variable lets us mark the fault with certainty.
5. Motors draw high current; an Arduino pin cannot supply it and gets damaged. A motor driver takes the current from a separate battery while the Arduino only sends a control signal; a common ground lets both sides share the same reference.

Source and verification note

For “Fault Analysis”, verification focuses on whether the relationship between Thinking in five layers and A symptom tells you little; the layer tells you more 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

Project: Obstacle-Avoiding Robot