Phase 1 recorder running; svc-core current; boundary v0 started

The recorder runs on the car unit and reads SocketCAN and gpsd directly
(decision 25, proposed). svc-gw and app-flutter talk boundary v0, both
channels on one WebSocket with their own semantics (decision 26, proposed).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz
This commit is contained in:
2026-10-09 20:24:32 +09:00
parent 9a1512793d
commit e6ca835992
3 changed files with 16 additions and 7 deletions
+11 -4
View File
@@ -38,17 +38,22 @@ Tracked in [orin-nano-env-setup](gitea:yukart/orin-nano-env-setup).
Get real Z27AG traffic onto disk before designing anything around it.
- [x] `recorder` — raw CAN + GNSS sessions on the car unit (`yukart-recorder.service`):
starts on traffic or `ctl start`, ends after 15 s idle, marks via `ctl mark` or
the app; fsync'd every second, bounded at 50 GB, ~20 MB per hour of driving
- [ ] `can-bridge` — listen-only, timestamped frames onto the bus
- [ ] `recorder` — persist raw sessions
- [ ] Capture drive sessions across varied conditions (idle, cold start, moving,
lights/indicators/windows actuated) with a written log of what was done when
The manual event log matters more than it sounds: it is what makes the raw
capture decodable later.
capture decodable later. Marks go into the session itself (`yukart-recorder ctl
mark …`, or the app's Mark button), on the same clock as the frames.
## Phase 2 — Decode
- [ ] Correlate captures against the event log; identify recurring frame IDs
- [ ] Correlate captures against the event log; identify recurring frame IDs —
prior art and first candidates (engine speed in `0x210` / `0x13D`) in contracts
`docs/impl/reports/Z27AG-CAN-PRIOR-ART.md`
- [ ] Build the Z27AG DBC incrementally in `contracts`
- [ ] `decoder` — raw frames to named signals
- [ ] `obd-poller` — active OBD-II PIDs, single writer, rate-limited
@@ -69,7 +74,9 @@ provides a cross-check for reverse-engineered ones.
Order chosen by feedback speed, not ambition.
- [ ] One display end-to-end first, proving the contract — `app-flutter` is the
quickest to iterate on, and is the only display in current scope
quickest to iterate on, and is the only display in current scope.
Started: boundary v0 (contracts `docs/BOUNDARY.md`) between `svc-gw` on the
car unit and a text-readout starter app; not yet run on the tablet
- [ ] `app-esp32` — RLCD/e-ink glanceable subset. Deferred, no hardware in scope
## Phase 5 — Camera and inference · *separate task*