28. RobotState and Superstructure as components

The motor and swerve chapters recovered the bottom two layers as components. This chapter does the same for the two higher seams of Part I — the world model and the coordinator — and in doing so collects the payoff promised in ch. 24: the seams that looked like three different shapes turn out to be the same faceplate at different altitudes.

RobotState is an estimator

The state seam (ch. 4) is a component with an unusual fill-pattern: it is a sensor that fuses. Its channels:

• Config — the vision standard deviations and trust weights.
• Command_in — empty. Nobody commands an estimate; what flows into this component — odometry from the drive, timestamped pose measurements from vision — arrives via the Observations channel, as the State of its designated peers (ch. 25).
• State — the fused Pose2d plus confidence (and, at the elite end, game-piece and mechanism state).
• Command_out — none. It commands nothing; it only emits an estimate.

In control terms it is an observer — the component that infers hidden state from measurements — which is exactly why pose estimation belongs in its own component rather than privately inside the drive subsystem. The mechanics (the time-interpolating buffer, the fusion math) are Part II (ch. 20); the point here is structural: both command channels are empty — everything it consumes arrives as Observations, and it emits nothing but State — and that emptiness is what distinguishes an estimator from a controller.

There is one honesty note, which ch. 32 returns to. RobotState does not sit in the command tree — nobody commands it and it commands nothing. It is a cross-cutting peer, a shared blackboard that many components read. Commands form a tree; state, with RobotState as a hub, forms a DAG. Same faceplate, different wiring.

Superstructure is an executive

The coordination seam (ch. 5) is a component that fills all four channels:

• Config — the interlock table and the goal graph.
• Command_in — one robot-wide goal from the driver or an autonomous routine.
• State — its FSM mode and readiness flags (here the status half of state is the primary output; the estimate is secondary).
• Command_out — a per-subsystem goal for each mechanism.

It is a controller whose plant is other subsystems instead of motors. The guarded transition function that turns one goal into a legal sequence of setpoints — and holds the interlocks in one place — is just this component’s update.

Why a subsystem and an executive are the same kind

Set the two side by side and the recursion is plain. A subsystem fills all four channels and its Command_out feeds motors. A superstructure fills all four channels and its Command_out feeds subsystems. Nothing else differs. The executive is not a special top-level construct; it is a component whose children happen to be other components. This is what lets the model claim “even the coordinator fits”: the same interfaces carry intent downward and state upward at every altitude.

It is also why every level’s exposed POD is named …State, and why above the leaf that State splits into an estimate half and a status half — the argument is ch. 25’s, and these two components are its extreme instances: RobotState is nearly all estimate, the superstructure’s state nearly all status.

(RobotState’s row has an empty Command_in by design — odometry and vision poses reach it as Observations, not as commands.)

Read the table top to bottom and it is one shape applied at five altitudes — the genus (ch. 25) and its species. The deep dives for these two seams are Part II (the world model; coordination in ch. 22 and ch. 23); what Part III adds is that they are not separate inventions but the same faceplate. The next three chapters collect what that uniformity buys: telemetry, replay, and tests for free.