Unit 02 · lesson

Diagnose the Architecture Before Touching the Robot

Troubleshooting is a decision process.

The fastest teams are not the teams that change parts fastest. They are the teams that reduce uncertainty fastest.

Begin with the symptom, not the suspected cause

Compare these two statements:

The left drivetrain motor controller is bad.

The left side does not produce motion when commanded, while the right side behaves normally.

The second statement is useful because it reports an observation. The first one jumps to a cause.

Start with what you can defend.

Build an observation ladder

Use the architecture layers from the first two lessons.

For a motor that does not move, inspect from the easiest safe observation toward the physical output:

Is the intended command active?
Is the controller visible to software?
Does telemetry show a requested output?
Is supply voltage available?
Is current behavior plausible?
Does the motor shaft move?
Does the gearbox transmit motion?
Does the load move freely?

The exact order may change, but the principle stays the same: use low-risk evidence before disassembling hardware.

Failure-isolation case

A robot drives normally in the pit. On the field, it browns out during a hard acceleration and resets behavior.

Possible causes live across several layers:

Layer	Possible issue	Evidence to collect
Power	weak battery, high resistance, loose connection	voltage under load, battery test, connection inspection
Mechanical	drivetrain binding or excessive load	wheel/gearbox inspection, current comparison
Control	aggressive command creates current spike	output command, current logs, acceleration profile
Configuration	current limits or device settings wrong	saved configuration and device status

Replacing the radio because “the robot disconnected” may treat a symptom while ignoring the power event that caused the disconnect.

Write a diagnostic tree

Choose one failure from your robot or a supplied case:

mechanism does not move;
robot loses one side of drive;
sensor value is frozen;
multiple CAN devices disappear;
autonomous starts but stops early.

Build a decision tree with at least four observations.

Example:

mechanism does not move
├─ command inactive → inspect input/binding logic
└─ command active
   ├─ controller offline → inspect power/CAN/configuration
   └─ controller online
      ├─ output zero → inspect software state
      └─ output nonzero → inspect electrical/mechanical path

Each branch should name evidence, not an action like “replace it.”

Your Unit 2 architecture package

Revise your layered diagram so it now includes:

power path;
control/computing path;
major communication paths;
actuator path;
feedback path;
at least three observation points; and
one diagnostic tree.

A strong architecture package lets someone else troubleshoot without starting from zero.

That is the standard we want throughout the course: make the hidden structure visible before the machine forces you to.