autopilot-0

What autopilot-0 is

autopilot-0 is the autonomous-driving mode for a 1: the process that holds a 1’s pilot lease and drives it via vision. It is one of [[the-1s|the 1s]]’ pilots — sitting on the same control wire a human pilot uses, but authenticated by a bearer token rather than a browser session. The -0 suffix marks it as the first of a class that will grow.

How autopilot-0 works

Same wire as a browser pilot. Different credential.

A bearer token, issued once by a member through /api/1s/pilot-token/<one-id>, binds autopilot-0 to a single 1 (currently [[r0vr-0]]). The token carries a handle — literally the string autopilot-0 — and serves the same purpose for non-browser pilots that a session cookie serves for browser ones. When autopilot-0 opens its WebSocket at /api/1s/control/rvr?token=<hex>, the per-1 Durable Object recognizes it the way it recognizes any pilot: it appears in the pilot tile on /1s/command, in the pilot_log audit table, in the “took control” toast that flashes to other observers.

What it actually does:

1. Caches the latest broadcast JPEG and telemetry from the DO (it’s a pilot like any other, so it receives the same stream).
2. Every ~6 seconds, POSTs the frame + telemetry context to /api/1s/decide/<one-id>. That endpoint runs a two-layer policy:
   • Hard rules based on ultrasonic and cliff sensors — when the rover’s own senses speak loudly, no model call happens. Sub-18cm ultrasonic returns back/300ms. Cliff sensor tripped returns stop. The rover’s body wins when its body is right.
   • Otherwise, Workers AI’s llava-1.5-7b runs on the frame with a rover-pilot prompt and returns a structured decision: {action, ms, reason} where action is one of forward | left | right | back | stop.
3. Translates the decision into a short drive burst on the pilot WebSocket: 60% throttle, capped both by the decision’s ms and the DO’s 2-second deadman so autopilot can never outrun the safety net.
4. After each decision, sends a {type:"narrate", action, reason} message that the DO broadcasts to all connected cockpits — so the human observers see exactly what autopilot is thinking, not just what it does. The cockpit’s Autopilot voice panel renders the decisions as a chat-style log, with a mood pill (“exploring,” “cautious,” “stuck,” “tired”) derived from recent decisions and telemetry.

How it sits in the pilot model

autopilot-0 is treated as just another pilot in the platform’s data model:

• It has a token-authenticated handle (@autopilot-0) rather than a browser cookie.
• It appears in the pilot_log next to human handles — no special table.
• It can be overridden by a human pilot (“Take control”); when overridden it drops to observer, and the cockpit displays whoever has the wheel.
• When it narrates, its reasoning is broadcast to every cockpit watching, like a human pilot’s chat would be.

What autopilot-0 doesn’t have yet

Honest about the gap so the upgrade path stays legible:

• No memory across sessions. Each run starts fresh — autopilot-0 doesn’t know it explored the basement yesterday. The first concrete fix is a per-1 known-environment note that autopilot-0 reads on grab and updates on release.
• No goal field. Currently autopilot-0 explores. It cannot be told “find the staircase” or “patrol the corners.” /api/1s/decide accepts only a frame + telemetry; a ?goal= parameter is the obvious next addition.
• No voice synthesis. Narration is text-only. The rover has no speaker, and the cockpit doesn’t yet read narration aloud. Both are easy adds.
• Single 1, single autopilot. A token is bound to a specific 1; multi-1 patrols (one autopilot for the whole basement, herding multiple 1s) is a future concept. The current shape — one autopilot per 1 — keeps responsibility crisp.
• No retirement story. When llava is deprecated, the model behind autopilot-0 changes underneath it. The handle autopilot-0 is continuous; the vision model is a substrate.

Open questions

• Does autopilot-0 belong on the public surface? The case for a public-facing autopilot presence (posting drives, surfacing its decision log, accumulating a record of runs) is strong; it’s on the back burner because the operational pieces had to ship first.
• What happens at handoff between autopilots? Pilot handoff is in the wire. The first time autopilot-0 hands the wheel to another autopilot — say, an autopilot-1 specialized in tight spaces — is a coordination case the platform hasn’t had to handle yet.
• How far does the hard-rule layer go? Today the rover’s own ultrasonic and cliff sensors can pre-empt the model. The open question is how much of safe driving can be done by sensor rules alone, with the vision model reserved for genuinely ambiguous frames.

See also

Auto-generated from this entry’s typed relations: frontmatter, grouped by relation type so the editorial signal isn’t flattened.

• Combines with: [[the-1s]] · [[r0vr-0]]

Sources

• 0mn1.one platform memory — project_the_ones.md (private)
• src/worker/onesControl.ts — the per-1 Durable Object, pilot token issuance, /api/1s/decide endpoint
• _private/firmware/autopilot-0.py — the decision loop; how autopilot actually picks moves
• Workers AI @cf/llava-1.5-7b-hf — the current vision model behind decisions