Lap Lens

Racing telemetry made simple. Compare laps, analyze corners, find speed - built for Toyota GR Cup drivers.

Comment

Inspiration

This project began as a hackathon initiative utilizing Toyota GR Cup racing data. We saw all this telemetry sitting there - lap times, speeds, corner data - but no easy way to actually understand it. Drivers finish a session and just get a lap time. They don't know if they're slow in the hairpin or losing speed on the corner exit. Pro racing teams have software for this, but it costs a fortune. We thought it'd be cool to build something that makes the data actually readable and useful.

What it does

Lap Lens takes telemetry from Toyota GR Cup races and breaks it down corner by corner. Pick any driver, and you can see:

  • Speed through every corner - entry, apex, exit
  • Time gained or lost compared to the fastest driver
  • Sector breakdowns across the whole lap
  • Side-by-side comparison of up to 5 drivers
  • Corner leaderboard showing who's fastest through each specific turn

How we built it

Started simple - just wanted to show one driver's performance compared to the fastest lap. Built that with Python/FastAPI on the backend, Next.js, and React on the frontend. Got the basic corner-by-corner breakdown working first. Then we added charts with Recharts to visualize the speed differences. Way easier to see where someone's losing time when you can actually look at a graph instead of reading numbers.

After that, we kept adding features - the corner leaderboard to see who's fastest through each specific turn, driver comparison to stack multiple drivers side-by-side, and PDF export so people can save their analysis. Each one made the app more useful.

Everything was working great locally. Then we tried deploying to free hosting, and it completely died. Telemetry files are massive, and Render's free tier only has 512MB of RAM. Loading and processing all that data on every request? Instant crash.

Had to completely rethink it. Ended up pre-computing all the analysis locally, saving everything as JSON files, and dumping them on S3. Now the app just loads the pre-calculated results instead of crunching numbers every time someone loads a page. Way faster and actually works on the free tier.

The data pipeline takes CSV exports (lap times, sector splits, full telemetry), runs corner detection using speed + steering angle + g-forces to identify real corners, then generates comparisons against the reference driver.

For deployment, we used Render(https://render.com) for both backend and frontend.

Challenges we ran into

  1. Memory was a nightmare. First version? Dead on arrival. Just loading the telemetry would kill the server. Took us multiple tries to figure out the pre-computation approach.
  2. The server would completely hang when users requested analysis. Telemetry processing takes time, and if someone refreshed the page or clicked away, the request would still be running in the background. Had to add abort controllers so requests actually cancel when users navigate away. Otherwise, we'd have 10 zombie processes eating up all the resources.
  3. Some cars had zero telemetry even though they finished the race. Transponders failed or whatever. Had to build a backup system using just sector times for those cases. In some cases, the data is not relevant enough to be able to deduce an in depth analysis for the driver.
  4. Corner detection was harder than we thought. Can't just look for "car going slow" because that could be traffic or a yellow flag. Had to use steering angle and lateral g's to actually identify real corners.

Accomplishments that we're proud of

  1. Got it running on completely free hosting - Render for backend, S3 for data. Zero monthly costs.
  2. The pre-computation thing actually worked. We were pretty sure it would solve the memory issue, but not 100%; actually, it did.
  3. Not all the data is created equal. Some cars had full telemetry, others just had sector times. Can't assume every data source will be complete - need fallbacks.

What we learned

  1. Don't overthink it. We tried to build this fancy real-time processing pipeline when batch processing was obviously the right call. Wasted time there.
  2. Also learned that pandas is really good at eating RAM if you're not careful. Had to get smarter about how we load data.

What's next for Lap Lens

  1. Track map visualization - Show an interactive track layout with the racing line overlaid. Color-code different sections based on speed so you can see performance zones at a glance. Makes it way easier to understand the data when you can see it on the actual track instead of just charts.
  2. We want to add a Redis caching layer that would improve the overall performance of the system.
  3. Weather and track conditions - Factor in temperature and track grip so you're not comparing a cold morning lap to a hot afternoon lap.

The main goal is to make telemetry analysis accessible. Right now, it's either crazy expensive software or nothing. We want to fix that.

Built With

Share this project:

Updates