project-yukart/docs/ROADMAP.md

type, status, updated

type	status	updated
plan	active	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.

• PCAN-USB working as SocketCAN can1 (out-of-tree pcan.ko, netdev build)
• 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.

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 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
• app-esp32 — RLCD/e-ink glanceable subset. Deferred, no hardware in scope

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; code in svc-nav (runtime) and tool-mapmint (artifact builds).

• 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