68 lines
2.6 KiB
Markdown
68 lines
2.6 KiB
Markdown
|
# 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 `can1` (out-of-tree `pcan.ko`, netdev build)
|
||
|
|
- [x] 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](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 `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](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
|