graymarshall.dev portfolio
Back to index
In Development/2025 — Present

In-Vehicle Driver Dash System.

Multi-Screen Real-Time Driver Display for the LHRE FSAE Car

FIG. · dash
Year 2025 — PresentStatus In DevelopmentStackReactTypeScriptRustWebSocketsMQTTCAN BusProtobufReal-TimeMonorepo
I.
Summary
Overview

A real-time in-vehicle driver display for Longhorn Racing Electric's FSAE car. Speed, SOC, pack temperature, lap delta + per-second delta rate, energy delta, brake bias, and driver-armable flags (traction control, regen) on a multi-screen UI that cycles Driving → Pit Diagnostic → Shutdown → Settings. Two data planes feed it: a Rust on-car backend (`dashd`) forwarding CAN over WebSocket, and a typed MQTT contract for off-car-computed lap and energy values. A built-in demo mode synthesizes the full data stream so the same dash runs off-car for development, presentation, and judging.

II.
Breakdown
Highlights
  1. I.Four-screen in-vehicle UI (Driving / Pit Diagnostic / Shutdown / Settings) cycled with an on-wheel button input — 800×480 target.
  2. II.Two data planes wired in lockstep — Rust `dashd` on-car forwards CAN signals over WebSocket, off-car compute publishes lap/energy values to typed MQTT topics.
  3. III.On-car renderer stays simple by design — anything that needs history (lap reconstruction, energy prediction, lap-delta-rate) is computed off-car and arrives over MQTT, leaving the dash as a stateless 30 Hz painter of last-known values.
III.
Margin
Notes
  • §Multi-screen architecture (Driving / Pit Diagnostic / Shutdown / Settings) cycled with an on-wheel button input — same `DashContext` + data hooks back every screen, so screens compose cleanly without per-screen wiring.
  • §Driving screen tuned for one-glance reads: oversized speed digit, ±0.5 s/s lap-delta-rate bar pinned at the top, energy delta with decimal-point dead-center anchoring to stop digit jitter, bidirectional power bar split 20% regen / 80% drive, dual sidebar gauges for SOC and pack temperature with thermal color-shift at 50 °C.
  • §Dual data planes — Rust `dashd` on-car forwards CAN signals (speed, power, SOC, cell-top temp, shutdown circuit) over WebSocket; off-car compute publishes lap delta, energy delta, and laps-remaining to `lhre/dash/*` MQTT topics per a typed contract, with QoS 0 and a 5-second staleness fallback to `--` so the driver never sees frozen values.
  • §Wire format is one schema with two implementations — Rust serde structs in `dashd` (`CanData`, `MqttData`, `DashMessage`) carry explicit `#[serde(rename)]` annotations so JSON keys line up byte-for-byte with the TypeScript interfaces in `DashData.ts` on the renderer. The schema is the contract; no ad-hoc parsing on either side, and adding a field is one coordinated change across both files.
  • §On-car reliability layer — `dashd` resets the CAN frame to all-default after 3 seconds without a fresh `cand` snapshot (so unwired or absent signals render `--`), the WebSocket renderer auto-reconnects on every drop with infinite retries at 1 Hz, and a monotonic `seq` field persists across reconnects so the frontend can detect skips. The dash is built to fail to `--`, not to last-known values.
  • §Pit Diagnostic screen for pre-/post-session checks (APPS, BPPS, brake pressures front/rear, motor / inverter / coolant temps, pack max cell temp, wheel speeds, active faults) plus an alerts overlay that latches on high cell temp (>55 °C) and any shutdown-circuit fault.
By the numbers
4
screens
800×480
res
30 Hz
render