Section 55.1: From notebook to robot

For From notebook to robot, deployment quality is measured by the command stream, safety monitor state, and replayable evidence behind each command.

A Careful Control Loop

Problem First

A notebook hides process boundaries, start-up races, stale topics, missing calibration, device contention, and undeclared operator assumptions. The robot experiences all of them concurrently, so deployment is a systems-identification step as much as a packaging step.

The practical question is therefore sharper than "does the model work?" It is: which sensors and clocks define the current state estimate, which action interface is authoritative, which monitor may override it, and which artifact proves that the resulting behavior is acceptable under perturbation?

Theory

Deployment begins by splitting the system into a high-rate actuation loop, a perception and estimation path, a policy service, and a supervisory layer. The minimum timing constraint is

$$\tau_{\mathrm{sense}} + \tau_{\mathrm{queue}} + \tau_{\mathrm{infer}} + \tau_{\mathrm{publish}} \le T_{\mathrm{policy}}, \quad T_{\mathrm{policy}} \le k T_{\mathrm{ctrl}},$$

where $T_{\mathrm{ctrl}}$ is the low-level controller period and $k$ is the number of controller ticks for which a policy action may remain valid. Once that inequality is violated, the deployment problem is no longer "model quality" but stale-command control.

A useful evidence record is $e_i=(x_i,\hat s_i,a_i,m_i,\ell_i,z_i)$, where $x_i$ is the scenario context, $\hat s_i$ is the estimator state, $a_i$ is the issued command, $m_i$ is the monitor transition, $\ell_i$ is the latency vector, and $z_i$ is the artifact id. Every deployment claim in this chapter should be recoverable from one set of $e_i$ records.

Worked Example

A notebook policy may look stable simply because the camera stream, estimator, and model all run in one synchronous process. On the robot, the camera can start late, one frame can be dropped, or a model can reload during operation. A deployment artifact should make those conditions observable instead of collapsing them into one final score.

from dataclasses import dataclass, asdict
import json

@dataclass
class DeploymentManifest:
    section: str
    control_hz: int
    policy_hz: int
    max_staleness_ms: int
    fallback_mode: str
    rollback_trigger: str
    readiness_checks: list[str]

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

manifest = DeploymentManifest(
    section="55.1",
    control_hz=100,
    policy_hz=10,
    max_staleness_ms=80,
    fallback_mode="hold_last_safe_command_then_stop",
    rollback_trigger="two consecutive watchdog failures or any emergency-stop event",
    readiness_checks=[
        "camera topic alive",
        "extrinsics loaded",
        "policy checksum verified",
        "controller deadline miss rate < 0.1%",
    ],
)

print(json.dumps(manifest.as_row(), indent=2))

{
  "section": "55.1",
  "control_hz": 100,
  "policy_hz": 10,
  "max_staleness_ms": 80,
  "fallback_mode": "hold_last_safe_command_then_stop",
  "rollback_trigger": "two consecutive watchdog failures or any emergency-stop event",
  "readiness_checks": [
    "camera topic alive",
    "extrinsics loaded",
    "policy checksum verified",
    "controller deadline miss rate < 0.1%"
  ]
}

The expected output is a manifest with fields that an operator, an auditor, and a replay script can all consume directly. If the rollout report later claims success but cannot point back to explicit readiness checks, the system is still operating in notebook mode intellectually even if it is physically on a robot.

Practical Recipe

1. Write one deployment manifest before touching launch files.
2. Measure controller tick rate, policy tick rate, queue age, and topic freshness under nominal load.
3. Inject at least one startup fault and one runtime fault.
4. Record monitor transitions, operator interventions, and rollback decisions in the same artifact.
5. Promote the service only if the artifact is enough for another team to reproduce both success and failure behavior.

From notebook to robot becomes operational when the model is subordinated to a runtime contract. The contract should specify who owns each transition in the boot-to-ready-to-autonomous path, how stale actions are detected, and when the robot leaves autonomy without human debate.

The disciplined habit is to separate three claims. The conceptual claim says the policy should improve task performance. The systems claim says the policy can live inside the timing and safety envelope. The evidence claim says the resulting deployment bundle proves both.

Cross-References

For From notebook to robot, connect benchmark design, sim-to-real transfer, uncertainty, and safety barriers through the deployment artifact that will be checked before release.

When the transition to hardware fails, assign the fault to startup sequencing, timing, frame inconsistency, estimator drift, stale command handling, operator procedure, or evaluation hygiene. Then rerun a perturbation that isolates exactly one of those mechanisms.