Chasing the 80-Second Lap: Evolving an Autonomous F1 Car in TORCS

Team: Please Don’t Crash | University: Queen Mary University of London

Solo Team: Darien Da Costa

Standing Lap time: 1:20.09 (80.09s)

• with generic fully fuelled IBM AI race league standard F1 ow1 car in TORCS

First Blog(Getting to 1:23.61): https://medium.com/@darien.dcosta/building-and-optimizing-an-autonomous-f1-car-in-torcs-9ee84ad063be

In my previous update for the IBM AI Racing League, my autonomous TORCS F1 car had achieved a standing lap time of 1:23.61 on the notoriously difficult Laguna Seca (Corkscrew) circuit. I had successfully replaced a sluggish Computer Vision setup with a lightweight array of depth sensors, using Bayesian Optimization (Optuna’s TPE) to tune my proportional controllers.

But in racing, 1:23.61 wasn’t the finish line. I wanted to see how far a purely reactive, mapless control system could be pushed. Over the following weeks, by fundamentally overhauling the control architecture, analyzing telemetry data, and experimenting with Evolutionary Algorithms, I managed to shave another 3.34 seconds off the time, achieving an 80.09s standing lap.

Here is the technical breakdown of how I pushed the bot to its absolute limit without relying on neural networks or pre-computed track maps.

Hitting the Architectural Limit and the ABS Breakthrough

Before overhauling my code, I wanted to see if my original P-controller setup had any remaining potential. I set up Optuna TPE to run over 5,000 trials overnight, hoping to brute-force a better lap time through parameter tuning alone. When the optimizer completely flatlined and failed to beat 83.61s, I realized the architecture itself was the bottleneck.

To figure out exactly where my logic was failing, I used IBM Granite to analyze my existing codebase. It highlighted the mathematical limitations of relying solely on proportional logic for high-speed dynamic environments, guiding me toward upgrading the systems to Proportional-Derivative (PD) and Proportional-Integral-Derivative (PID) controllers.

By running a highly focused Bayesian Optimization search on my newly implemented speed and braking parameters, I discovered that the key to speed wasn’t just raw throttle, but Anti-Lock Braking (ABS). I tuned an ABS PID controller that detected wheel lock-up and rapidly modulated brake pressure. This prevented flat-spotting and allowed the car to brake incredibly late and aggressively. Because the bot could now survive later braking, the optimizer drastically increased the base speed multipliers. The car was suddenly hurtling through turns at a much greater speed.

This upgrade alone shattered my previous record, bringing the lap time down to 80.91s.

Phase 6: Dynamic Racing Lines Using Only Sensors

In professional racing, cars don’t drive down the center of the track; they utilize the “racing line” (outside-inside-outside). Because my strict rule for this project was no pre-computed track maps, I had to engineer a way for the bot to find the racing line organically.

I introduced a logic system that dynamically shifts the car’s target position based purely on the 19 ray-cast depth sensors. On corner entry, the bot shifts its target inward toward the apex; on exit, it drifts wide. I combined this with a mid-corner penalty system that dynamically scaled with speed, and an aggressive engine-braking logic that forced downshifts during heavy deceleration.

This dropped the time to 80.48s.

Phase 7: Telemetry Analysis and Structural Fixes

At this point, throwing more parameters at the optimizer wasn’t helping. I had to look at the raw telemetry to find bottlenecks.

First, I realized my standing start launch control was flawed. The code was locking the car in 1st gear for a full 50 simulator steps to prevent early shifting. However, telemetry showed the car was hitting the rev-limiter within 15 steps, meaning I was bouncing off the limiter and wasting acceleration for nearly a full second. I reduced the 1st-gear lock to 15 steps, letting the shifting logic take over earlier while maintaining full throttle.

Second, I generated extensive telemetry logs during my laps and fed the raw data into IBM Granite for analysis. By parsing the data, Granite helped me pinpoint a critical edge case in the bot’s corner-exit logic. As the car transitioned out of the final turn and onto the finish straight, the reactive look-ahead sensors were causing a momentary hesitation, leading to a brief but costly period of unnecessary braking. I patched this edge case to ensure the controller seamlessly committed to full throttle the moment the track opened up.

These structural code fixes brought the time down to 80.35s.

Phase 8: Exploring CMA-ES for the Final Polish

To squeeze out the final milliseconds, I initially ran my Optuna TPE optimizer again to search across 45 different parameters. However, TPE is fundamentally designed for global exploration. It has a tendency to wander across wide probability spaces, sometimes testing highly unstable parameter combinations that were too fragile to survive outside the simulation sandbox.

I wanted to expand my skillset and try a different method for local fine-tuning. I consulted IBM Granite to learn about advanced optimization strategies, and it helped me break down how CMA-ES (Covariance Matrix Adaptation Evolution Strategy) works under the hood. I realized its mathematical approach to modelling variable correlations was exactly what I needed for this specific problem.

Unlike TPE, which guesses across a wide probability space, CMA-ES takes a known “good” setup and breeds a population of slight genetic variations around it. I gave the algorithm incredibly tight boundaries (±10% of my best v7 parameters) and a tiny step size (σ=0.05) across only the 14 most impactful variables.

This forced the optimizer to act as a precision scalpel. CMA-ES excelled at modelling correlations— learning that if it widened the racing line exit offset, it mathematically had to slightly increase the steering damping to maintain stability.

This experiment paid off beautifully. It meticulously refined my setup, bringing my final standing lap time to 1:20.09.

What Didn’t Work (Engineering is about what you discard)

During this journey, several “great ideas” completely failed in practice:

• The Kamm Circle (Friction Ellipse): Attempting to dynamically limit braking based on lateral steering (to mimic real-world tire physics) clashed with my reactive PD controllers and cost me time.
• Physics-Based Braking (v²=u²+2as): Trying to calculate exact braking distances conflicted horribly with the reactive system, causing severe oscillation and adding 5 seconds to the lap time.
• Short-Shifting: Upshifting early (at 15,000 RPM) to prevent wheelspin out of corners dropped the RPMs too low in the next gear, robbing the car of necessary exit power.

The Takeaway

Dropping from 83.61s to 80.09s required an entirely different philosophy than my first attempts. It required a multi-stage optimization pipeline: Bayesian Optimization (TPE) to globally explore the unknown, manual telemetry analysis guided by IBM Granite to fix structural logic, and Evolutionary Algorithms (CMA-ES) to exploit the final fractions of a second.

This project proved that you don’t necessarily need complex computer vision or pre-computed track memorization to achieve high-performance autonomous driving. With a clean array of sensors, deeply tuned PD/PID controllers, smart AI-assisted analysis, and a localized optimization pipeline, a purely reactive system can navigate the track with incredible precision.

Bot Gameplay (Standing Lap Time: 01:20.09) :

[embed]Standing lap time: 1:20.09

[embed]Technical Defence