Files
project-yukart/docs/ROADMAP.md
T
mikkeli 62ac7bd09d Populate design, architecture and repo layout docs
project-yukart becomes the code-free hub: overview, roadmap and cross-cutting
design only. Each app or app cluster gets its own repo, indexed from here.

- ARCHITECTURE.md: separate services over a message bus, with displays as bus
  subscribers so the directly-driven screen, Android client and ESP32 panel
  share one contract. Records CAN scope (listen-only + OBD-II as sole writer)
  and a decisions table for choices still in flux.
- REPOS.md: repo splitting rule, planned repos, naming, and Gitea template-repo
  policy (scaffolding only — no upstream link after instantiation).
- ROADMAP.md: phases 0-5, capture and decode before displays.

Bus choice (MQTT) is marked proposed pending a check against real CAN rates;
implementation language is still open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 09:22:35 +09:00

2.6 KiB

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 yukart-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 — Android client is the quickest to iterate on
  • yukart-hud — directly-driven screen (Class A)
  • yukart-esp32-display — 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.

Deferred

  • Live off-board telemetry over LTE — hardware is present, but local logging covers the current need
  • Any CAN transmission beyond OBD-II diagnostics