WEBVTT

00:00:00.060 --> 00:00:05.580
You already know that a subsystem
should own one mechanism.

00:00:05.580 --> 00:00:11.940
Let's follow an arm request through the same
read, periodic, write, and reset rhythm.

00:00:11.940 --> 00:00:17.220
Then see why direct motor writes from other
classes break that ownership.

00:00:17.820 --> 00:00:24.720
TeleOp and autonomous both need the arm,
but neither should write its motor directly.

00:00:24.720 --> 00:00:34.560
They request up, down, or idle. The arm subsystem
stores that intent and owns the final hardware write.

00:00:35.100 --> 00:00:43.860
This gives us one place to ask what state was
requested and what output that state produced.

00:00:43.860 --> 00:00:49.560
We can also ask what limits changed the output
and what happens on STOP.

00:00:49.800 --> 00:00:59.820
In this fixture, request only changes the desired
state. It does not wait or touch the motor.

00:00:59.820 --> 00:01:09.900
Read captures the encoder position. Periodic turns
the requested state into one bounded teaching output.

00:01:10.320 --> 00:01:24.540
Write sends that output to the motor exactly once.

00:01:24.540 --> 00:01:32.520
Reset returns the state and pending output
to idle and zero.

00:01:32.820 --> 00:01:42.240
Normal exits call the finally block
and share the same cleanup path.

00:01:42.240 --> 00:01:45.720
The power values are examples.

00:01:45.780 --> 00:01:52.260
We have different states,
and we can request a next state.

00:01:53.040 --> 00:02:00.840
The important note is the ownership shape,
not the numbers.

00:02:01.800 --> 00:02:13.140
Reading left to right, a caller requests intent,
and the subsystem reads its inputs.

00:02:13.140 --> 00:02:21.120
Then it calculates the pending output
and performs one hardware write.

00:02:21.120 --> 00:02:25.080
Cleanup resets the owner and writes zero.

00:02:25.080 --> 00:02:34.920
This is intentionally small. You do not need a giant
framework before writing a good subsystem.

00:02:34.920 --> 00:02:46.140
You need a clear owner and a small state vocabulary
for places an arm can go.

00:02:46.140 --> 00:02:58.260
Or whether a shooter is spinning. You also need
a consistent loop order, one final write, and telemetry.

00:02:58.260 --> 00:03:01.140
And, of course, explicit reset behavior.

00:03:01.500 --> 00:03:12.120
Now imagine TeleOp writes 0.4, and a helper
writes -0.2 later in the same loop.

00:03:12.120 --> 00:03:18.360
Both pieces of code can look reasonable,
but the last write wins.

00:03:18.360 --> 00:03:27.060
Telemetry inside the first writer may claim the
correct value while the motor receives something else.

00:03:27.060 --> 00:03:33.420
The fix is to remove the competing write,
not add more guesses.

00:03:33.420 --> 00:03:40.680
Search the project for every use of the motor
and route behavior through the subsystem.

00:03:40.680 --> 00:03:49.920
During the season, build this ownership map with
the programmers adding features to the same mechanism.

00:03:49.920 --> 00:04:03.540
Everyone needs to use the same vocabulary.
Confusing two states is a common teamwork-code error.

00:04:03.540 --> 00:04:08.640
Make sure everyone uses the vocabulary
in the same way.

00:04:08.640 --> 00:04:15.600
Subsystems should help with
organization and management.