Canopy Race Engineering Challenge 2025

Earlier this year, Canopy hosted its inaugural Race Engineering Challenge for staff members only. The day included immense concentration and computation power, where individuals competed to engineer the fastest virtual car driven by Dynamic laptime simulation. While virtual driverless racing may never gather a mass audience, it is this process that top racing teams employ to make their real car faster behind the scenes. The variety of techniques employed were fascinating.

The one-day challenge comprised tuning ride height, flap, springs, anti-roll bars, weight distribution, camber, brake balance shaping and differential to achieve the quickest possible Barcelona laptime. To ensure the car remained legal and drivable, several heuristic constraints had to be satisfied for bottoming, balance, stiffness and camber.

Petaflops of human intelligence performing optimisation…

Early Surprises

Embarrassingly for our so called “experts”, Lizzie our COO, and honorary engineer through osmosis, completed the task in record time, demonstrating the ease of use of our Canopy web application. Lizzie nearly took the prize, had her entry not been for the disqualified for failing the bottoming test by a wafer thin 0.2mm of front ride height. Please direct your vehicle dynamics questions to her in future!

Bottoming caused this car to be disqualified.

Too many variables

The challenge deliberately included more dimensions than could be solved using a single exploration.

Explorations can be used to run large design of experiments (DOE) but too many input dimensions results in a ridiculous number of simulations.

The Winning Strategy

The winners used their VD knowledge to identify the most sensitive parameters, diligently chipping away at laptime before fine tuning less crucial parameters. This approach is familiar to most Canopy users. It delivered incremental improvements from each batch of simulations run, with fallback options to guarantee a legal submission at every stage. This resulted in a race winning car ready in time for the qualifying deadline.

Extreme Vehicle Dynamics Approach

The most interesting results came from two opposite ideological approaches which failed to deliver a car within the deadline.

The first of these was to identify direct relationships between allowable tuning parameters and the problem constraints, for example bottoming is primarily affected by front ride height and spring stiffness even though there are other parameters that contribute to a lesser degree. This broke the problem down into manageable sets of parameters where trends and promising directions could be chased.

Extreme Brute Force

The quickest car came from the opposite approach, an API optimisation. The parameters were swept with no implied knowledge of what they did. Illegal results were discarded from the results, then the gradient of laptime with respect to each parameter was used to narrow down the ranges for the next sweep.

Python workbook: https://github.com/CanopySimulations/canopy-python-examples/blob/master/race_eng_challenge.ipynb

While failing to meet the deadline, it would be easy to automate this process for the next circuit or adapt to a different range of inputs using the generated code.

The script is available in our canopy-python-examples repository. I have no python knowledge yet find it relatively straightforward to understand and adapt to a specific use case. Click “Open in Colab”, and it can be run directly in your web browser. You can then “Run all” and enter your credentials. I would urge you to have a play with this kind of interaction, as it is useful for automating common tasks in Canopy. We would love to hear your feedback on it.

The Results

The winning submissions that passed all the legality, balance, and ride heuristics employed a familiar approach. The winner delivered a staggering 351ms of performance from a day of work.

A flabbergasting result came from our COO. After tweaking her car with +0.2mm front ride height to pass the bottoming constraint, it ended up 452ms quicker.

The showstopper came the next morning, an enormous 2534ms found using the API to run constrained optimisation overnight. Despite all the careful preparation for this challenge, I wondered if someone might find a loophole…

Suspicious…

Despite touting the immense advantages of using Canopy simulations to make your car go faster, 2.5sec does seem a little unrealistic…

A sign error in the tyre model (my user input error I should point out, not a modelling mistake), resulted in the tyres picking up grip with reduced (negative) camber. This put anyone employing a VD approach at a distinct disadvantage. It would be reasonable to expect that a winning car might approach manufacturer-imposed limits for end of straight camber, so none of these experts thought to go against conventional wisdom and reduce the camber.

Our non-specialist stumbled upon this trick by mistake, making the car go faster by reducing camber, while the brute force optimisation pushed very hard in this direction to deliver an infeasibly quick laptime.

Camber gain user sign error.

Mistakes Happen

While it might seem disappointing that a mistake was found, this is representative of reality. There are infinite possibilities for end users to type incorrect combinations of numbers into the car model and endless room for correlation improvement. These discrepancies may go unnoticed for years.

It is rather pleasing that this method surfaced the issue well before it would have been spotted by conventional platform use. Furthermore, it prompted us to add a warning for unrealistic camber gain, alongside the other sanity checks that exist to help users.

Challenge Yourself

The Car (with correct camber gain), Weather, Track and User Maths configs are available as defaults on the Canopy platform, so you can try this for yourself. You’ll find the competition rules within the User Maths Config Notes.

We would be happy to host this as a training event for new users in your company or university.

Alternatively, if you have any ideas of what we should optimise for our next challenge, we would love to hear from you. The team feedback from this challenge went into our development pipeline to make it even easier next time around, so keep challenging us!