Third Place Solution in Summer 2026 Simulation Racing Series

Written by Tate Wamola, a junior at Mountain View High School. Tate’s solution for the Monza Map v1.1 timed at 320.15 s over three laps.

Repository: https://github.com/tatewamola-web/roar-summer2026-submission

Introduction

I entered the Summer 2026 series with no prior ROAR experience. I began by analyzing one of the winning solutions from the Spring 2026 competition, the first-place entry by Racing Cognition (Advay Bansal, James Farmer, Jacob Lam), which races Monza in 320.40 s and which the organizers encourage competitors to study and build on.

Reading through it, what stood out was how much of its speed came from tuned constants rather than from the control algorithm itself. It reflects three seasons of accumulated work: pure-pursuit lateral control, a radius-based speed controller, and extensive hand-tuning by successive teams. I used it as my reference point and set out to find where, if anywhere, time still remained in it.

Most of what I tried did not work. The structural changes I attempted, a new racing line, a
physics-based speed profile, and smoother throttle application, were all slower than the baseline. What did work was building measurement infrastructure careful enough to detect improvements smaller than the run-to-run noise, and discovering that such noise existed at all.

Development

Telemetry: What Limits the Car

Before changing anything, I instrumented a full race and logged per-tick throttle, brake, speed and position. Two figures shaped everything afterwards:

The car is acceleration-limited rather than grip-limited. For most of the lap it is at full throttle and still gaining speed, running well below the cornering speed its own friction model would permit. Grip only binds for a few ticks per lap, in four braking zones.

This turned out to predict the outcome of nearly every experiment that followed.

Racing Line Optimization (Crash, or No Gain)

The obvious structural improvement is a better racing line. Both previous winning repositories contain TUM’s global_racetrajectory_optimization package unused, in an experimental folder. I got it running, which required five compatibility fixes for current NumPy and SciPy versions, and generated optimized lines.

Each variant failed. A full minimum-curvature line crash-looped on the pit straight. Constraining it to a corridor near the proven path did not help. Even pinning sections 0 and 1 exactly to the baseline, and moving only the grip-limited corners, still produced crashes further around the lap.

The cause is worth recording: the speed controller is tightly coupled to the exact line. It reads roughly 300 waypoints ahead to place braking points, so moving the line anywhere perturbs the speed profile upstream of that point and invalidates hand-tuned brake timings, including in sections whose geometry was unchanged. The line and the controller are effectively one artifact.

The ceiling here was low regardless. Given 1.8 m of freedom, the optimizer moved the line at most 1.17 m, suggesting the baseline’s line is already close to curvature-optimal.

Track Limits (Informative, but Not Exploitable)

To find whether the line had room at all, I wrote a probe that drives the baseline controller with a fixed lateral offset and logs the collision sensor, mapping the true drivable width. There is over 2 m of unused room on both sides of the line almost everywhere, the exception being the first chicane, where barriers sit about 2 m from the centerline despite a nominal 12 m width. Those barriers explain the crashes above. The available room, however, lies in
acceleration-limited sections where a wider line cannot help, while the one genuinely constrained corner is where extra room would have been useful.

Physics-Based Speed Profile (10 s Per Lap Slower)

I fitted a vehicle model from telemetry, covering acceleration, braking and lateral limits against speed, and computed a forward-backward optimal speed profile from it. The result was 116.8 s per lap, against the baseline’s actual 106.8 s.

The fitted model is ten seconds a lap slower than the hand-tuned values. The simulator permits harder cornering and acceleration than a conservative fit predicts, so model-based planning would have slowed the car down. This matches the Spring 2026 team’s observation that physics-first approaches underperformed, and suggests that in this simulator empirical calibration is more productive than modelling.

Throttle Smoothing (349 s)

Since the telemetry showed entirely binary throttle, I tried rate-limiting the control output to smooth weight transfer. Smoothing the throttle lift and brake application produced crashes, as gentler braking overshoots the tuned brake points. Smoothing only the throttle rise, leaving braking instant, finished in 349.15 s, about 29 s slower.

Both results follow from the acceleration limit. The car benefits from maximum throttle immediately, and any cap costs acceleration across most of the lap with no traction benefit in return.

Parameter Search

With structural changes exhausted, the remaining option was systematic tuning of the same constants the baseline authors tuned by hand. I built a harness for it:

Parallel evaluation, with several CARLA servers on separate RPC ports, each racing a different configuration under its own per-port lifecycle.
True headless operation. -RenderOffScreen does work on this Monza build; an
earlier crash I had attributed to headless mode was actually caused by
quality-level=Low, passed alongside it. Removing the render contexts eliminated GPU contention and roughly doubled throughput.
Stall detection. Some configurations crash-loop indefinitely, and a fixed timeout wastes a worker for its full window, so the harness monitors the waypoint counter and stops a race after 150 s without progress. File size is not a usable signal, since a stuck car still writes a log line every tick.
Coordinate search across 30 parameters, covering per-section friction coefficients, steering multipliers, brake pulse shaping and throttle constants, with a Hooke-Jeeves pattern move to catch gains that require two parameters to move together.

This ran 339 evaluations and converged on a configuration timing 320.05 s.

Run-to-Run Variance

That figure was misleading, and the reason is the most useful thing I learned.

Early on I had checked determinism by re-racing the baseline, which returned 320.40 s every time, and assumed this held for all configurations. Re-racing candidates five times each showed otherwise:

With structural changes exhausted, the remaining option was systematic tuning of the same constants the baseline authors tuned by hand. I built a harness for it:

Parallel evaluation, with several CARLA servers on separate RPC ports, each racing a different configuration under its own per-port lifecycle.
True headless operation. -RenderOffScreen does work on this Monza build; an
earlier crash I had attributed to headless mode was actually caused by
quality-level=Low, passed alongside it. Removing the render contexts
eliminated GPU contention and roughly doubled throughput.
Stall detection. Some configurations crash-loop indefinitely, and a fixed
timeout wastes a worker for its full window, so the harness monitors the
waypoint counter and stops a race after 150 s without progress. File size is
not a usable signal, since a stuck car still writes a log line every tick.
Coordinate search across 30 parameters, covering per-section friction
coefficients, steering multipliers, brake pulse shaping and throttle
constants, with a Hooke-Jeeves pattern move to catch gains that require two
parameters to move together.

This ran 339 evaluations and converged on a configuration timing 320.05 s.

The baseline is highly repeatable. Tuned configurations are not. The likely mechanism is the brake pulse calculation, `round(speed_excess / brake_ticks_div)`. At the tuned value of 2.5 the quotient lands on rounding boundaries more often than at the default 3.0, so a floating-point difference on the order of 1e-13 can change a brake duration by a whole tick.

The consequence is that run-to-run spread, up to 0.30 s, is the same size as the differences the search was trying to measure. Evaluating one race per configuration had been partly ranking noise.

I re-validated the leading candidates with repeated runs and ranked them by median instead. This changed the answer. The configuration I had already committed as my submission ranked first on single samples and second to last on medians:

I selected on median and stability rather than best sample. The chosen configuration’s slowest observed run was faster than any other candidate’s median, and its 0.05 s spread was the tightest I measured on a tuned configuration. That seemed a better bet than a faster single sample with a wide spread, which is more likely to disappoint on unfamiliar hardware.

Results

Four constants differ from the Spring 2026 baseline:

The official evaluation returned 320.15 s. On my own machine, across five repeated runs, the same configuration had a median of 320.05 s and a range of 320.05 to 320.10 s, against 320.40 s for the baseline.

I mention the small difference because it illustrates the point above rather than contradicting it. A configuration measured at 320.05 s locally returning 320.15 s under evaluation is consistent with the sensitivity I found, and it is the reason I chose the most stable candidate rather than the fastest single sample. The attached video, recorded from the chase camera, is timed at 320.25 s; capturing 6,405 frames adds work per tick, and recorded runs came in slightly slower than clean ones.

Summary of the approaches attempted:

Conclusion

The contribution here is not a new control algorithm, but a measurement method and the finding that made it necessary.

There are three main findings from my work. First, measuring the car before theorising about it was worthwhile: a short telemetry run showed it is acceleration-limited, which correctly anticipated the failure of every line-related and grip-related idea I tried afterwards. Second, this simulator appears to reward empirical calibration over modelling, since a reasonable
physics model was ten seconds a lap slower than hand-tuned values. Third, determinism is worth checking per configuration rather than once: the baseline is repeatable, tuned configurations are not, and their variance is comparable to the gains being sought.

That last point may be relevant to how close recent seasons have been. At this level of tuning, the difference between two good solutions can be smaller than the variation between two runs of the same solution.

My thanks to the Racing Cognition team for open-sourcing the solution I built on, and to the ROAR organizers for running the series.