Debugging with Telemetry

So, you already know that telemetry lets us see values from inside the robot loop. Let's use it to find the first layer that disagrees with what we think should happen instead of changing random parts of the actual code. So, we want to start with a prediction. So, in this fixture, the drive is positive 0.5, strafe is zero, and turn is zero. That should produce positive 0.5 for all four of our wheel commands. The input, calculation, and command layers are all software. After that, the evidence crosses into the actual robot configuration, the hub ports, wiring, and the actual mechanism. This example stops at that boundary. We do not have physical robot evidence to inspect. So, looking at the code here, this is the clean fixture. The three inputs are fixed, so every replay uses the same conditions. Directly below them, the four mixer equations calculate front left, front right, back left, and back right. And telemetry prints the inputs and all four results together. The clean front-right line is drive minus strafe minus turn. With our inputs, that is 0.5 minus zero minus zero: positive 0.5. Now, if we compare that with a controlled faulty version, only the front-right equation has changed. So, if we have a negative sign that appears in front of drive, like so, every other input and equation remains exactly the same. So, the input still matches our prediction. Front left, back left, and back right also match. Front right is the first disagreement. We expected positive 0.5 and observed negative 0.5. That tells us where to look. We have evidence for an arithmetic problem in the front-right mixer equation. We do not have a reason to rename a configured motor, reverse a motor direction, or inspect a wire. So, when the original front-right equation is restored and the same inputs are replayed, all four values return to positive 0.5. The evidence record should include the prediction, the incorrect value, the exact one-line change, and the corrected value. Then we use the same method on the season robot. If the software values agree but the wrong wheel moves, move down one layer to the configuration and port map. If the correct wheel moves in the wrong direction, inspect the declared direction. The useful habit is to stop at the first mismatch instead of guessing across every layer at once. Now, I know this sort of concept and example seems really, really simple, but the sort of intent behind it is really important. Instead of looking and guessing at what you think might be the problem deeper down, start at the first mismatch, and then that'll actually save you time in the future. So, again, this is super simple, but try and apply it to the problems we actually encounter every day when you program.