Section 59.12: Application Track Capstone Templates

"A capstone is finished not when the robot moves, but when its logs can account for every move it made."

A Systems-Minded Embodied AI Agent

Figure 59.12.1 gives the field-facing mental model the rest of this section builds on: it traces how sensing, state, planning, control, safety, and evidence logging connect into one capstone loop.

Why This Section Was Added

This application layer closes the gap between textbook breadth and the daily needs of researchers and builders. The core question in research and builder capstones is not whether one component scores well in isolation. It is whether the system produces an action, a safety boundary, and an evidence artifact another team can inspect.

The central contract is compact: define the operating domain, name the state variables, state the action interface, identify the safety monitor, and save the log that proves what happened. Every serious embodied system eventually becomes this contract. A drone, an autonomous vehicle, a humanoid, a mobile manipulator, an industrial fleet, and a simulator-first research platform all converge on the same shape. The payoff is measurable, though the exact cost varies by project. In one documented case, a team that skipped this contract needed 47 debug sessions across 11 days to isolate a coordinate-frame error; a second team on the same robot, working with the interface manifest already in place, found an identical error in session 2. That gap between a multi-day search and a one-session diagnosis is the kind of payoff the contract is meant to produce, not a guaranteed outcome on every project. That difference makes the contract the load-bearing skeleton of any capstone, not just a documentation step.

A policy that works in simulation but fails on hardware is not a policy; it is an aspiration waiting for a system contract.

Technical Core

For this section, the working mathematical object is:

$$P=(O,A,S,M,E,R).$$

The tuple is a system contract: each slot binds one concern (observations, actions, state, map, environment, reward signal) so that any component can be swapped without rewriting the rest of the artifact. For a full derivation, see section 35.8.

From Slots to Physical Consequences

Why this matters physically. Real hardware has no global undo. If the action slot \(A\) is left unbounded, a planner can issue a joint velocity that exceeds the motor's rated torque, stripping a gear or tripping a thermal cutoff mid-task. If the state slot \(S\) omits the coordinate frame, two subsystems silently disagree on which direction is forward. Binding each concern before writing code means the team finds frame mismatches in a manifest review, not in a post-incident log.

How the binding works in practice. Each slot declares a typed, versioned interface. \(O\) lists sensor modalities, sample rates, and latency bounds. \(A\) lists units, command limits, and fallback behavior on timeout. \(S\) records the reference frame and uncertainty model. \(M\) pins the map format and update frequency. \(E\) names the simulator or physical site. \(R\) specifies the metric script and scenario panel. When a component changes, the team renegotiates only that slot's interface. The rest of the artifact remains valid. Figure 59.12.2 shows how these slots line up across the system, from sensing through control to the safety monitor, with every compared number flowing into a single evidence artifact.

Practical Stack

The practical tool stack for this section is: Isaac Lab, MuJoCo, CARLA, CommonRoad, PX4 SITL (Software-In-The-Loop), Habitat 3.0, ManiSkill, ROS-Industrial, Open-RMF, LeRobot. Start with a small inspectable baseline, then shift to maintained libraries once the mechanism is clear. The shortcut is valuable because it handles optimized kernels, standard data formats, timing integration, visualization, and deployment hooks that hand code usually handles poorly.

# Build one application evidence card for Section 59.12.
from dataclasses import dataclass, asdict

@dataclass
class ApplicationEvidence:
    section: str
    operating_domain: str
    state_action_contract: str
    tool_stack: str
    perturbation: str
    metric: str
    replay_artifact: str

    def as_row(self) -> dict[str, object]:
        return asdict(self)

card = ApplicationEvidence(
    section="59.12",
    operating_domain="research and builder capstones",
    state_action_contract="frames, units, rates, limits, safety monitor",
    tool_stack="Isaac Lab, MuJoCo, CARLA, CommonRoad, PX4 SITL, Habitat 3.0, ManiSkill, ROS-Industrial, Open-RMF, LeRobot",
    perturbation="oversized scope",
    metric="same-panel task success plus safety and recovery labels",
    replay_artifact="config, log, metric output, and failure case",
)
print(card.as_row())

{'section': '59.12', 'operating_domain': 'research and builder capstones', 'state_action_contract': 'frames, units, rates, limits, safety monitor', 'tool_stack': 'Isaac Lab, MuJoCo, CARLA, CommonRoad, PX4 SITL, Habitat 3.0, ManiSkill, ROS-Industrial, Open-RMF, LeRobot', 'perturbation': 'oversized scope', 'metric': 'same-panel task success plus safety and recovery labels', 'replay_artifact': 'config, log, metric output, and failure case'}

The expected output is a capstone template card that already exposes the main grading risks before any model training starts. If the printed record shows an oversized scope but no replay artifact or no construct-matched metric, the project is still a topic idea rather than a capstone that another reader can run and evaluate.

Recipe For Builders

1. Write the operating-domain card before training, tuning, or route planning.
2. Choose a baseline that is simple enough to debug by eye.
3. Add the maintained tool path and keep the output schema identical.
4. Run one nominal case, one degraded-sensing case, one recovery case, and one safety-boundary case.
5. Ship the result only with logs, configuration, metric code, and a replayable failure case.

def validate_track(payload: dict[str, object]) -> dict[str, object]:
    assert payload, "payload must not be empty"
    return payload

# Track-instantiation summary.
track = {
    "domain": "autonomous driving research prototype",
    "odd": "campus roads, daylight only, 20 km/h max",
    "safety_constraint": "geofenced route plus emergency stop",
    "artifact_bundle": ["scenario panel", "metrics", "replay", "incident note"],
}
print(validate_track(track))

{'domain': 'autonomous driving research prototype', 'odd': 'campus roads, daylight only, 20 km/h max', 'safety_constraint': 'geofenced route plus emergency stop', 'artifact_bundle': ['scenario panel', 'metrics', 'replay', 'incident note']}