Files
project-yukart/docs/ROADMAP.md
T
2026-10-09 17:03:21 +09:00

105 lines
4.6 KiB
Markdown

---
type: plan
status: active
updated: 2026-10-09
---
# 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`
- [ ] 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)
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 — `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](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