WEBVTT

00:00:00.070 --> 00:00:04.330
So, you already know that telemetry lets us see values from inside the robot loop.

00:00:04.330 --> 00:00:11.770
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.

00:00:12.850 --> 00:00:16.930
So, we want to start with a prediction.

00:00:16.930 --> 00:00:22.810
So, in this fixture, the drive is positive 0.5, strafe is zero, and turn is zero.

00:00:22.810 --> 00:00:27.610
That should produce positive 0.5 for all four of our wheel commands.

00:00:27.610 --> 00:00:33.550
The input, calculation, and command layers are all software.

00:00:33.730 --> 00:00:43.390
After that, the evidence crosses into the actual robot configuration,
the hub ports, wiring, and the actual mechanism.

00:00:43.390 --> 00:00:49.090
This example stops at that boundary.
We do not have physical robot evidence to inspect.

00:00:52.090 --> 00:00:56.830
So, looking at the code here, this is the clean fixture.

00:00:56.830 --> 00:01:01.510
The three inputs are fixed, so every replay uses the same conditions.

00:01:01.510 --> 00:01:06.730
Directly below them, the four mixer equations calculate
front left, front right, back left, and back right.

00:01:06.730 --> 00:01:12.310
And telemetry prints the inputs and all four results together.

00:01:12.310 --> 00:01:17.950
The clean front-right line is drive minus strafe minus turn.

00:01:17.950 --> 00:01:24.730
With our inputs, that is 0.5 minus zero minus zero: positive 0.5.

00:01:24.730 --> 00:01:32.290
Now, if we compare that with a controlled faulty version,
only the front-right equation has changed.

00:01:32.290 --> 00:01:38.950
So, if we have a negative sign that appears in front of drive, like so,

00:01:38.950 --> 00:01:45.370
every other input and equation remains exactly the same.

00:01:46.390 --> 00:01:53.590
So, the input still matches our prediction.

00:01:53.590 --> 00:02:01.210
Front left, back left, and back right also match.
Front right is the first disagreement.

00:02:01.210 --> 00:02:08.110
We expected positive 0.5 and observed negative 0.5.

00:02:08.110 --> 00:02:13.150
That tells us where to look. We have evidence for an arithmetic problem
in the front-right mixer equation.

00:02:13.150 --> 00:02:19.810
We do not have a reason to rename a configured motor,
reverse a motor direction, or inspect a wire.

00:02:20.650 --> 00:02:29.050
So, when the original front-right equation is restored and the same inputs are replayed,
all four values return to positive 0.5.

00:02:29.050 --> 00:02:37.090
The evidence record should include the prediction, the incorrect value,
the exact one-line change, and the corrected value.

00:02:37.090 --> 00:02:44.130
Then we use the same method on the season robot.
If the software values agree but the wrong wheel moves,

00:02:44.130 --> 00:02:48.130
move down one layer to the configuration and port map.

00:02:48.130 --> 00:02:51.970
If the correct wheel moves in the wrong direction,
inspect the declared direction.

00:02:51.970 --> 00:02:57.730
The useful habit is to stop at the first mismatch
instead of guessing across every layer at once.

00:02:57.730 --> 00:03:04.930
Now, I know this sort of concept and example seems really, really simple,
but the sort of intent behind it is really important.

00:03:04.930 --> 00:03:11.410
Instead of looking and guessing at what you think might be the problem deeper down,

00:03:11.410 --> 00:03:17.110
start at the first mismatch, and then that'll actually save you time in the future.

00:03:17.110 --> 00:03:21.390
So, again, this is super simple, but try and apply it

00:03:21.390 --> 00:03:26.290
to the problems we actually encounter every day when you program.