Files
project-yukart/docs/ROADMAP.md
T
mikkeli d234a2da37 Adopt designed front matter: typed, with staleness on plans
Replaces `type: default` — one value across every document, read by nothing,
so it discriminated nothing. Types are now reference, guidelines, plan and
report, applied to every markdown file with no exceptions for the hub.

Plans carry status and updated, reports carry date. REPOS.md already noted
that plans go stale and reports do not, but nothing made that visible: a plan
from months ago looked identical to one written today.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
2026-09-04 14:14:17 +09:00

95 lines
3.8 KiB
Markdown

---
type: plan
status: active
updated: 2026-09-04
---
# 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 `can1` (out-of-tree `pcan.ko`, netdev build)
- [x] SIM7600G-H-M.2 specified and documented
- [ ] SIM7600 brought up: LTE data path and GNSS via gpsd
- [ ] Kernel-update procedure for the out-of-tree PCAN module — it does not
survive kernel upgrades and will break silently
- [ ] Power and mounting in the car: clean shutdown on ignition off
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.
- [ ] `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.
## Phase 2 — Decode
- [ ] Correlate captures against the event log; identify recurring frame IDs
- [ ] 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 — Android client is the
quickest to iterate on
- [ ] `app-hud` — directly-driven screen (Class A)
- [ ] `app-esp32` — RLCD/e-ink glanceable subset (Class B)
## Phase 5 — Camera and inference · *separate task*
Deliberately 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.
## 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 — **blocked on gpsd in Phase 0**
- [ ] 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