Where autonomous racing technology goes after the podium

Constructor Racing finished second at Imola on 5 September 2026. It was A2RL’s first multi-car autonomous race in Europe, a 12-lap event that brought five qualified EAV-25 cars to the grid. The hardware was identical; each team developed its own driving software. TUM returned to the pit lane after a technical issue on the formation lap, before the race itself began. Kinetiz won.

The result matters beyond the finishing order because the race exposed problems that are difficult to reproduce cleanly in a lab: changing grip, failures at speed, short reaction windows and interaction between autonomous cars. For Constructor, those conditions connect directly to a broader research question: which parts of a racing stack remain useful when the vehicle and the customer change?

Ilya Shimchik is team principal of Constructor Racing and a principal investigator at Constructor Labs. His work spans perception, state estimation, planning and control. Constructor Labs sits between university research and industry. Shimchik’s work includes translating autonomous-driving research into projects outside racing, and his public profile lists Drako Motors as an industry partner for driver assistance and emergency obstacle avoidance.

This article draws primarily on Shimchik’s written comments after Imola, with additional material from an interview recorded before the race. Quotations have been translated from Russian. We covered the race chronology separately.

What the podium reflects

Asked what helped Constructor move from fifth on the grid to second at the finish, Shimchik points first to the way the car handled a track whose grip was changing through the weekend.

Two things: reliability and tactics. And the tactics here are every bit as interesting as the reliability. Imola after other racing series is a dirty track. Rubber, dust, different grip on different sections and in different corners, and all of it changing across the weekend. We knew in advance that nobody would repeat their qualifying time in the race. So our car did not run a pre-set speed profile. It adjusted the pace to the actual state of the track, estimated the available grip in real time and built its braking points from that.

That description points to a capability Shimchik considers central to the team’s engineering work: estimating how much grip is available now, then driving close to that physical limit. A speed profile derived from cleaner conditions would not have survived this race.

Constructor’s race was not clean. According to Shimchik, a technical problem stopped the car on the opening lap and cost 29 seconds relative to Kinetiz. Constructor resumed and finished 10.963 seconds behind. The raw change in the gap sounds dramatic, but Shimchik puts a limit on what it proves.

Kinetiz was leading, and once Unimore and PoliMOVE were out it had no reason to take risks. It could simply bring the car home. So “we were faster” describes the pace in those circumstances. It is no guarantee that we would have won all else being equal.

The gap closed while the race was running green. After the Unimore and PoliMOVE collision the race director declared Code 60, capping every car at 60 km/h, and Shimchik says the rest of the distance ran in that mode, which holds gaps in place. What the recovery shows is that Constructor took back most of what its own failure had cost, then kept the car running while three other teams lost their races to technical problems or the collision.

In autonomous racing, a fast lap measures one part of the stack. A race also tests whether the system can keep operating after conditions depart from the clean case engineers planned for.

A capability another vehicle can use

Shimchik describes the underlying capability as “assessing the state of the car and taking decisions at the limit of its capability, with no human in the loop and on a tight reaction-time budget”.

An emergency manoeuvre depends on more than detecting an obstacle. The vehicle also has to estimate what it can physically do at that moment. Available grip, tyre load and the current trajectory determine whether braking, steering or a combination of the two is feasible.

Drako Motors is the clearest partner example. Before Imola, Shimchik told Inside Deep Tech that Constructor was helping develop emergency obstacle avoidance algorithms for the company’s electric performance-car platform. He described the work as an adaptation problem: Drako’s own vehicle architecture means the solution has to be designed for that platform and cannot be transferred unchanged from the race car. The partnership also appears on Shimchik’s Constructor Labs profile. Neither source establishes a series-production release of the function.

A racing stack can demonstrate that the team solves particular control and estimation problems under extreme conditions, but moving that capability to another vehicle still requires modelling and testing on the customer platform.

Shimchik also describes two closer-to-racing product directions. One is safety assistance for amateur track drivers, where the system could intervene when a driver exceeds what the car can safely do. The other is a Racing Coach concept for driver training, using the team’s knowledge of vehicle dynamics to give feedback to less experienced drivers. He presented both as areas for pilots or development, not announced commercial products. He also names navigation without satellite signals as an application area, but the supplied material does not describe a customer project or enough technical detail to assess it further.

What racing produces that is harder to get elsewhere

Shimchik calls data one of the team’s main assets. Constructor has accumulated more than 10 TB over three seasons, including lidar point clouds, camera and radar data, full chassis telemetry and records of failures.

The value comes from the operating conditions behind those recordings. Shimchik contrasts them with ordinary road-driving data, where vehicles are generally kept away from the edge of tyre adhesion. Racing repeatedly creates examples near that boundary: changing grip, high lateral load, loss of traction and failures while the vehicle is moving quickly.

Those recordings can be reused as engineering cases. A failure observed on track can become a scenario for simulation, regression testing or a later physical test. A larger archive alone says nothing about algorithm quality. Its value lies in the cases engineers can inspect and reproduce.

Simulation covers much of the development cycle, but Shimchik does not treat it as a substitute for the track.

Simulation covers most of it. The final few per cent are real rubber on real asphalt, and there is nothing to replace them with.

That gap was visible in his pre-race interview as well. Tyres, asphalt temperature and grip do not behave exactly as they do in a simulator, and increasing physical fidelity raises compute cost. Engineers therefore work with an imperfect model, then use real track time to identify where it stops matching the car.

The Imola collision supplied a new case. Unimore slowed sharply while leading; PoliMOVE, following within roughly a second, hit the rear of the car. Shimchik identifies several interacting constraints: the short following distance, tyres already carrying lateral load through the corner and lower grip away from the racing line. At around 250 km/h, a car covers close to 70 metres each second.

He does not claim Constructor would have avoided the collision.

We would have had a reaction to an object like that, I can say that much. Whether we would have had time to avoid it, honestly, I do not know. That is not a question to answer confidently without checking. We can reproduce the situation in simulation and see what our stack would have done, and we probably will, because it is a real scenario.

Replaying the event can test Constructor’s own response, but without the other teams’ telemetry it cannot reconstruct exactly what their systems detected or why PoliMOVE behaved as it did.

The problem on a wet mine road

Heavy off-road and mining equipment is one application Shimchik connects to real-time grip estimation. He names no mining customer. The link at this stage is technical.

A NIOSH-funded final report from November 2023 gives an external example of the problem. Its authors, Joel Haight and Robin Burgess-Limerick, cite an analysis by Pascoe and colleagues of haul-truck incidents recorded at BHP’s Jimblebar mine over FY2014 to FY2018, the four years spanning the introduction of autonomous haulage. Wet-road loss-of-traction events accounted for 27% of the autonomous-truck incidents identified at that site. The report describes trucks relying on traction controls and on speed zones entered by people, because the system cannot see a wet road the way a driver does.

The same analysis records the overall haul-truck incident rate at the site falling by more than 90% across those four years, from 590 to 51 incidents per million hours. The wet-road figure is narrower. It isolates one residual problem inside a system whose recorded incident rate was falling sharply.

A live traction estimate could inform speed limits or control limits for a mine operator. Racing gives Constructor relevant experience with that problem, but a haul truck is a different machine in a different operating environment. Any customer claim would need measurements on the target vehicle. At present, the mining case remains a plausible transfer path; Constructor has no demonstrated product there.

Testing as an application in its own right

A second transfer path is validation. Shimchik describes a testing practice that is closer to regulated engineering than to the usual image of a research prototype:

We have a habit that is rare for software teams: running one fixed set of parameters through prescribed tests with quantitative pass-or-fail criteria.

The point is repeatability. Instead of asking whether an autonomous vehicle generally appears to drive well, the test fixes a configuration and checks it against defined conditions. That makes failures comparable across software changes and creates evidence that can be reviewed later.

Regulation gives that discipline a practical context. Regulation (EU) 2023/1230 on machinery applies from 20 January 2027. Annex I, Part A includes safety components with fully or partially self-evolving behaviour using machine-learning approaches to ensure safety functions. It also includes machinery with embedded systems of that type that have not been placed independently on the market, in respect only of those systems. For Part A categories, Article 25(2) sets conformity-assessment routes that involve a notified body.

The scope is specific. The 2027 date applies only to the categories defined by the regulation. Formal conformity assessment remains the job of a notified body, and nothing in the supplied material establishes Constructor as one. The connection to Constructor is narrower: teams building safety-related autonomous systems need controlled tests and evidence before an external assessor can evaluate the product.

Six developers and an intern

The amount of physical testing the team can do is partly a resource question. Constructor lists seven technical areas around the racing programme, but Shimchik says they should not be read as seven staffed departments.

Those are areas of responsibility. The staffing behind them is six core developers plus an intern on the racing stack. I am not counting researchers at Constructor University Bremen here; they belong to a separate research group. One person covers several areas at once. The perception engineer also does sensor calibration and integration. Whoever writes the controller also validates it in simulation.

That overlap creates a bottleneck. The same engineers have to adapt the car to new conditions, develop features, inspect test data and prepare the next round of validation.

Six people cannot adapt to new conditions quickly, develop new features and work through test data all at the same time. We have to choose.

Shimchik links additional engineers directly to iteration speed between test days. He also wants more track time. In this programme, those two constraints reinforce each other: physical testing generates the cases the team needs, while engineers need time to analyse them and turn them into software changes before the next session.

Building on the Imola result

Shimchik describes Constructor’s progress over three seasons through the relative lap-time gap to the leader. Raw lap times do not travel well across seasons: regulations changed, and so did vehicle configuration and tyres. His metric compares Constructor with the leader in each competitive context.

We used to be 8–9% of lap time behind the leader. Now we fight the leaders on equal terms.

The percentage gap is still not a controlled experiment across seasons. Track, field and race conditions change. But it is more informative than comparing raw lap times from different versions of the championship, and it reflects Shimchik’s assessment that Constructor has moved from chasing the front to competing close to it.

The next test is already defined. Ahead of the Yas Marina finale, Shimchik names three priorities: faster adaptation to changing grip, reliability at the start and on the opening laps, and multi-car interaction when another vehicle suddenly loses speed.

Imola supplied Constructor with examples of all three priorities: changing grip and a first-lap failure recorded in its own data, and a multi-car incident at speed the team can reconstruct in simulation. The next iteration runs to Yas Marina, where those changes get tested on track. Beyond racing, the same engineering experience is already being applied to the Drako platform, while heavy equipment and autonomous-system validation remain areas Constructor sees as potential paths for further transfer.

Sources

A2RL official release on the Imola race, 5 September 2026. A2RL announcement via the Abu Dhabi Media Office, 1 July 2026, for the return to Yas Marina for the season finale. Ilya Shimchik’s page at Constructor Labs for the Drako Motors partnership and the link to Constructor University Bremen. Regulation (EU) 2023/1230, Annex I Part A and Article 25(2), application date 20 January 2027, text on EUR-Lex. “Automation Experience with a Global Perspective”, J. Haight and R. Burgess-Limerick, final report prepared for NIOSH, November 2023, citing Pascoe et al. (2022b) for the Jimblebar figures.