Unit 01 · lesson

Trace One Robot Action End to End

You press a controller button. Half a second later, a mechanism moves.

That looks simple from the driver station. Underneath the interface, several systems have to agree.

This lesson is about tracing one action without skipping layers.

Start with an observable event

Use this example:

The driver holds the intake trigger and the intake rollers pull a game piece into the robot.

Do not begin with code. Begin with the physical result and work backward.

Physical layer

The rollers rotate in the correct direction with enough torque to overcome contact forces.

Mechanical layer

A motor shaft transfers torque through whatever mechanism the robot uses: direct drive, gears, belt, chain, or another transmission.

Electrical layer

The motor controller receives electrical power and regulates what the motor receives.

Control layer

Robot software requests an output from the correct controller.

Input layer

A controller button or trigger produces an input the program recognizes.

Feedback layer

A sensor may confirm the game piece arrived, motor speed changed, current increased, or a mechanism reached a position.

Now reverse the direction and trace the actual information flow.

human intent
→ controller input
→ Driver Station
→ robot program
→ command / subsystem logic
→ motor controller
→ motor
→ mechanism
→ game piece moves
→ sensor evidence returns

Completed trace: what if the sensor never changes?

Suppose the intake rollers run, the game piece enters, but the program never recognizes that it arrived.

The actuation path worked. The feedback path did not.

That immediately narrows the investigation. Rewriting the motor command would be noise. The useful questions are now about the sensor, its wiring, configuration, reading, threshold, or interpretation.

This is why architecture matters. It turns “the intake is broken” into a smaller claim.

Make a two-path diagram

For your chosen subsystem, draw two different paths:

Command path

input → decision → actuator command → physical motion

Evidence path

physical state → sensor → data → software interpretation → displayed/logged state

Label the actual device or software element at each step.

Then mark three failure points with an X.

For each X, write:

the symptom you would expect;
one observation that would support that failure;
one observation that would contradict it.

Example:

Possible fault	Expected symptom	Supporting evidence	Contradicting evidence
motor controller has no power	motor never moves	device dark/offline	controller reports normal voltage and responds
command never schedules	no requested output	logs show no command start	command log shows start/end
sensor threshold wrong	mechanism works but state stays false	raw sensor value changes below threshold	raw sensor value never changes

Why this beats random troubleshooting

Changing three things at once destroys information. If the robot starts working, you no longer know which change mattered.

A trace gives you an order:

confirm the symptom;
find the nearest observable boundary;
test one layer;
move upstream or downstream based on evidence.

That process scales. You can use it on a drivetrain, shooter, autonomous routine, CAN fault, sensor issue, or entire robot.

Unit evidence

Combine the system map from Lesson 1, the safety boundary card from Lesson 2, and today’s command/evidence trace.

Your Unit 1 evidence should show that you can answer one question clearly:

How does this machine turn an intention into a controlled physical result, and what evidence tells you whether it actually happened?

If your answer is only a parts list, keep tracing.