• Skip to main content
  • Skip to primary navigation
  • Skip to primary sidebar
Header Search Widget
Robot Open Autonomous Racing (ROAR™)
  • ROAR Home
  • Programs
    • AI Racing Tech
    • ROAR GO
    • ROAR Academy
    • Ambassadors Program
  • News
  • Simulation Racing
    • Maps
    • Past Results
    • Blog
  • Support Us
  • Contact

Opening the Corner: Late-Apex Line Widening and Per-SectionGrip Tuning for the ROAR Monza Simulation Race

First Place Solution in the Summer 2026 Simulation Racing Series

Written by Micah Chen and Conrad Lumsden of Hong Kong International School, on behalf of HKIS Racing (Micah Chen, Conrad Lumsden, Eric Hong, Noah Yiu).

Code: https://github.com/micahc123/roar2026

Table of Contents

Abstract

The winning entry in the Summer 2026 ROAR simulation race completed three laps of the Berkeley Monza map in 319.65 s with zero collisions, 0.20 s ahead of second place in a field of 22. The entry is derived from the publicly available University High School controller [6], which runs 321.25 s as given. Two changes account for the improvement. First, the friction coefficient that caps corner speed was tuned one track section at a time against a live CARLA server, because a global increase of even 2 % produced an immediate DNF. Second, and more importantly, four corners of the hand-built racing line were reshaped into a late-apex form using a raised-cosine lateral displacement that leaves the line continuous. Opening the radius of the tightest of these corners by 17 % raised the corner speed the grip model permits, and also moved the grip limit itself, so a friction value that had previously
been pinned could be raised again. Three offline tools were built so that the seven-minute live runs were spent only on candidates whose direction and magnitude had already been settled geometrically. Forty-one further parametric configurations, covering braking shape, braking distance, steering authority, lookahead, waypoint averaging, the hairpin, and the standing start, were measured and found null or unsafe; they are reported here so that they are not repeated.

Introduction

The University of California, Berkeley Robot Open Autonomous Racing (ROAR) program, part of the FHL Vive Center for Enhanced Reality in the College of Engineering, introduces students to autonomous driving algorithms and organizes three simulation races a year [1]. Each race is run in CARLA 0.9.12 [9] on the Berkeley Monza map v1.1 [5] with a Tesla Model 3 vehicle model. A submission drives three laps under a fixed 0.05 s control step; a major collision resets the car to the start of the lap, so a single crash costs a full lap. This paper presents the approach behind the first-place submission in the Summer 2026 race [2].

Background

Convergence of the field

Times on the Monza map have converged. In Spring 2026 the top three finishers were within 0.40 s of each other and the top seven within 2.0 s [3]. In Summer 2026, thirteen of 22 entries finished within 2.0 s of the winner, and the top five within 0.60 s [2]. The Kimball Jags Fall 2025 report reached the same conclusion for the earlier season and responded with an outcome-driven learning loop over the grip coefficient [4]. The approach reported here is complementary: rather than search the existing parameter space more efficiently, it changes the geometry the parameters act on.

Provenance of the base controller

This entry is derived from the public ROAR_1_S25 repository by University High School (second place Spring 2025, first place Fall 2025) [6]. That code is the starting point for the steering and throttle controllers, the section timing, and the hand-built racing line. It carries no licence file, so all rights remain with its authors; it is used with credit and no claim of original authorship. The competition-supplied runner and infrastructure files are byte-identical to the official starter repository. Measured on our hardware, the base controller as given runs 321.25 s. A recorded reference run of the same controller, supplied as telemetry, runs 321.70 s.

Architecture of the base controller

The track is divided into ten sections at fixed waypoint indices. Each section is, in practice, a straight plus a single corner (Table 1). The car is steered by pure pursuit [8] toward a lookahead point that is chosen from the raw map waypoints, averaged over a speed-dependent window, and then snapped onto a separate hand-built racing line of 5,865 points. Sections 0 and 9 do not snap to the line and follow the raw waypoints directly. The pure-pursuit steering command is scaled by a per-section multiplier ladder tuned by the original authors.

Speed is governed by a grip model. For each of several lookahead distances (30, 60 and 90 m, with wider spacings above 100 km/h) the controller computes the Menger radius R of three upcoming waypoints and converts it to a target speed

where g is gravitational acceleration and μs is a friction coefficient specific to the current section. The permitted speed at distance d from that corner is

with KB = 825, which fixes how late the car brakes. The smallest vmax over all lookahead probes is compared with the current speed, and a latched brake counter converts the excess into a number of ticks of full braking. Section 3 is routed to a second throttle model with its own grip constant and a distance-based deceleration curve.

Minimum radius is the Menger radius over a ±30 m window along the raw waypoints, computed by analysis/section_radius.py. A flying lap is 104.65 s; lap 1 is about 5.75 s slower because the car launches from rest and spends 437 ticks in section 0 against 322 on a flying lap.

Instrumentation and measurement protocol

Tuning hooks

Every run against the live server takes about seven minutes, so the first change was to make runs cheap to configure. Twenty-one environment variables were added that override tuning constants at import time without editing source: a global grip scale and per-section grip overrides, the braking constant KB, four braking-shape constants, a per-section steering multiplier, the set of sections that bypass the racing line, the lookahead scale, per-section waypoint-averaging counts and shift caps, the two hand-placed brake-event trigger speeds, the launch throttle cap, the gear divisor, and the line-widening specification described below. All default to the shipped values, so the competition submission is unaffected. This allowed a PowerShell battery to sweep configurations unattended, restarting the runner for each, with every collision and every waypoint reached written to a log. A live lap timer was added to the solution’s step function. It prints the lap, cumulative time, section and speed once per simulated second, and a final scoreboard at exit; it counts control ticks at 0.05 s, so its figures match the official result exactly.

Protocol

Run-to-run variation on the stock line is about 0.3 s (320.20–320.55 s across repeats), so any single-run gain smaller than that was treated as noise until it repeated. Because a major collision respawns the car to the lap start and costs a whole lap, every candidate configuration was judged on its worst run rather than its best. One configuration ran 320.35 s clean twice and then crash-looped from the start on its third attempt; a candidate that is quick when lucky is worth less than a slower one that always finishes. CPU contention was also found to matter: a game running in the background produced six consecutive DNFs during testing and nearly caused a good configuration to be discarded.

Offline tools

Three scripts were written so that live runs were spent only on candidates that geometry already favoured:

  • section_radius.py prints the Menger radius profile along each section. It showed that every section is a straight plus one corner, so μs only ever acts over roughly 150 m of each section, and that sections 2 and 6 sit exactly on their grip limit while the other eight have room.
  • line_room.py compares the shipped racing line against recorded reference telemetry per side of the centreline, to find track width that has already been driven over cleanly. A path 3 m left and one 3 m right share no width, so a naive maximum of absolute offset invents room that is not there. It also costs each corner in ticks, so a candidate can be valued before it is run.
  • crash_atlas.py mines every logged collision into an empirical track boundary (Section 7).

Per-section grip tuning

The base controller uses μs = 2.75 by default with higher values on five sections. A global increase of 2 % is an immediate DNF because sections 2 and 6 are already on their limit, so each section was probed alone while the others were held. The resulting values are given in Table 2.

Section 9 holds the hairpin, and its low value sets the car up for the start-finish straight. Section 3 is served by the second throttle model, whose own grip constant is 3.6; the 3.36 entry in the main table is therefore not consulted in the shipped configuration, and the measured difference from 3.30 lies inside run-to-run noise. Grip tuning alone took the entry from 321.25 s to 320.30 s, deterministic across four runs.

Late-apex line widening

Motivation

With corner speed capped by grip, equation (1) leaves one lever: the radius R. The only way to go faster through a corner at fixed μs is to open its radius, which means using more of the track’s width. The obstacle is that no trustworthy track boundary is available: the map’s lane width is not meaningful and the OpenDRIVE surface rejects most of the drivable area. The line was therefore reshaped in small, measured steps, with the resulting radius computed offline before each live run.

Method

A widening specification is a list of windows (start, end, A) over the racing line. Within each window, every point pi is displaced along the local left-normal ni of the line by

where S is the window length in points and k the position within it. The raised-cosine weight wk is zero at both ends of the window and one at its centre, so the displaced line remains continuous and the pure-pursuit controller never sees a step. Positive A is a shift to the left. A wide-entry, tight-apex corner is produced by two adjacent windows of opposite sign: the entry window pushes the line outward and the apex window pulls it inward, with the
exit left untouched (Figure 1).

Shipped configuration

Four corners were opened (Table 3). The radii are the minimum Menger radius over a ±12 m window along the line, measured on the stock and widened lines by running the widening hook itself; they agree with the values recorded during tuning to within 0.2 m for section 2.

Section 2’s corner went from 167 to 165 ticks per lap. The line change took the entry from 320.30 s to 319.60–319.75 s.

Rules learned

  • Only the apex may move. The first attempt used a full outside-inside-outside shape with a third window at the corner exit. It crashed at line index 1527, 3.06 m off-line, because the car runs wide at the corner exit, not at the apex. Shifting the exit in either direction fails. Dropping the exit lobe costs no radius, because the apex sets the minimum. Entry displacement alone, without an apex lobe, gives no radius gain at all, which the offline radius computation established before a run was spent on it.
  • Magnitude is per-corner and the working window is narrow. Section 2 works at 0.9 m and produces 22 collisions at 1.2 m and 60 at 1.5 m. That clean dose-response is how a genuine track limit is distinguished from a bug in the hook. Sections 1, 3 and 6 were each written off after a single probe at 0.9 m; all three came good at 0.5 m or 0.3 m. A failed magnitude says nothing about the corner, only about that magnitude.
  • Lowering grip to compensate for a wider line makes it worse. Reducing μs on a widened corner produced 135 collisions: a slower entry reshapes the whole trajectory rather than merely trimming speed.
  • Fewer moving parts was not safer. Widening sections 2, 1 and 6 alone turned a 319.80 s but finished only two of four runs. Adding section 3’s widening and the section-2 grip increase made the configuration repeatable, eight clean runs in eight, rather than merely faster.

Grip unpinned by the new line

Section 2’s grip coefficient had been pinned at 3.35 and recorded as at its limit. That was true of the old line. Opening the corner by 17 % moved the constraint along with the radius, exactly as equation (1) predicts, and 3.45 now runs clean where it previously produced a DNF; 3.55 still fails. The effect scales with the radius change: sections 1, 3 and 6, whose radii grew by 4–11 %, stayed pinned (section 1 at 3.05 gave 4 collisions, section 6 at 3.50 a DNF). This coupling between line and grip is the reason the section-2 corner contributed more than its share of the final improvement.

An empirical track boundary from logged collisions

Ninety-five sweep logs held 3,226 major collisions, each stamped with the waypoint the car had reached. Cross-referenced against the widening specification that produced it, that is a direct measurement of how far the line maybe moved at each point before the car contacts something, which is exactly the boundary information that had been treated as unavailable.

Respawn loops must be filtered first. A configuration that crash-loops respawns at the lap start and re-crashes at the spawn point, so about 90 % of the raw count is one failure re-stamped at waypoints 0–59. Unfiltered, the data claims that section 0 causes 87 % of all crashes, which is an artifact. Counting only hits the car drove at least 250 waypoints to reach leaves 312 collisions (Table 4).

Sections 1 and 2 are where the track punishes the line, and they are the two corners that responded to widening. Sections 7 and 8 have never produced a collision and carry the lowest grip on the track, which suggested free speed. Pushed to μs = 4.4 on section 8, a 48 % increase, every run was clean and every run was the same speed, with section tick counts identical to baseline. Their targets already exceed what the car can reach, since section 8 spends its fast half on the 257 km/h limiter. A section that never crashes is never binding; it is not a source of free speed.

Negative results

Every parametric family was exhausted before the line was reshaped. Forty-one measured configurations were null or DNF; the families are recorded here because a negative result measured is worth more than an idea untested.

  • Braking shape. Halving the light-brake value from 0.6 to 0.3 produced identical section-by-section tick counts; that branch of the controller effectively never fires. The hysteresis speed change, brake-tick cap, brake-tick divisor and early-throttle threshold were likewise neutral or DNF. The controller is already saturated bang-
    bang.
  • Braking later. Raising KB to 835, 860 or 900 all DNF. The default 825 already implies a deceleration of about 32 m/s2 against a measured capability of 16–19 m/s2.
  • Steering authority. Sections 0, 1 and 8 were the only ones without a steering trim. Adding one is neutral on sections 1 and 8 and DNF on section 0.
  • Line snapping for sections 0 and 9. Enabling it changes nothing; section 9 holds at 202 ticks regardless, and moves one tick for a 10 % grip swing.
  • Waypoint averaging and lookahead. Section 9 averages zero points and that is load-bearing: smoothing the hairpin at all crashes the car. Scaling the lookahead by ±15 % DNFs in both directions, because it is co-tuned with the steering ladder.
  • The hand-placed brake events. The event at waypoint 2381 fires above 257 km/h against a 257.3 km/h limiter and is a measurable no-op; disabling it gives identical ticks. The event at waypoint 800 DNFs if moved later.
  • The hairpin. Section 9 (radius 20.8 m, 72 km/h, 83 ticks a lap) is the slowest point on the track. Since it ignores the racing line, the raw waypoints were shifted instead. 1.2 m of shift buys 1.3 % speed; the hairpin is slow because the track is tight there, not because the line is wrong. Section 0’s corner gave one tick, inside noise, and DNFs at 0.9 m.
  • The standing start. Lap 1 loses 5.75 s to the launch, so capping throttle off the line, as a traction-control launch would, looked promising. It made lap 1 monotonically worse: 110.35 s stock, 110.60 s at 0.40 throttle for 10 ticks, 110.65 s at 0.70 for 20 ticks, 110.85 s at 0.70 for 45 ticks. A clean dose-response in the wrong
    direction shows there is no recoverable wheelspin in this vehicle model. Changing the gear divisor gives a byte-identical lap 1, confirming the original authors’ note that gears have no effect.
  • The finish line. The race ends when the runner’s furthest-waypoint index comes within five of the end of its three-lap list, which is rotated to begin at the spawn; the line sits about 23 m past section 0’s last corner. There is no stretch where the car brakes for a corner it will never take.

Results

The final configuration ran eight consecutive clean runs, four in candidate verification and four in final validation with every tuning variable explicitly cleared, so that the tune is provably in the source and not leaking in from a sweep. The worst of the eight was 319.75 s.

Conclusion

A 1.60 s improvement over an already competitive base controller was obtained without touching the braking, steering, or lookahead logic, all of which proved to be at their limits. The gain came from tuning grip one section at a time and then from opening the radius of four corners with a continuous late-apex displacement of the racing line, which both raised the permitted corner speed directly and unpinned the grip coefficient on the corner that opened most. Three offline tools, a radius profiler, a per-side room finder, and a crash atlas, kept the seven-minute live runs for candidates whose direction and magnitude were already settled geometrically.

What remains is not cheap. Sections 0 and 9 never consult the racing line, and section 9 holds the hairpin, the slowest point on the track. Making them use the line measured neutral; making them faster would mean reshaping the raw waypoints with section 9’s steering ladder re-tuned alongside, since the two are co-tuned and every attempt to move one alone has failed. A learning loop of the kind reported by Kimball Jags [4] could be applied to the widening magnitudes, which are few, bounded, and have a clean dose-response, and would suit that method better than the grip coefficients do.

Acknowledgements

Dr. Allen Y. Yang and the ROAR team at UC Berkeley organize the series and maintain the Monza map. The authors of the University High School ROAR_1_S25 repository [6] built the controller and racing line that this entry starts from; that work is used here with credit. Eric Hong and Noah Yiu were the other members of HKIS Racing.

References

[1] “Robot Open Autonomous Racing (ROAR),” https://roar.berkeley.edu/

[2] “Summer 2026 Simulation Racing Series Results,” https://roar.berkeley.edu/summer-2026-simulation-racing-series-
results/

[3] “Spring 2026 Simulation Racing Series Results,” https://roar.berkeley.edu/spring-2026-simulation-racing-series-results/

[4] Y. Khalafalla, “Outcome-driven Optimization Loop for ROAR Simulation Racing Competition,” Second Place Solution in Fall 2025 Simulation Racing Series, https://roar.berkeley.edu/

[5] “Monza Map,” https://roar.berkeley.edu/monza-map/

[6] MightyMark3, “ROAR_1_S25,” University High School, https://github.com/MightyMark3/ROAR_1_S25

[7] “Summer 2026 ROAR Simulation Racing Series Competition,” https://roar.berkeley.edu/summer-2026-roar-simulation-
racing-series-competition/

[8] R. C. Coulter, “Implementation of the Pure Pursuit Path Tracking Algorithm,” Robotics Institute, Carnegie Mellon University, Tech. Rep. CMU-RI-TR-92-01, 1992.

[9] A. Dosovitskiy, G. Ros, F. Codevilla, A. López, and V. Koltun, “CARLA: An open urban driving simulator,” in Proc. 1st Annual Conference on Robot Learning, PMLR vol. 78, 2017, pp. 1–16. https://proceedings.mlr.press/v78/dosovitskiy17a.html

Primary Sidebar

Recent News

  • AI Racing Tech Places Third in the Indy Autonomous Challenge Laguna Seca 2026
  • Fall 2026 ROAR Simulation Racing Series Competition due Dec. 11, 2026
  • Summer 2026 Simulation Racing Series Results​
  • Summer 2026 ROAR Simulation Racing Series Competition due Aug. 21, 2026
  • Contact
  • FHL Vive Center
  • Berkeley Engineering
  • UC Berkeley
  • linkedin
  • youtube
  • facebook
  • instagram
  • Privacy
  • Accessibility
  • Nondiscrimination

© 2026 UC Regents  |  Log in