• 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

Third Place Solution in Summer 2025 Simulation Racing Series

Title: Developing a Collision Avoidance System to ROAR Simulation Racing Series

Written by Youssef Khalafalla, a senior at John C Kimball High School, on behalf of Kimball Jags.

Table of Contents

Abstract

Fine tuning existing solutions for Robot Open Autonomous Simulation Racing at UC Berkeley was based on increasing target speed and decreasing brakes. The tuning successfully increased the average speed but increased crash rates also. A Collision Avoidance System (CAS) was developed to reduce the collision rate. Track boundaries were constructed by offsetting the centerline by half the road width. The CAS relied on calculating the Time till Collision (TTC) with the track boundaries and activating controls necessary to avoid the collision in case the TTC is below a specified threshold. Applying the CAS in the manner described in this study reduced crash rate from 30% to 7%.

Introduction

Robot Open Autonomous Racing (ROAR) program at the University of California Berkeley coordinates the efforts of electrical, computer, and mechanical engineers to develop autonomous driving algorithms and offers research and educational programming to develop knowledge for students in schools up to the PhD level [1].

ROAR organizes simulation racing in the fall, spring, and summer of each year and provides a Python-based racing simulation environment that allows contenders to race their autonomous AI agents. Contenders can fully train and test their AI algorithms without any vehicle hardware in this series utilizing the CARLA simulator [2]. In this paper, we present the third-place solution for Summer 2025 Simulation Racing.

Background

The race was performed on the official Berkeley Monza Map v1.1 [3] for the sixth time. The difference between the first and the second rank the first time the race was performed on this map was 8% of the completion time. The difference between the same ranks was reduced to 0.1% in Spring 2025, indicating the progress in refining the solutions over the past five races. Improvements by participants included refining the way points, steering, braking, and throttle controls.

Objectives

Our solution’s objective was to reduce the completion time from that of previous races, reduce crash rate, and to introduce new methodology that allows future improvement. The challenge was that previous races on the same track indicated that contenders have refined the solution to the extent that the differences in completion time between the first three ranks was less than 1% of the completion time. It was understood that refining previous solutions is possible but will not be adequate. Introducing new features was essential to make sure the improvement is consistent.

Solution

The submitted solution relied on improving the BHS Racing [4] solution that achieved first place for Fall 2024, with the intention of improving completion time. Initially, new code was written to simplify the base and avoid accumulation of edits. We also modified the solution to include the weighted average vector of waypoints for steering as developed by George Zeng [5]. This algorithm allows the controller to constantly calculate a weighted average of the waypoints ahead giving higher priority to closer waypoints. Although this adjustment provided more logical steering behavior it did not improve the completion time or reduce the crash rate. We finally decided not to include it in our solution.

We considered improving the waypoints, throttle, braking, and steering control to achieve the stated objectives.

Optimization

In order to achieve a better understanding of the performance of CARLA along the track, the speed was plotted against time for a complete run comprised of three laps (Fig. 1). BHS [4] solution divided the track into 10 sections as shown in Fig. 2. These sections are shown by the vertical lines racing in Fig. 1. The track was plotted showing the areas where brakes were applied (Fig. 3)

Fig. 1. Variation of Speed against time for BHS

The data points of each tick including throttle, steering, speed, brakes, and acceleration were examined. The figures and data indicate that the reduction of speed from its maximum values as shown in Fig.1 is a result of turns as much as brakes. The brakes were applied only at relatively short intervals. We also noticed that both throttle and brake values are mostly either 0 or 1.

Fig. 2 Monza Track - Numbering of Sections
Fig. 3. Speed and Throttle/Brake activation along the route

After examining the waypoints and steering as modified by BHS Racing [4], we found that there is little improvement that could be achieved by modifying their waypoints, and it was decided to concentrate on increasing speed and reducing brakes before turns.

Modifications

The target speed is calculated by the equation by BHS Racing:

Speed could be increased by changing the variables affecting the target speed.  After several trials, we found that the simplest way is to increase the target speed is to add a specific constant to the equation.  We found that the best value for the constant is 1, as shown in the following modified equation for the target speed:

Increasing the value of the added constant above 1 did not provide additional improvement to the finish time. 

The second stage was using neural networks to reduce the value of brakes.  The solution was to allow the AI to modify the value of the brakes for each section separately by multiplying the braking value by a reduction multiplier, because each section had its special boundary conditions including radius of turns and the point/speed of entry and exit in and out of the section.

The AI ended with the brake multipliers  shown in Table I. 

The adjustments described above reduced the run completion time to a mean of 321.6 sec (with a range of results between 321.45 sec to 322.2), compared to 322.35 sec for the original BHS solution. 

Collision Avoidance System (CAS)

The reduction in completion time caused the crash rate to increase to around 30% of runs compared to the BHS reported 5% crash rate.  It was clear that any increase in speed needed to reduce the completion time will be accompanied by a significant increase in crash rate.  The crash was caused by the lateral slide of the car in turns that led to the car hitting the side of the road.

We decided to Collision Avoidance System (CAS)

The reduction in completion time caused the crash rate to increase to around 30% of runs compared to the BHS reported 5% crash rate.   

The Collision Avoidance System (CAS) is designed to prevent the simulated vehicle from colliding with racetrack boundaries by continuously monitoring the distance to the nearest wall and adjusting the car’s trajectory when necessary. In place of LiDAR or radar sensors, which were unavailable through the CARLA API, the CAS relies on a custom ray casting approach to detect wall proximity.  Since the vehicle is modeled as a rigid rectangular shape moving along a two-dimensional track, the CAS operates by estimating how close the car’s exterior is to the walls in the direction of its current motion. A critical component of this system is the computation of the Time till Collision (TTC), which is defined as the distance to the wall divided by the car’s current velocity. If the TTC drops below a constant threshold, the CAS is activated and performs specified actions to prevent collision.

This method begins by constructing left and right track edges based on the centerline waypoints. By offsetting the centerline laterally with a constant half-width, two polylines are generated that represent the physical walls. From the car’s center, a ray is cast in the direction of its velocity vector (or heading, if velocity is near zero). The ray–wall intersection is then computed against each wall segment. The earliest valid intersection provides the predicted collision point and distance (Fig. 4).

Fig. 4. Dimensions for CAS

Raycasting is critical because it provides a geometric substitute for sensor data. After identifying the center-to-wall hit distance, the CAS adjusts this by subtracting the projection of the car’s half-length and half-width along the ray direction, ensuring that clearance is measured from the vehicle’s exterior and not from its center. This yields a realistic collision distance that can be used for TTC calculations. In this way, CAS effectively simulates environmental sensing without needing native CARLA LiDAR or radar support.

The value of TTC is given by the equation

The implemented CAS was triggered when the TTC is less than a specified value, and applied the brakes. It was noted that once CAS activates the vehicle is already too close to the wall, and braking not only fails to prevent the collision but also induces additional sliding, reducing the ability to reorient.  The first modification was to implement a hybrid approach of braking and swerving followed by maximum throttle. The idea was to exploit slippage to rotate the vehicle rapidly until its orientation diverged more than sixty degrees from the wall, at which point maximum throttle would change its trajectory. However, in practice, the car continued to slip for several ticks after the maneuver, resulting in worse performance than simply steering away without braking or throttle modulation. As a result, the final CAS strategy is to apply steering adjustments alone once TTC falls below the threshold, ensuring rapid and stable avoidance of the wall.  This adjustment resulted in notable reduction of the crash rate.

The final stage was to fine tune the CAS by adjusting the value of the time to crash TTC that is needed to trigger the CAS.  Increasing the value of the trigger time increased total completion time because of steering away from the way points before the risk of crash was very high, and in some cases cause crash at a later section because the CAS steer-away effect causes the car to enter the next section from an unfavorable position.
It was noted that the crashes happened in sections 3 and 5, and in laps 2 and 3 only. Therefore, it was decided to operate the CAS in these sections only.  Moreover, the value of the time triggering the CAS was varied between these sections based on results from trials to make sure it is at the minimum value required to reduce the crash rate while keeping disruption to the route minimal.  The final values for the CAS trigger time are shown in Table 2.  These values triggered the CAS for a maximum of two ticks, and in most cases only one tick.  The CAS was triggered in 70% of the runs, and in laps 2 or 3 only.

The application of CAS in the manner described reduced the crash rate from 30% to 7% of the runs.  After the fine tuning of the CAS triggering times, CAS did not increase the completion time. There was no correlation between triggering of CAS and completion time.

Conclusion

Fine tuning of target speed and brake reduction using neural networks reduced the completion time to an average of 321.6 sec with a range of results in various runs between 321.45 sec to 322.2 sec.  The applied CAS kept the crash rate low despite increasing the average speed.

Future development should cover using the neural networks to adjust the brake values and target speed while the CAS is implemented. The reduction of crash rate by CAS is expected to allow additional increase of average speed.

The CAS itself could be improved by calculating the Time till Collision based on the distance between the wall and the car center in a direction perpendicular to the wall, instead of the direction of the velocity vector.

Another area of development is to investigate the reason for the relatively wide variance of completion time, noting that CAS operation did not have a measurable effect on completion time.

Acknowledgements

The author is grateful to UC Berkeley ROAR program which introduced myself and other students to autonomous driving programing.  Special thanks to Dr. Allen Yang and Mr. Huo Chao Kuan for their guidance and mentorship.

References

    • “Robot Open Autonomous Racing (ROAR™),” https://roar.berkeley.edu/
    • Dosovitskiy, G. Ros, F. Codevilla, et al., “CARLA: An open urban driving simulator,” in Proceedings of the 1st Annual Conference on Robot Learning, ser. Proceedings of Machine Learning Research, S. Levine, V. Vanhoucke, and K. Goldberg, Eds., vol. 78. PMLR, 13–15 Nov 2017, pp. 1–16. [Online]. https://proceedings.mlr.press/v78/dosovitskiy17a.html
    • “Monza Map,” https://roar.berkeley.edu/monza-map/
    • “First Place Solution in Fall 2024 Simulation Racing Series,” https://roar.berkeley.edu/first-place-solution-in-fall-2024-simulation-racing-series/
    • “First Place Solution in Spring 2025 Simulation Racing Series,” https://roar.berkeley.edu/first-place-solution-in-spring-2025-simulation-racing-series/

Primary Sidebar

Recent News

  • Fall 2025 Simulation Racing Series Results
  • Announcing 2026 ROAR Ambassadors
  • Fall 2025 ROAR Simulation Racing Series Competition
  • 2026 ROAR Ambassador Applications due Oct. 1
  • Contact
  • FHL Vive Center
  • Berkeley Engineering
  • UC Berkeley
  • linkedin
  • youtube
  • facebook
  • instagram
  • Privacy
  • Accessibility
  • Nondiscrimination

© 2026 UC Regents  |  Log in

 

Loading Comments...