Assessment of an Autonomous Racing Controller: A Case Study From the Indy Autonomous Challenge ’ s Simulation Race

Non-racing autonomous challenges

The first notable autonomous driving challenges were hosted by Defense Advanced Research Projects Agency (DARPA) from 2004 through 2007 (DARPA, 2014). Whereas the first two Grand Challenges focused on off-road autonomous driving, DARPA’s 2007 Urban Challenge was the first to be held in an urban setting. Held in Victorville, California, this challenge required 11 participating teams to design their own autonomous vehicles that could navigate through an urban environment containing marked lanes, traffic signs and signals, and other vehicles while obeying the rules of the road (Reinholtz et al., 2007). Following DARPA’s Urban Challenge, a number of organizations began to host their own challenges in Europe (McEachern, 2015), Asia (Hyundai Motor Group, 2014), the United States (SAE International, 2021), and virtually (Shell, 2021).

Autonomous racing challenges

As autonomous driving systems continue to evolve and gain increasing public awareness, numerous autonomous driving competitions have emerged seeking to push autonomous operations to the limit. These competitions require successful navigation of challenging tracks and require autonomous racers to operate at speeds much higher than those found on public roads. Beginning in 2005, Formula Student Germany is an ongoing event that includes the design of autonomous driving systems as part of its evaluation criteria (Formula Student Germany International Design Competition, n.d.). While teams did not race head-to-head, the autonomous performance of each team’s vehicle performance is evaluated through various scenarios and compared to the performance of other teams. Two other competitions, Roborace and Self Racing Cars, both began midway through the 2010s (Yvkoff, 2016;). Self-Racing Cars hosts amateur competitors who have modified their vehicles to navigate autonomously through a racetrack. As with Formula Student Germany, these modified vehicles do not directly compete but instead try to see which vehicle can achieve the lowest lap time. In contrast, Roborace has held a race in which two vehicles directly competed against each other on a real-world track (Tobin, 2019).

Applications of PID controllers for simulated vehicles

Within the industrial automation sector, it has long been estimated that 95% of all operations rely on closed-loop PID controllers (ELPROCUS, n.d.; Åström, 2002; Tejado et al., 2019). The widespread use of these controllers is largely attributed to their straightforward design and robustness that has enabled their usage as the technology used in the industry sector has changed over the past century (Åström, 2002). Concerning vehicles, numerous studies have implemented their own PID controllers for unmanned aerial vehicles (Salih et al., 2010; Kada & Ghazzawi, 2011; Müller et al., 2019, Najm & Ibraheem, 2019), simulated vehicles (Marino et al., 2011; Azar et al., 2019; Baskaran et al., 2019; El Hajjami et al., 2019), and real-world autonomous vehicle systems (Hoffman et al., 2007; Zhao et al, 2012).

One application of interest has been the use of PID controllers for simulated racing vehicles. As noted by Chen et al. (2021), the advantage of PID controllers is their ability to reduce computational load; this particular characteristic is significant for vehicles operating at high speeds. Recent studies have implemented customized PID controllers for high-speed longitudinal control systems (Gomes et al., 2017; Wang et al, 2018; Chen et al., 2020, 2021), lateral (steering) control systems (Armagan & Kumbasar, 2017; Zhang et al., 2018), and at least one previous study by Wang et al. (2021) has utilized two PID controllers for both longitudinal and lateral control. Generally, the results of these works found that PID controllers provided favorable results for simulated racing vehicles. In particular, PID controllers that were integrated with model predictive controllers or fuzzy logic controllers tended to perform the best in terms of balancing lateral and longitudinal vehicle states (Chen et al., 2021) and improving handling stability (Zhang et al., 2018).

Difficulties of designing autonomous driving systems

Designers face numerous challenges when designing autonomous driving systems. For real-world, public road applications, it is imperative to design a system that can make decisions on a level that is at least equivalent to an attentive and responsible driver. Past non-racing challenges assess systems by placing autonomous vehicles in mock environments that contain elements that a human driver would encounter on a typical commute (Bacha et al., 2008; Kammel et al., 2009; Burnett et al., 2019). Such elements include traffic signs and signals, pavement markings, intersections, and other vehicles (static and dynamic). Furthermore, designers must consider the rate at which sensors receive information about the vehicle’s environment while also accounting for any potential software errors that can contribute to a failure of operations.

The IAC and other racing challenges introduce the additional challenge of having an autonomous driving system operate at speeds well above the threshold for most human drivers. Designers must ensure that the selected sensors are capable of reliably collecting accurate information in a timely manner (Wischnewski et al., 2019). Similarly, the selected computational software should be capable of performing all required calculations as quickly as possible, and the software should be streamlined to reduce computational time while remaining flexible enough to promptly develop accommodations for unexpected changes to the vehicle’s surroundings (Andersen et al., 2020; Nekkah et al., 2020).

Simulation software

The simulation competition was conducted using the Ansys VRXPERIENCE (VRX) Driving Simulator. VRX is a physics-based simulator powered by SCANeR Studio that allows users to modify various aspects of the virtual environment, including the terrain, vehicles, and custom scenarios. The program’s user interface grants the user the ease of editing vehicle configurations as well as creating unique testing scenarios with a built-in pseudo-script editor. Furthermore, VRX can also be run using external scripts written in Python through the Data Distribution Service. This environment facilitated the testing of each team’s unique control systems in a manner that avoided damage to real-world vehicles or the IMS.

Vehicle model

The Dallara IL-15 is the vehicle model that was used by all teams for the simulation competition (see Figure 1). The files for this model were provided to each team since the real-world competition would be using this very same model of racing vehicle. Simulated vehicles were equipped with sensors (cameras, laser imaging detection and ranging [LiDAR], radar, and global navigation satellite system [GNSS]), and each vehicle could be controlled using VRX’s own default controller or using a custom controller. Information regarding the vehicle (e.g., lateral and longitudinal speed and acceleration, tire grip and forces, etc.) could be monitored directly via either VRX or RTI Connext.

Figure 1.

Illustration of (a) Dallara IL-15 model and (b) IMS recreated within VRX. IMS, Indianapolis Motor Speedway; VRX, VRXPERIENCE.

Racetrack model

The simulated environment consisted of a replication of the IMS. The simulation tracks latitude, longitude, and elevation values that match up with real-world values that were collected onsite by Ansys. Identical track values help ensure the realism of tests and the simulation race. A view of the racetrack modelled in VRX is shown in Figure 1.

Test scenarios and control system architecture

In order to ensure a successful performance within the final simulation race, the team’s controller needed to meet two key requirements. Firstly, high speed and low lap times are desirable in order to remain competitive with other racers. Second, the ego vehicle should have an awareness of its environment and should be able to avoid maneuvers that could result in a collision or veering off the track.

In order to design a control system that could meet these two requirements, two main scenarios were designed to test different components of the team’s custom vehicle controller. The first scenario, the Single Ego, contained a single simulated vehicle used to test and evaluate longitudinal and lateral controls in a basic environment. The second scenario, the Multi-Vehicle, contained four vehicles controlled by the custom controller racing against each other in order to test and evaluate obstacle avoidance and path planning portions of the main controller.

To this end, the team’s controller would be required to interpret sensor input data from and transmit commands to the VRX environment. This was accomplished by incorporating five distinct modules into the controller. The first module, Localization, was responsible for determining the global and local positioning of the vehicle, and it was dependent on sensor input data. The second module, Perception, also uses sensor input data to determine the road boundaries as well as for object detection. The next module, Path Planning, was dependent on the first two modules for determining the optimal race line that the ego vehicle will try to adhere to. The fourth module, Decision-making, was dependent on the previous three modules for obstacle avoidance and obstacle movement prediction. Finally, the Longitudinal and Lateral Control module takes the outputs of the four prior modules to determine the required throttle (or braking) and steering angle that will be transmitted to the VRX environment.

Because the longitudinal and lateral control module contains three sub-controllers, it should be noted that the use of the term “controller” from this point on refers to the overarching main control architecture that is presented in Figure 2. The sub-controllers that exist within this main controller are expanded upon in a later section of this paper.

Figure 2.

Overarching main controller architecture. GNSS, global navigation satellite system; VRX, VRXPERIENCE.

Due to the nature of the IAC’s Simulation Race, the Reveille Racing team did not need to spend time and resources on selecting sensors or computational hardware because these components were predetermined and uniform for all teams. Thus, the Reveille Racing team placed all of its focus on designing effective and robust software modules that could effectively handle a multitude of potential scenarios. To this end, the team’s goal was to develop a control architecture that could operate competitively at high speeds while simultaneously prioritizing safety.

In summary, the compartmentalization of the main control architecture was designed to allow the vehicle to autonomously assess its environment, evaluate its choices of action, and ultimately select the optimal action based on its assessments. An overview of the overarching main control architecture is provided in Figure 2, a list of the longitudinal and lateral controllers within the architecture is provided in Table 1, and the remaining sections discuss how the team’s control architecture and each longitudinal and lateral controller were designed in order to safely operate at high operating speeds.

Sensors

Each simulated vehicle is equipped with sensors that would be identical to the ones that would be included in the physical vehicle. The data from each sensor could be acquired and read using either a custom script or RTI Connext. Data from each simulated sensor was pre-processed by VRX; consequently, this eliminated the need to create custom code to interpret objects detected by each sensor. A summary of the sensors and their specifications are included in Table 2.

Perception

Camera, LiDAR, and radar sensors were used for perception. Each sensor provided pre-processed data, thus reducing the effort required by each team to interpret objects and track boundaries. After fusing the data from these sensors, the location of the track boundaries and all objects around the ego vehicle could be determined by the team’s control system.

For this competition, lane and object detection is handled by the Reveille Racing team’s perception module. VRX provides third-degree polynomial coefficients that can be used to identify the track boundaries that will be used for path planning. For objects (e.g., other vehicles), the camera sensor provides X and Y local coordinates originating from the point of installation on the simulated ego vehicle, and these local coordinates are then converted into VRX’s world coordinates as part of the localization process.

Localization

The coordinates of pre-processed sensor data provided by VRX have different origin points; each sensor is installed at a different location on the vehicle and with its own unique heading. In order to obtain accurate track boundaries and object positions, the local coordinates for each sensor had to be converted to match with the simulated ego vehicle’s VRX world coordinates. This conversion was performed by utilizing the simulated vehicle’s known position and the sensors’ local properties provided by VRX. By doing this, the local coordinates of detected boundaries and objects could be placed into a common world coordinate system with the ego vehicle.

Path planning

In order to be competitive with other teams, it was important to develop a controller that could determine potential race lines to follow. Furthermore, the designed control system would need to be able to handle areas where the main track would split off to the pit lane; these locations are referred to as blind spots because the camera sensors had difficulty correctly identifying the track boundaries at these locations. Figure 3 provides an overview of the path planning module.

Figure 3.

Overview of the path planning module.

The path planner takes in the ego vehicle’s location and track boundaries that were previously calculated with the localization and perception modules. The output of the path planner is a set of 10 potential waypoints or race lines. Out of those 10, the left- and rightmost candidates are immediately removed as potential race lines due to their closeness to the left and right boundaries, respectively. The decision to omit these race lines stems from the fact that following these two lines would result in the ego vehicle driving onto either the grass or into a wall. An illustration of the candidate race lines, as well as the prohibited race lines, is presented in Figure 4.

Figure 4.

Script generated candidate and prohibited race lines.

Decision-making

As the penultimate component in the Reveille Racing team’s control system, the decision-making module is tasked with processing the outputs of all the path planning, localization, and perception modules in order to determine the best course of action. The proposed module is designed to perform competitively while simultaneously maintaining safety as the highest priority. An overview of the decision-making process is shown in Figure 5.

Figure 5.

Overview of the decision-making module.

Once path-planning determines a set of 10 candidate race lines, the ego vehicle’s position is determined via localization, and the environment is assessed via perception (Step 1); the decision-making module considers the ego vehicle’s location on the track and determines an initial optimal target race line and target speed V_max (Steps 2–4). This part of the process is illustrated in Figure 5 where the target race line initially depends on whether the ego vehicle is in a straightaway or curved section. Next, the module considers whether or not any objects have been detected (Step 5). In the case in which no objects have been detected, the module outputs the final target race line and target speed (Steps 8–9).

On the other hand, if an object is detected, then the module next considers the object’s location in relation to the ego vehicle’s own location (Step 6). In the event that the detected object is not directly ahead of the ego but is located on the target race line and is located relatively nearby, then the ego vehicle adjusts the target race line to prevent colliding with the object (Step 6 ➔ Step 7b). If the object is on the target race line but is considerably far from the ego, then the ego vehicle makes no changes to its target race line (Step 6 ➔ Step 8). In either case, no changes are made to the target speed.

If the detected object is directly ahead of the ego and the ego vehicle is already on the target waypoint, then the module considers the object’s distance from the ego. If the object is considerably far from the ego and if the object’s speed V_obst is greater than the ego vehicle’s speed V_actual, then the ego vehicle is not prompted to adjust its race line (Step 6 ➔ Step 8). If the object is instead moving slower than the ego vehicle, or if the object is determined to be too close, then the decision-maker must evaluate its options for obstacle avoidance (Step 7a ➔ Step 8).

To further elaborate on obstacle avoidance (Step 7a), there are several checks that need to be performed in order to assess all possible maneuvers at any given instance. First, the controller determines the ego vehicle’s current race line. Next, the positions of all detected obstacles are processed, and the status of each race line is determined; each race line can be considered to be available or blocked depending on the position of detected obstacles or the distance to the track boundaries. Following this, the controller checks the heading of each obstacle, and all race lines that the obstacle appears to be driving toward are marked as undesirable to prevent the ego vehicle from a potential collision. After all potential race lines have been evaluated, the controller determines whether there are any suitable race lines that can be used to perform a takeover maneuver. In the event that a takeover is not feasible, the controller will prompt the ego vehicle to slow down to prevent a collision. If either the ego vehicle has performed a takeover and does not detect any other obstacles or it does not detect any obstacles to begin with, the controller will direct the ego vehicle to make its way around the track using the optimal race line.

Longitudinal and lateral controls

Three separate PID controllers designed to provide throttle, brake, and steering inputs control the ego vehicle’s longitudinal and lateral motions. Due to robustness and ease of implementation, PID controllers were selected to reduce the complexity of the control architecture while simultaneously providing a simple means for fine-tuning. A simple block diagram of the PID controller structure is provided in Figure 6 whereas an overview of how longitudinal and lateral control was handled by the Reveille Racing team’s controller is provided in Figure 7.

Figure 6.

Block diagram of PID controller structure. PID, proportional-integral-derivative.

Figure 7.

Longitudinal and lateral control module. PID, proportional-integral-derivative; VRX, VRXPERIENCE.

In order to obtain a command throttle or braking value, the speed’s PID controller requires both the target speed, V_target, and the ego vehicle’s current or actual speed, V_actual. Whereas V_actual can easily be obtained directly from VRX, V_target is dependent on whether the decision-making module has determined the need to slow down or to continue at the maximum speed, V_max. After assessing the simulated environment information (e.g., speed, steering wheel angle, cross-track error, GNSS positioning, LiDAR points), the decision-making module determines the need to slow down. More specifically, the action of slowing down was performed either by reducing throttle input or by braking. In instances in which braking was deemed unnecessary, then the V_target was set to 90% of the V_actual value; this value was selected based on empirical observations made while testing the controller. Although reducing V_target by more than 10% offered a greater safety buffer between the ego vehicle and nearby obstacles, this reduction to 90% of the V_actual resulted in the ego vehicle falling farther behind and negatively affected the observed lap times. This 10% reduction in speed offered a practical compromise that let the ego vehicle create a buffer between itself and the target while simultaneously preventing the ego vehicle from increasing its lap times. An overview of this framework is provided in Figure 8.

Figure 8.

Process for determining target speed. VRX, VRXPERIENCE.

Once both the V_actual and V_target are known, the controller selects Throttle if V_actual < V_target or the Brake PID if V_actual > V_target. The PID controller for the throttle and brake inputs both use the following models:

A PID controller is utilized for determining a steering angle δ_command and is presented in the following equation:

Figure 9.

Cross-track error measurement.

The final variables for Equations 1–3 were fine-tuned using a modified Ziegler-Nichols procedure (Ziegler & Nichols, 1942). Initially, K_P, K_I, and K_D were set to 0. K_P was increased until a steady oscillation was obtained; at this point, the critical gain K_U and peak-to-peak oscillation period T_U can both be obtained. Several simulation trials were run, and each variable was further tuned based on the vehicle’s performance. The final PID constants for Equations 1–3 are provided in Table 3.

Ansys hackathons

Ansys hosted three hackathon events in order for teams to assess their progress against one another before the simulation race. The first hackathon served as an introduction to the VRX program that all teams would be using to test their controllers. Competitive elements were not present for this particular event. This early event made it clear that there would be a significant amount of work to perform in the nine-month span between the first hackathon and the final simulation race.

The second hackathon required all teams to test their controllers to complete two tasks. The first task was simply to complete a lap as quickly as possible without exceeding track boundaries or colliding with the walls. This required teams to design controllers that could compute and run along an optimal race line. The second task was to avoid colliding with a reckless VRX-controlled vehicle that would suddenly swerve into the path of each team’s vehicle. Each team was scored based on their performance while completing the two tasks; the Reveille Racing team finished in 9th place out of 19 competitors. At this point, it was realized that the Reveille Racing team’s determined optimal race line needed to be updated because the selected race line failed to perform as well as the lines followed by other teams.

The third hackathon divided all of the remaining teams into groups of two. Each group would compete head-to-head in two sets of races with the objective of safely completing five laps as quickly as possible. While the Reveille Racing team was able to outperform its competitor in the first race, the team’s controller received a penalty due to a collision with the competing team in the second race. During the second race, the opposing team’s vehicle swerved frequently on its race line, and the race team’s vehicle drove too closely when overtaking the other team on a straight section. Ultimately, the race team finished in 12th place out of 18 competitors.

Final simulation challenge

All teams submitted their final controllers on or before May 19, 2021. At that point, Ansys spent the next month running the simulations using the submitted controllers and obtained the rankings for each team. The final challenge consisted of three parts: a qualifying lap, two head-to-head semi-final races between the qualifying teams, and a head-to-head race among the top seven teams based on the results from the semi-finals. On June 30, 2021, Ansys announced the results of the final simulation challenge.

For the qualifying lap portion of the challenge, each team was required to complete one full lap (approximately 2.5 miles) successfully. No other vehicles were present during each team’s qualifying lap. Penalties were awarded to teams that collided with walls or exceeded acceptable track boundaries. The Reveille Racing team placed 13th out of 16 competing teams with a lap time of 52.152 seconds, less than half a second behind the fastest lap time of 51.848 seconds.

The two semi-final races both hosted five teams as they competed for 10 laps (approximately 25 miles). Teams that collided with walls or other vehicles due to negligent maneuvers would be disqualified. During the first semi-final race, the race team began from the fifth-place position and performed a successful early overtake of the fourth-place team, maintaining this position for the remainder of the race. The race team finished in fourth place with a time of 508.58 seconds, 3.592 seconds slower than the first-place team.

For the final race, the race team began from the sixth-place position and performed a successful overtake in the last half of the first lap and can be seen from the opponent’s perspective in Figure 10. Throughout the remainder of the race, three of the seven teams would become disqualified due to collisions; one of these collisions occurred when another team’s vehicle collided with the Reveille Racing team’s car. Due to the circumstances of the collision, the Reveille Racing team was found not to be at fault and was allowed to continue the race. Ultimately, the race team completed the final 10 laps and finished in third place with a time of 458.74 seconds, 3.816 seconds slower than the first-place team.

Figure 10.

Opponent’s perspective of the racing team’s overtake maneuver (courtesy of Ansys).

Operational performance of control system

By the end of the third and final hackathon, it became clear that the race team’s control system would require substantial updates to its various components, especially the scripts pertaining to obstacle avoidance. In particular, obstacle avoidance at this point was more focused on avoiding objects on straightaways that were not making significant movements to the left or right; this became problematic when dealing with vehicles that behaved erratically. It was soon realized that the controller should behave more conservatively when deciding how to avoid obstacles and how much space to keep between itself and other vehicles. These changes are reflected in the controller architecture that was presented in the previous section of this paper. Performance data from two laps was collected directly from VRX. The performance along the length of the two laps was assessed according to the following metrics:

• •

  Speed: The speed of the vehicle (kph)

• •

  Steering wheel angle: The angle of the vehicle’s steering wheel (°)

• •

  Cross-track error: The error between the vehicle’s current position and the target race line (m)

• •

  G-G diagram: The performance envelope of the vehicle represented by the plotting of its longitudinal acceleration against its lateral acceleration (Gs)

To further assess the vehicle’s performance, the first three metrics are measured against the bank angle (°) of the track. It should be noted that the bank angle of the track is 0° in straight sections and negative at the corners. Furthermore, positive and negative bank angles correspond to right and left turns, respectively. Thus, because the track exclusively contains left turns, all bank angles at corners are negative.

The final speed performance for a single vehicle completing two laps is visualized in Figure 11.

Figure 11.

Speed performance for a single vehicle over two laps.

Figure 11 demonstrates that the final controller design is capable of sustaining speeds of nearly 300 kph (186 mph) with an average speed of 280 kph (174 mph) and a maximum speed of 298 kph (185 mph). In comparison, the top qualifier at the 2019 Indy Lights race held at the IMS had a maximum speed of 320 kph (198 mph) and an average speed of 312 kph (194 mph). The final controller’s performance in contrast to the top qualifying team indicates that there is still substantial room for improvement in terms of speed. This difference between performances is attributed to the final controller being more conservatively designed in contrast to other teams. More specifically, other teams placed more emphasis on following an optimal race line around the track as well as achieving more aggressive speeds when entering corners. The final lateral controller proposed in this paper instead focused on following a more conservative race line and opted for less aggressive speed choice at curves; this design choice is due to the aforementioned overtaking incident during Hackathon 3.

The system’s lateral control module was also evaluated over the distance it took a single vehicle to complete two laps. The steering wheel angle and the cross-track error produced by the steering PID controller are presented in Figure 12.

Figure 12.

(a) Steering wheel angle and (b) cross-track error for a single vehicle over two laps.

The final lateral control module proved to be effective at yielding cross-track error of no more than 4.7 meters from the desired waypoint. The largest cross-track error values were produced at points immediately after the ego vehicle exits turns 2 and 4 with a rapid correction and stabilization once the vehicle is within the straight sections of the track. As observed with the speed performance, the cross-track error plot indicates that there exists room to improve the vehicle’s lateral module. Deficiencies in the lateral module’s performance are due to the nature of the module being similar to a pure pursuit controller. With the exception of the command steering angle δ_command, the remainder of the lateral controller operates similarly to a simple pure pursuit controller (e.g., finding a desired point, calculating the angle to the desired point, and steering toward the desired point). For this reason, the lateral control module is vulnerable to oversteering at the corners of the track. Lastly, comparing the steering wheel angle with the cross-track error over the same distance reveals that the controller was more effective at steering into corners in contrast to steering out. This is supported by the fact that steer-in behavior corresponded to lower cross-track error when entering the corner versus the more abrupt steer-out behavior contributing to larger cross-track error at corner exit points.

In order to evaluate the final controller’s performance with respect to the theoretical limits of the vehicle, a G-G diagram was produced using the longitudinal and lateral acceleration values collected from the two laps. G-G diagrams are useful for visualizing the operational stability of a vehicle. More specifically, G-G diagrams illustrate how grip on the road is distributed. Generally, values within the envelope (boundaries of the diagram) are considered to be indicative of stable operation, values on the envelope are indicative of operations utilizing all available grip, and values outside of the envelope indicate instances of unstable conditions in which the tires exceed available grip. G-G diagrams can be further divided into regimes based on the actions being performed:

• -

  Pure acceleration: All grip dedicated to longitudinal acceleration

• -

  Pure braking: All grip dedicated to longitudinal braking

• -

  Pure right cornering: All grip dedicated to turning right

• -

  Pure left cornering: All grip dedicated to turning left

• -

  Combined acceleration out of a left turn (Quadrant I): Grip divided between acceleration and turning out of left

• -

  Combined acceleration out of a right turn (Quadrant II): Grip divided between acceleration and turning out of right

• -

  Trail braking going into right corner (Quadrant III): Grip divided between braking and turning right

• -

  Trail braking going into left corner (Quadrant IV): Grip divided between braking and turning left

The G-G diagram generated from the collected data is shown in Figure 13.

Figure 13.

G-G diagram of a single vehicle over two laps (format courtesy of OptimumG, 2019).

As indicated by the G-G diagram, the vehicle would experience over 2.5 Gs of lateral force while maneuvering the left turns of the track. Instances of Gs greater than 1 were experienced as the vehicle accelerated from its rolling start of 100 kph and most instances of pure longitudinal acceleration sustained values below 0.5 Gs. In the absence of right turns, lateral acceleration values that fall into the threshold of right turn cornering are instances in which the vehicle attempted to move to the right outer bound of the track. The absence of points in the pure braking regime was attributed to the decision-making process used by the vehicle. In particular, in the absence of any emergency situations, the vehicle will avoid braking in order to reduce speed loss and will instead slow down by reducing input to the throttle. Because the results in Figure 13 were obtained from a single-vehicle simulation, the vehicle did not encounter other moving vehicles that would need to be avoided by braking. In particular, data from the final race could not be accessed due to the nature of the simulation event being primarily handled by Ansys.

The G-G diagram supports the earlier claims that both the longitudinal and lateral control schemes could be improved. Specifically, the current controller does not make full use of the tires’ grip when attempting to accelerate out of a turn as indicated by the scarcity of points located in Quadrant I. This is indicative of less-than-optimal performance of the vehicle when attempting to re-enter the straight sections of the racetrack, which could be remedied by adjusting the controller to behave more aggressively when selecting speed at curve exit points. Furthermore, the lack of any points on the envelope’s boundaries indicates that some available grip goes unused. For instance, lack of points on the boundary within the pure left cornering regime is indicative that our vehicle could have operated safely at higher speeds while cornering but did not do so due to the controller’s conservative nature. Future work should attempt to tap into the unused grip to maximize the efficiency of the controller.

Despite not operating on its performance boundaries, the controller demonstrated safe high-speed operations in the presence of seven additional script-controlled opponents. Its conservative actions allowed for the simulated vehicle to safely navigate through curves with the aforementioned force of over 2.5 Gs while never reducing to less than 282 kph (175 mph). Figure 14 provides a still image taken during a test run to evaluate the controller’s performance.

Figure 14.

Eight script-controlled vehicles safely operating at high speeds while entering a corner.