High-Fidelity Multi-Body Simulator for Autonomous Racing

I. INTRODUCTION

• High testing cost and risk, limited track time, and sometimes unavailable vehicles create a gap between algorithm development and experimental validation.A simulator capable of reproducing maneuvers or entire track sessions with high efficiency and fidelity is presented as essential.Source: §I · p. 1
• The framework provides real-time testing and reliable ground truth for assessing autonomous-racing algorithms before real-world deployment.The authors also state that it significantly accelerates development.Source: §I · p. 1
• Dymola racecar libraries, OpenCRG road surfaces, and FMU integration with a custom C++ software-in-the-loop environment form the simulation framework.The libraries provide adaptable vehicle templates; FMU provides a tool-independent interface for integrating dynamic models.Source: §I · p. 1

II. STATE OF THE ART AND CONTRIBUTION

• Prior simulators often simplify vehicle dynamics, while vehicle-dynamics-oriented tools are rarely used in autonomous racing and prior real-data comparison was limited.The cited comparison did not specifically demonstrate dynamics fitting or state how close its data came to vehicle limits.Source: §II · pp. 1–2
• The contribution is a customizable, parameterizable high-fidelity simulator tailored to autonomous racing, with real-time capability and FMU/CRG standards compliance.The authors state that experimental-data-based tuning supports deeper understanding of system dynamics and model-based control development.Source: §II · p. 2

III. DEVELOPMENT OF THE SIMULATION FRAMEWORK

• Manufacturer-provided parameters populated the Dymola model, enabling an initial physics-based approximation before on-track validation.The parameters covered chassis, tires, suspensions, powertrain, and aerodynamics.Source: §III · p. 2
• Dymola generated reference maneuvers that are unsafe, impractical, or unavailable for testing, supporting calibration of simplified planning and control models.The reference data supports identification of axle characteristics in single-track models.Source: §III · p. 2
• Dymola simulations were also used to derive control-oriented subcomponents for locked-differential force distribution, lateral load transfer, and road-banking effects on tire loads.The authors state these analyses support enhanced control-oriented models.Source: §III · p. 2
• The Dymola model was exported as an FMU and integrated into a custom software-in-the-loop simulator for real-time testing of the complete autonomous software.This followed computational-efficiency improvements to the high-fidelity model.Source: §III · p. 2
• Road modeling progressed from a flat surface to variable banking and then high-resolution 3D CRG surfaces representing complex geometry.The flat-surface approximation was described as too coarse.Source: §III · p. 2

A. Vehicle Model

• Motorsport library blocks model a complete race vehicle, with tire forces using Pacejka Magic Formula 6.2 and custom tire-temperature and brake adaptations.The tire model includes custom grip and stiffness variation with temperature; the brake block supports four independent commands and varying pad–disk friction.Source: A. Vehicle Model · pp. 2–3
• The driveline uses a centrifugal clutch that engages from 1400 rpm to full engagement at 1800 rpm, and the differential supports locked and friction-based limited-slip configurations.The clutch engagement range and differential alternatives are specified in the model description.Source: A. Vehicle Model · p. 3
• Suspensions are adapted to the actual vehicle geometry, while opponent position indexes aerodynamic slipstream scaling and actuator dynamics use transfer functions identified from track data.The aerodynamic lookup returns drag and downforce scaling coefficients.Source: A. Vehicle Model · p. 3

1) Brake Thermal model:

• The brake thermal model divides the disk into a low-inertia surface node and a core node that stores heat, exchanges it by conduction, and dissipates it through convection.The surface temperature follows an energy balance; convection coefficients depend on disc angular velocity and vehicle speed.Source: 1) Brake Thermal model · p. 3
• Brake torque and thermal input use a pad–disk friction coefficient retrieved dynamically from an experimental map of contact pressure and disk surface temperature.A heat-partitioning factor scales the generated friction power for the thermal model.Source: 1) Brake Thermal model · p. 3

2) Tire Thermal model:

• Tire peak force and cornering stiffness are modeled as functions of tread temperature, with the same approach applied to longitudinal characteristics.Tire heat generation is computed internally from tire forces and slip.Source: 2) Tire Thermal model · p. 3
• The piecewise approximation makes grip rise during warm-up, remain constant within a thermal window, and fall with overheating, while cornering stiffness decreases as temperature increases.The temperature variations are experimentally identified; T is tread temperature and Tref is reference ambient temperature.Source: 2) Tire Thermal model · p. 3
• Thermal components are implemented in custom blocks as a coupled thermomechanical model that captures temperature-induced performance changes and can be disabled for more deterministic simulation.The implementation uses thermal components from the Modelica standard library.Source: 2) Tire Thermal model · p. 3

3) Actuation models:

• The ARX actuator model captures actuator-relevant dynamics, especially dead-time delay, while steering and braking also include delay and friction effects.A throttle delay approximates turbo-lag, though it does not represent full turbocharger dynamics.Source: 3) Actuation models · p. 3

B. Road Model

• A preliminary track model can be refined with a 3D map reconstructed from vehicle LiDAR when simulated and measured quantities show significant discrepancies.Source: B. Road Model · p. 4
• The two-stage road approach is particularly effective for preparing for competitions on new tracks without prior experimental data.Source: B. Road Model · p. 4
• The road workflow converts a processed track mesh into a CRG reference line and elevation grid, with optional local refinement and smoothing.The grid samples elevations from the STL surface, and coordinate transformations align the resulting CRG file with real global coordinates.Source: B. Road Model · p. 4

C. Execution time and Numerical Stability

• The 0.001 s Euler timestep is the minimum value ensuring numerical stability; a 0.0012 s step remained stable at high speed but oscillated at low speed and was discarded.The selected step is required to capture fast tire dynamics, and system poles have negative real parts.Source: C. Execution time and Numerical… · p. 4
• Dymola’s in-line integration embeds discretization expressions in the model equations to reduce integration CPU time.Source: C. Execution time and Numerical… · p. 4

D. Dymola Experiment Setup for FMU Export

• The FMU-export experiment couples the vehicle model with open-loop driver and CRG road blocks, exposing actuator commands and external aerodynamic effects as inputs.The interface also includes steering, throttle, four independent brake commands, gear selection, and opponent position for slipstream modeling; relevant outputs are collected in the controlBus.Source: D. Dymola Experiment Setup for FMU… · p. 4, Figure 3 · p. 4
• Vehicle setup, parameters, and track configurations can be changed without re-exporting the FMU.Configuration files hold vehicle parameters and setup, while aerodynamic and engine maps and tire models use external MAT and .tir files, respectively.Source: D. Dymola Experiment Setup for FMU… · pp. 4–5
• The exported FMU is a pre-compiled black box that runs in Co-Simulation mode with its own solver and exchanges only defined inputs and outputs.Source: D. Dymola Experiment Setup for FMU… · p. 5

• Pacejka Magic Formula 6.2 micro-parameters are selected to minimize error between experimentally measured and modeled tire forces across vertical-load and camber conditions.Source: §V · p. 5
• T.R.I.C.K. uses vehicle parameterization and CAN-bus signals to produce virtual telemetry estimates of tire forces and slip.Its vehicle description includes direct parameters such as mass and wheelbase as well as aero maps and dynamic toe and camber variations.Source: §V · p. 5
• The T.R.I.C.K. inputs include IMU acceleration and yaw rate, steering-potentiometer angle, wheel speeds, and optical-sensor vehicle slip angle.These signals support load-transfer, force, wheel-slip, and slip-ratio estimation; steering angle is converted to wheel angle accounting for Ackermann variation.Source: §V · p. 5
• An optimization algorithm varies Pacejka micro-parameters within prescribed ranges to minimize the deviation between experimental forces and Magic Formula forces.Experimental characterization and calibration are interconnected, with test data collected for tire operating conditions to support the optimization process.Source: §V · p. 5

A. C++ environment for co-simulation

• At each 1 ms loop iteration, Sim-node passes stack commands to Fmu-manager, which advances the FMU, retrieves vehicle state, and supplies it to sensor devices.Devices process signals with normalization, noise, and sensor-specific update rates; their measurements are published in the format of real vehicle sensors.Source: A. C++ environment for co-simulation · pp. 5–6
• The closed-loop architecture sends stack control commands to the FMU and returns simulated sensor measurements to the software stack.The Fmu-manager encapsulates FMU interaction, while Device produces sensor measurements from FMU vehicle state.Source: A. C++ environment for co-simulation · p. 5, Figure 5 · p. 6

B. Graphical User Interface (GUI)

• The GUI provides a wireframe vehicle view, drivable-area and trajectory cues, sensor data, and command and feedback metrics.Source: B. Graphical User Interface (GUI) · p. 6
• The interface supports basic vehicle commands and runtime changes to driving-style parameters through custom plugins; PlotJuggler displays real-time virtual telemetry.Source: B. Graphical User Interface (GUI) · p. 6

1) Tire-road interaction:

• Low-frequency braking-zone bumps and Turn 8 banking/elevation are preserved despite filtering high-frequency road irregularities.Smoothing is particularly important with simplified, single-point tire–road contact, which yields a smoother vertical tire response.Source: 1) Tire-road interaction · p. 6

2) Brake thermal model:

• Constant-brake warm-up maneuvers at about 360 s and 460 s heat the system and increase braking performance, as reflected by the friction coefficient.Source: 2) Brake thermal model · p. 6
• After the system reaches its operating temperature range, simulated brake temperatures consistently approximate experimental data despite early surface-temperature overestimation.The early overestimate occurs during the first two braking events and is attributed to constant thermal conductance between nodes.Source: 2) Brake thermal model · p. 6

1) Fastest lap analysis:

• 58.763 s reference vs 58.829 s simulated lap; the simulated time is within 2% of the former Formula 1 driver’s best lap.Lap time is an aggregate metric, not a direct indicator of perfect model matching: the real car has a more powerful powertrain, while modeling simplifications produce larger torque delivery.Source: 1) Fastest lap analysis · pp. 6–7, Figure 9 · p. 7
• Longitudinal velocity and sideslip are accurately replicated, with localized discrepancies in Turn 5 and lateral-error mismatches especially in Turns 5 and 6.The passage reports overall good agreement and notes that quantitative error metrics are in Table I.Source: 1) Fastest lap analysis · p. 7, Figure 9 · p. 7, Table I · p. 7
• Turn-in peak errors caused by the controller’s overestimation of combined slip also occur on the real car; real turn-out oscillations are larger amid sensing delays and localization noise.Source: 1) Fastest lap analysis · p. 7

2) High-dynamics scenario:

• Near-limit Turn 1 oversteer is qualitatively reproduced: combined rear-tire slip raises sideslip and prompts countersteering, with lateral deviation closely matched.Source: Figure 10 · p. 7, 2) High-dynamics scenario · pp. 7–8
• Simulation anticipates oversteer because the real engine responds more slowly from turbo-lag, producing an earlier speed increase and slightly more pronounced sideslip in simulation.Source: 2) High-dynamics scenario · p. 7
• 0.357 ms average FMU execution is below the 1 ms real-time threshold.Source: Figure 11 · p. 8

C. Real-time performance

• Most full-stack runtimes were below 1 ms, with very few slight exceedances that had no significant impact on model response.The reported test system used Ubuntu 24, an Intel Core i9-14900HX CPU, and 32 GB of RAM.Source: C. Real-time performance · p. 8

VIII. CONCLUSION AND FUTURE WORK

• Dynamic accuracy still needs investigation through a more detailed powertrain model for turbocharger effects and a multi-point tire–road contact model for curb loads.Source: §VIII · p. 8
• Planned extensions include exteroceptive sensor simulation, a game-oriented interface for human-driving data, and data-driven planning and control approaches.The authors also describe the platform as a step toward extensive AI-agent training and real-world deployment.Source: §VIII · p. 8