project-yukart/docs/ROADMAP.md

type, status, updated

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

• PCAN-USB working as SocketCAN (out-of-tree pcan.ko, netdev build)
• Stable CAN names by udev: can_pcan, can_onboard — canN order raced at boot
• 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
• SIM7600G-H-M.2 specified and documented
• SIM7600 LTE data path: QMI (self-built qmi_wwan), povo, metered, ranked below Ethernet/WiFi; failover tested, Tailscale stays reachable over LTE
• SIM7600 GNSS via gpsd (/dev/sim7600-gps): 3D fix in the car
• Kernel-update procedure for the out-of-tree modules (pcan, qmi_wwan) — documented, sources kept in ~/infra; still manual, and breaks silently if forgotten
• Network time pinned to NICT; timezone Asia/Tokyo
• 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.

Phase 1 — Capture

Get real Z27AG traffic onto disk before designing anything around it.

• 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, 2026-10-12: mosquitto 2.0.11 on the car Orin, localhost only. First publisher orin-status (svc-core, yukart/host/*); svc-gw subscribes and serves it to the tablet
• Confirm MQTT holds up at real CAN rates (yukart/can/raw), 2026-10-12: no loss at a saturated bus, per frame or in 10 ms batches; batched costs the broker ~1 % of a core (svc-core BUS-BENCH.md)
• 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)
• 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)

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 (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