Debugging with Telemetry

Why Debugging with Telemetry matters

This lesson is part of the team workflow layer, where code quality becomes a competition habit. The point is to make programming choices visible, reviewable, and recoverable when students are tired or under event pressure.

Starting point

Telemetry is the robot talking back

Good telemetry turns mystery behavior into visible data. Show joystick input, current state, motor power, and any sensor value that affects decisions.

Debug the smallest claim first

Before rewriting logic, check whether the robot sees the same input you think it sees. Most fixes start with one boring value on screen.

Build path

Practice the workflow in small loops: make a change, describe it, test it, record the result, and decide whether it is safe to keep. The lesson should produce a team artifact such as a checklist, branch, commit, tuning note, or debug log.

For this specific lesson, students should first restate the goal in robot terms, then identify the value or behavior they expect to observe, then run the smallest test that proves the idea. The lesson should feel like a guided lab: predict, run, observe, explain, and only then extend.

Debugging and failure modes

Workflow breaks when knowledge lives only in one student's head. If nobody knows what changed, what was tested, or what code is deployed, the robot becomes fragile. The lesson should make the next action obvious to another teammate.