Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.7 KiB
type, status, updated
| type | status | updated |
|---|---|---|
| plan | active | 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.
- PCAN-USB working as SocketCAN (out-of-tree
pcan.ko, netdev build) - Stable CAN names by udev:
can_pcan,can_onboard—canNorder raced at boot - Z27AG OBD-port CAN measured: 500 kbps, not gatewayed, 27 periodic IDs at
~890 frames/s;
can_pcancomes 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 - 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.
can-bridge— listen-only, timestamped frames onto the busrecorder— 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 signalsobd-poller— active OBD-II PIDs, single writer, rate-limitedgnss— 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-flutteris 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_adminsfrom 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, withlocalIdeographFontFamilyset 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