Project architecture for how every agent works
Event workflow showing how every event can be simulated

Inspiration

During our research in both the applied ML domain (part of academic research) and literature review for this project, we discovered that deep learning approaches like Recurrent Feed Forward neural networks and LSTMs work great as numerical solvers and simulators for time dependent differential equations representing seasonal, constraint based patterns. Data driven and constraint based simulations have been practiced extensively by one of our teammates an example of which can be found in this preprint about how time dependent Schrodinger equation can be solved using a feed forward network to simulate the behavior of quantum particles : https://www.researchgate.net/profile/Arpit-Goel-14/publication/394354557_Neural_Simulation_of_Quantum_Interactions_in_a_Confined_System/links/6893b3b9c8f8b1083fa3397c/Neural-Simulation-of-Quantum-Interactions-in-a-Confined-System.pdf

These patterns are similar to the strategies Formula teams employ per lap. The only thing is, instead of being seasonal in the time domain, these patterns emerge in the space (distance) domain. This was observed in F1 telemetric data where every approaching corner and every straight is reflected in the speed and throttle by breaking and speed ups respectively. These distance domain features can be simulated using such neural network based approaches and then easily converted into the time domain for the function of speed wrt time (discretized) and therefore the distance w.r.t time function. This distance with respect to time function can help us determine who (at any given time) takes the lead.

Note: Full pitch deck attached in the links provided

What it does

Since we have the core technology (in theory) to simulate the telemetry of a race (after some observation period ofc), we can indirectly simulate the race's outcome and also high resolution (time resolution) position data.

Basically

Our system is capable of helping teams simulate races in real time (even while a race is going on) while modeling the car's health, events (planned and unplanned, observed in data and input based) and monitoring the vehicles' capabilities.

How the simulation will work algorithmically

Now we need to include the framework to model events into this network (hereby referred to as the baseline simulator) based simulation. It is important to note that the Baseline simulator is trained to only predict what every lap should look like. It models degradation of tires and fuel reserves to suggest possible pit stops but that's about all the events it can logically have the power to simulate. Events like the safety car coming out, or the teams' strategists calling pitstops can happen without event correlation in the data and we need to give the user the ability to mark such events, we also need to enable the system to shift its control to a separate more specialized framework capable of simulating such events.

In cases like these, specialized simulators from the data will be employed. If from the live data, an event flag (like an opponent's team going into pit) is observed, the simulation agent for that team, will shift into the pit simulation module for that team and will model the most likely time spent in the pit, entry conditions and exit conditions (based on previous data ofc). Such events also have the power to update the simulation hyper parameters. For example, refueling during the pit will reset the agent's fuel consumption counter, and a change of tires will reset the tire health to maximum possible efficiency factors for the given set of tires. These hyperparameters help the simulator to stay within realistic limits by modeling car health and performance over a race. These parameters are also updated regularly through out the race from observed live data.

Once any event is completed, the control is given back to the Baseline Simulator and the log of the event is stored in the final evaluation matrix for calculation of position.

The math and logic behind hypermeters

RPM, Throttle and Gears

We can easily simulate the RPM, gear and the Throttle, they are the easiest to simulate because throttle shows low variance, gear is a categorical quantity and RPM can be tied mathematically to Throttle and Gear.

Logically speaking, there must exist a relationship between throttle, gear and RPM that states

\[ R = f(T \mid G) \]

in most realistic mechanical machines, this is relationship is modeled as \[ R(T, G) = \frac{v(T) \cdot k}{r_G} \] where the gear ration \(r_G\) is a hyper parameter that we need to observe from data and affects the ranges of the numbers the baseline simulator simulates.

Speed Calculation

After we simulate the features mentioned above, it is necessary to model the speed from these parameters. Now, due to us living in a world that isn't created by my class 11 physics teacher , the kind of acceleration we expect the throttle to produce isn't actually the acceleration because friction, tire health and other adversary features affect the acceleration that the car actually takes. We may model this difference in features as a type of an efficiency problem as follows : \[ \alpha = \frac{a_{\text{obs}}}{a_{\text{theo}}} \] this also applies to speed \[ \alpha = \frac{v_{\text{act}}}{v_{\text{exp}}} \] this factor \( \alpha \) depends on the type and deration of tires, the overall health of the car and the track conditions, which is why it is best observed during the race live. Every pit stop resets this factor to its observes (or possible given conditions) highest limits and observes the short time right after reset, for any mismatches and observes them to model the actual value and progression of these adversary features.

Finally

Once all that is done and dusted, calculating the speed as a function of the distance. Given the speed wrt distance distribution, it can very easily be converted into the time domain, and then used to calculate the distance travelled on the track as a function of time.

This time dependent distance function can be used to simulate the podium (at every instant and the end of the race) like the challenge asked.

How we plan to build it

The main challenge in building this system is building the machine learning model that acts as the baseline simulator. The Simulation methodology in itself looks concrete only if the model learns the seasonal patterns of every track and every driver. It also has to be light weight and quick so teams don't have to wait the entire lap just to see what the simulator predicted for the lap. In other words, its latency for simulating the entire race should be less than at most 10 data pings made to the model.

To address this issue, we propose using a transfer learning approach and trading storage space for time efficiency. We will train the same type of model for different tracks and one simulator for each team (agent) so every simulator runs independently with the ability to run sequentially. Additionally, specializing the simulator to just one track allows us to us less dense and data heavy models which are much faster to run.

Here is the proposed plan for building this thing

Where We Get the Data

We use the fastF1 api to find telemetric data, we use the features we need to simulate using the model like throttle, gear, rpm, drs and use them in the space domain for the simulation.

This reserve also contains the data for speed, position and time per lap, making it an extremely rich data source and suitable for this application.

How the model works

The model simulates the next step of the data given all the observed data, and then uses its own prediction as input for the next step. In simple words, the model autoregressively predicts the race lap by lap, with the stopping condition set to number of laps.

This model forecasts the throttle, RPM, DRS as values scaled between 0 to 1. The values are scaled to actual values using conversion ranges which are observed from the data during training, and in practice, observed during the live feed. These ranges also fall under the list of computational hyper parameters that were discussed earlier.

These quantities are then used to calculate forecasted speed which is converted into the time domain and used to calculate the function of distance wrt time that we ultimately desire. Please note that the model only predicts the forecasting features, the rest is calculated using mathematics logic because, it very easily can be. This solution fits most elegantly to the problem statement because it uses concrete math and engineering where required. Such a setup avoids over engineering and chances of a miss fit. It also allows us to have a more explainable setup which we can interpret better.

Training Strategy (Transfer Learning approach)

As mentioned countless times, the task that we train the model for is kind of like an autoregressive time series forecasting but with distance. Say, a distance series which is a sequential/temporal sequence of data in distance (instead of time). This forecasting will be done for Throttle, RPM, DRS, and gear.

We start out by training one model for every track. This is because every track shows its own seasonality features as discussed before. This allows us to not have to worry about larger models capable of detecting the kind of track were racing on. Once that is done, the model knows the generalized setting of the track and knows what the strategy should be for every turn, corner, break and straight.

Then, we use this model and fine tune it for every driver on that specific track. This allows the model to better understand the team's strategy and the driver's skill sets. This new fine tuned model acts as the brain for the agent representing the driver with the capability to simulate the data according to what they are most likely to do.

Loss Functions

Since it is essential to include constraints to keep the simulation realistic, all the hyper parameter features and update algorithms for them used to create the training environment. The ultimate goal is to create the simulation using our model of the race math as close to the reality as possible.

Due to this requirement our primary loss function should be the mean squared error loss over the forecasted quantities.

Additionally, the calculated speed from these forecasted quantities will also be subjected to the same loss function from the observed data.

Since there are very real relationships between RPM, gear and throttle at any given time, we'll also be enforcing the function we previously used to describe this relationship into the loss function, to keep the simulation grounded by actual physics at every time stamp (or distance stamp).

The algorithm isn't trained on who wins, its trained on what they do and how they do it.

Challenges we ran into

The main challenge was the mathematics and the mechanical physics involved in understanding and modeling the F1 car behavior. As a team of data scientists and engineers we had to hit the books, and utilize all the physics we have learnt during our education.

The training methodology for the challenge was also a tough challenge. We had the algorithm but repurposing it for a distance series and training in two domain (time and space) was a challenge and a differential nightmare. Luckily the core algorithm was designed to work on Physics Informed Neural Networks and gave us a lot of leverage with the same.

What's next for us

We hope you like the core idea and the design of the system. If you have any questions about how this works, please feel free to reach out to any member of our team. We hope that this solution was unique and concrete enough to get an invitation to the final round. Please also refer to the drive link provided in the "Try it out links" for a better visual summary of this idea.