Subsystem Lifecycle

You already know that a subsystem should own one mechanism. Let's follow an arm request through the same read, periodic, write, and reset rhythm used in the lesson, then see why direct motor writes from other classes break that ownership. TeleOp and autonomous both need the arm, but neither one should write the arm motor directly. They ask for a state such as up, down, or idle. The arm subsystem stores that intent and owns the final hardware write. This gives us one place to answer the important questions: What state was requested? What output did that state produce? What limits changed the output? And what happens on STOP? In this fixture, request only changes the desired state. It does not wait and it does not touch the motor. Then read captures the encoder position, periodic turns the requested state into one bounded teaching output, and write sends that output to the motor exactly once. At the bottom, reset returns the state and pending output to idle and zero. Normal exits always call the finally block and share the same cleanup path. The power values are examples. We have different states and can request a next state. The important note here is the ownership shape, not the numbers. If we read this lifecycle from left to right, a caller requests intent on what we want to do, and the subsystem reads its inputs. Then it calculates the pending output and performs one hardware write. Cleanup resets the owner and writes zero. This is intentionally small. You do not need a giant framework before writing a good fundamental subsystem. You need a clear owner, a small state vocabulary for places an arm can go or whether a shooter is spinning, a consistent loop order, one final write, telemetry, and an explicit reset behavior. Now imagine TeleOp writes 0.4 and a helper writes -0.2 later in the same loop. Both pieces of code can look reasonable by themselves, but the last write wins. Telemetry inside the first writer may even claim the correct value while the motor receives something else afterward. The fix is to remove the competing write, not add more guesses into your system. Search the project for every use of the motor and route behavior through the subsystem. During the season, build this ownership map with the other programmers who add features to the same mechanism. Everyone needs to use the same vocabulary in the same way. Confusing two different states is a common teamwork-code error. Subsystems should help with organization and management.