The Optimal Racing Line

I've recently reached the stage in the TORCS-Adaptive project in which I need to consider implementing some more sophisticated performance measurement than simply monitoring the player/AI driver's speed. I stumbled across a rather dated but still very relevant series produced by Brian Beckman, PhD, named The Physics of Racing. There were many useful articles here, however Part 4 and Part 5 were the most relevant to this project. Part 4 of the series introduces the idea of centripetal force (centre-seeking force), and is able to produce an equation from which we can derive the maximum driving speed for a given arc radius. I won't go into the details here - those interested can see the link at the bottom of this post - but ultimately the equation derives to:

Where v is the maximum possible velocity, a is the sideways acceleration and r is the radius of the curve. Here we can see that the radius is being used almost as a scalar for the velocity - the sideways acceleration multiplied by the radius gives the maximum possible velocity. Therefore we an infer that the optimal corner arc in terms of speed alone is in fact the one with the largest possible radius. The diagram below has been adapted from the diagram shown in The Physics of Racing Part 5:

Here, w is the width of the track and W is the width of the track minus half of the car's width. When considering the optimal path we are considering the trajectory of the car's centre of mass as opposed to the paths of individual wheels. Therefore, the width of the track is slightly lower to prevent the car dragging it's wheels off the sides. The optimal path can be seen here as Line M, the line that passes through points E, Q and X. Two more sub-optimal lines that hug the sides of the track are shown for sake of example, Line o and Line i. Ro and Ri are the inner and outer radii of the curve, and also happen to be respective to the arc radius of the curves in Line o and Line i. If Ri is the radius of the curve of line i and K is the radius of Line M, it can be seen that the speed possible on Line M is far greater.

References:
Beckman, B. (1993) The Physics of Racing [online] Available at: http://phors.locost7.info/contents.htm

TORCS-Adaptive Progress

I've been making some progress recently on TORCS-Adaptive, my final year project at the University of Lincoln. Thus far, I've managed to implement procedurally generated tracks into TORCS, that now function both in console racing mode and in graphical mode. The generation of new 3D models when adding new track segments still has some performance issues, however I've manage to set up a pipeline in which performance measurement and adaptive difficulty algorithms can be easily tested and analysed using AI drivers. Currently, I have a very simple AI driver set up. In order to build a completely random track, I use the 'Procedural' race mode. When in the runtime/runtimed folder, it is possible to run TORCS in console mode on Windows as follows:

This will run TORCS in the console, with the race manager contained in procedural.xml. This file can either be modified directly in a text editor, or the race can be set up within TORCS itself and it will be saved. At the end of the race, there is now a feature of the procedural library that builds the entire track, and writes it's data out to a .txt file with data readable by gnuplot. Gnuplot allows the user to then plot this track, with results such as the following:

This image shows a plot of the entire track, with accurate scaling. The values on the X and Y axis are both in metres. 

TORCS Adaptive Real-Time Tracks

Since my last post I've managed to get a prototype of the track generation system up and running. It currently generates and loads an entirely new model file for each segment that is added to the track, running through TORCS' existing track generation functions. These functions have all been exported to a static library, and the client has access to these functions to enable what you see in the video below.

As can be seen, this is not the most efficient method for track generation at run-time within TORCS. It does however prove that it is possible without drastic changes to the existing framework. Possible optimizations would be to only generate a single track segment's AC3D file, and somehow merge this with the existing file. However, it is not yet clear where the computationally expensive part of this process is. It may be that removing and re-attaching the node containing the track from the scene graph is expensive, or it may be the track generation itself. This needs to be further explored before deciding on how it could be optimized.

TORCS Adaptive

For my final year project at the University of Lincoln, I am currently modifying TORCS (The Open Source Racing Car Simulator) to generate tracks at runtime. It is then intended that these tracks will adapt to the skill of the player, depending on several performance measures. The project is currently in it's very early stages, but some simple run-time track generation has been implemented alongside some telemetric functionality, though these values are not yet used in any kind of performance measure. The following videos show some of the current features.

This video shows telemetry printing data to the console at runtime about the current car. The car here is one of the 'robots' that come with TORCS, which are compiled AI drivers written in C++.

This video shows a single track segment that has been generated completely at runtime. TORCS stores all of it's 3D models, including tracks, in AC3D files. Here, a segment has been generated at runtime and an AC3D file generated for it all during the runtime of the application. The next step is to find a way to update the existing AC3D file with new segment data each time a new segment is added.

The project's Github page can be found here, and more information can be found on it's wiki.