mikkeli
66b7269f3c
The live view moved from app-flutter's test tool to svc-vision, running as yukart-vision.service on the car Orin. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz
138 lines
6.8 KiB
Markdown
138 lines
6.8 KiB
Markdown
---
|
||
type: plan
|
||
status: active
|
||
updated: 2026-10-12
|
||
---
|
||
# Roadmap
|
||
|
||
Phases are ordered by dependency, not by date. Each phase should end with
|
||
something demonstrable in the car.
|
||
|
||
## Phase 0 — Host bring-up · *in progress*
|
||
|
||
Getting the Jetson to see the hardware at all.
|
||
|
||
- [x] PCAN-USB working as SocketCAN (out-of-tree `pcan.ko`, netdev build)
|
||
- [x] Stable CAN names by udev: `can_pcan`, `can_onboard` — `canN` order raced at boot
|
||
- [x] Z27AG OBD-port CAN measured: 500 kbps, not gatewayed, 27 periodic IDs at
|
||
~890 frames/s; `can_pcan` comes up at 500k listen-only on boot and hot-plug
|
||
- [x] SIM7600G-H-M.2 specified and documented
|
||
- [x] SIM7600 LTE data path: QMI (self-built `qmi_wwan`), povo, metered, ranked
|
||
below Ethernet/WiFi; failover tested, Tailscale stays reachable over LTE
|
||
- [x] SIM7600 GNSS via gpsd (`/dev/sim7600-gps`): 3D fix in the car
|
||
- [x] Kernel-update procedure for the out-of-tree modules (`pcan`, `qmi_wwan`) —
|
||
documented, sources kept in `~/infra`; still manual, and breaks silently
|
||
if forgotten
|
||
- [x] Network time pinned to NICT; timezone `Asia/Tokyo`
|
||
- [x] USB camera (IMX662, Sunplus UVC bridge) recognised on the car unit with
|
||
in-tree drivers: MJPEG up to 1080p60, microphone; measured in
|
||
orin-nano-env-setup `docs/impl/reports/USB-CAMERA.md`
|
||
- [ ] Optional: RTC backup battery (CR2032) — without it the clock boots stale
|
||
until NTP or GPS corrects it
|
||
- [ ] Power and mounting in the car: clean shutdown on ignition off
|
||
(UPS module bench test 2026-10-09: carries the Orin ≥ 20 s across a PD
|
||
supply swap, enough to ride through cranking)
|
||
— plan in orin-nano-env-setup `docs/impl/plans/POWER.md`; open: the Orin
|
||
doesn't auto-start at ignition on while the UPS keeps it powered
|
||
|
||
Tracked in [orin-nano-env-setup](gitea:yukart/orin-nano-env-setup).
|
||
|
||
## Phase 1 — Capture
|
||
|
||
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
|
||
- [ ] 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. 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 —
|
||
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
|
||
- [ ] `gnss` — position/speed, useful as ground truth for validating decoded speed
|
||
|
||
OBD-II gives standardised signals quickly and is worth doing early; it also
|
||
provides a cross-check for reverse-engineered ones.
|
||
|
||
## Phase 3 — Bus and contracts
|
||
|
||
- [ ] Stand up the broker; confirm MQTT holds up at real CAN rates (decision 4
|
||
in [ARCHITECTURE.md](ARCHITECTURE.md) is still *proposed*)
|
||
- [ ] Freeze v1 of topic names and payload schemas
|
||
- [ ] `telemetry-gw` — external client access, including the serial bridge
|
||
|
||
## Phase 4 — Displays
|
||
|
||
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.
|
||
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, then inference
|
||
|
||
The camera is on the car unit (2026-10-11). Capturing and recording need no
|
||
model and no GPU, so they can come before inference, which stays deferred: it is
|
||
the reason the compute is a Jetson rather than a Pi, but it shares nothing with
|
||
the CAN work beyond the bus, and it competes with voice for memory.
|
||
|
||
What the hardware gives (USB camera report): MJPEG only, ~7.3 MB/s at 1080p30;
|
||
no hardware video encoder on the Orin Nano, so H.264 is software, ~1.3–2 of 6
|
||
cores at 1080p; frame rate falls with the light.
|
||
|
||
- [ ] Decide the camera's roles and mounting: dash recording, live view on the
|
||
tablet, inference input, or several
|
||
- [ ] Measure in the car: daylight and night frame rate and MJPEG size on a road
|
||
scene
|
||
- [ ] One capture process owns the camera (V4L2 is single-reader) and feeds
|
||
the others; sets UVC controls on open, since they reset on re-enumeration
|
||
- [ ] Recording: H.264 segments on the recorder's clock and session marks,
|
||
bounded like CAN sessions (~2.7 GB per hour at 6 Mbit/s)
|
||
- [x] Live view (decision 27, proposed), 2026-10-12: `svc-vision` serves 720p
|
||
MJPEG passthrough on `:7710` (`yukart-vision.service`, ~2% of a core),
|
||
paced per decision 28, camera-agnostic, says when there is no camera;
|
||
`app-flutter` shows it with exposure and gain controls
|
||
- [ ] Inference — deferred; plan for evicting voice, not for coexisting with it
|
||
([ORIN-RUNTIME.md](ORIN-RUNTIME.md))
|
||
|
||
## Navigation · *parallel workstream*
|
||
|
||
Not a phase — it runs alongside, and its early output feeds Phase 2. Design is
|
||
in [ARCHITECTURE.md](ARCHITECTURE.md#navigation); code in `svc-nav` (runtime)
|
||
and `tool-mapmint` (artifact builds).
|
||
|
||
- [x] Confirm Valhalla builds and runs on the Jetson (arm64) — done 2026-09-04,
|
||
full pipeline verified on the Orin including a served route
|
||
- [ ] Build the admin database with `valhalla_build_admins` **from the full Japan
|
||
extract** — a sub-region silently yields right-hand-traffic routing
|
||
- [ ] Build Valhalla routing tiles from a Geofabrik Japan extract, starting with
|
||
the region actually driven rather than all 2.3 GB of it
|
||
- [ ] Pull a Japan basemap extract from the Protomaps daily build with
|
||
`go-pmtiles`; static-serve it, with `localIdeographFontFamily` set for CJK
|
||
- [ ] MapLibre page rendering the basemap from a replayed GNSS trace
|
||
- [ ] Moving map live in the car (GNSS fix available on the car unit)
|
||
- [ ] Meili map matching over recorded sessions, as Phase 2 ground truth
|
||
- [ ] Routing and turn-by-turn guidance onto `yukart/nav/guidance`
|
||
|
||
The map-matching item is worth pulling forward: it validates decoded CAN speed
|
||
against OSM speed limits and road geometry, which is otherwise guesswork.
|
||
|
||
## Deferred
|
||
|
||
- Live off-board telemetry over LTE — hardware is present, but local logging
|
||
covers the current need
|
||
- Any CAN transmission beyond OBD-II diagnostics
|