Circuit OS

The Dashboard

Inspiration

The TOYOTA GR Cup is a "spec series," meaning every driver races the exact same car—the GR86 Cup. In this environment, mechanical advantage is nonexistent; the only true competitive edge is data. However, a major gap exists between the data availability and its usability. Drivers generate gigabytes of telemetry, but they cannot analyze spreadsheets while driving at 120 mph.

We were inspired to bridge this gap by building a "Digital Race Engineer." We wanted to move beyond passive charts and create an active, strategic companion—Gazoo Razoo. Our goal was to answer the question: What if an AI could sit in the passenger seat, decode the telemetry in real-time, and whisper the winning strategy into the driver's ear?

What We Learned

Through the development of Gazoo Razoo, we learned that context is king in racing analytics.

Raw speed isn't everything: A fast lap is useless if it creates tire degradation that ruins the next ten laps. We learned to value consistency (via our "Driver DNA" module) as much as peak performance.
The "Human Factor" is quantifiable: We discovered that by analyzing the standard deviation of throttle application ($aps$) and braking pressure ($pbrake_f$), we could mathematically model a driver's psychological state, detecting stress or fatigue before it became a visible error.
Alert Fatigue is real: The most critical lesson was UI/UX design. A driver has milliseconds to process information. We learned to suppress raw data in favor of simple, actionable directives like "Defend High" or "Push Now."

How We Built It

We architected Gazoo Razoo as a full-stack real-time simulation platform using a modern tech stack:

1. The Backend (Python & FastAPI)

We built a robust analysis engine using Python and FastAPI to process the hackathon datasets (R1_vir_telemetry_data.csv, etc.). We treat these static CSVs as a live data stream, "replaying" them row-by-row to simulate a race environment.

Key libraries included:

Pandas & NumPy: For high-speed manipulation of telemetry vectors.
Scikit-learn: Used in our Overtake Probability Engine to calculate $P(pass)$, the probability of a successful overtake, based on corner exit speed and the gap to the car ahead.

2. The Algorithmic Modules

We developed specific algorithms for each racing scenario:

Driver DNA: We implemented a statistical model to classify driving styles (e.g., "Late Stomper" vs. "Smooth Roller") by analyzing the slope of the braking curve: $$\text{Slope} = \frac{\Delta pbrake}{\Delta t}$$ We then monitor live variance from this baseline to detect "over-driving".
Ghost & Guardian: We created a "Guardian" lap by stitching together the theoretical best sector times from all drivers, giving our user a "perfect" target to chase.

3. The Frontend (React & Shadcn UI)

The dashboard was built with React and styled using Shadcn UI for a clean, professional aesthetic. We utilized Recharts for visualizing the telemetry traces (Speed, Brake, Throttle) and created custom components for the "Track Grip" and "Overtake Probability" widgets.

Challenges We Faced

Simulating Real-Time constraints: Adapting static historical data to behave like a live WebSocket stream was difficult. We had to ensure our API responded instantly to "current lap" queries without leaking future data.
Defining "Optimal" Gear Shifts: We struggled initially to determine the "correct" gear for every corner. We solved this by building a lookup table that maps vehicle speed to gear usage from the top 10 fastest laps, flagging any deviation as a "Gear Mismatch" error.
Noise in Telemetry: The sensors (accelerometers and potentiometers) are noisy. We had to implement smoothing algorithms to prevent our "Overtake Probability" model from firing false positives due to micro-fluctuations in speed data.