Introduction to VD Simulation

Simulation and Simulation Environment

Every simulation aims at describing the observed system as accurately as possible in order to be able to model the behavior of the real system. A vehicle or part of a vehicle as well as, if necessary, a part of its environment can be referred to as a system.

The vehicle models are purely mathematical in nature. Thus running a simulation is equivalent to the running of software.

Vehicle Models

Model Type	Degrees of Freedom
Single track (bicycle) model, linear	2
Single track(bicycle) model, nonlinear	3-7
Twin track model	14-30
Multibody model	>20
Finite Element Model	>500
Hybrid model	>500

Point Mass

Main page: Point Mass Model

Bicycle

Main page: Bicycle Model

Commercial Available Software

Formula Student Teams Available Software

OpenLAP

Open source lap time simulator coded in MATLAB. Students may find the simulator files in the Mathworks file exchange in the link below:

https://www.mathworks.com/matlabcentral/fileexchange/75063-openlap-lap-time-simulator

Includes the following functions:

1. OpenVEHICLE Vehicle modeling:
   Includes inertia, engine torque curve, drivetrain, tyres, aerodynamics, and steering models.
2. OpenTRACK Track modeling:
   Can be generated from segments or logged data.
   Includes curvature, closed/open type tracks, elevation, banking, grip factors and sectors.
3. OpenDRAG Straight line simulation:
   Time based point mass simulation system using models from OpenVEHICLE.
   Includes shifting duration.
4. OpenLAP Lap time simulation:
   Distance based point mass simulation system using models from OpenVEHICLE and OpenTRACK.

Tutorials to use the tool can be found at Michael Chalkiopoulos' YouTube channel.

Vehicle Dynamics Modelling Best Pratices

A note on implicit versus explicit approach. If you ever worked in a coding team, or if you have inherited code from other people. Most certainly you have experience not knowing what a variable is. This is because we are using an implicit approach. We assume that everyone knows that "m" means mass, or that "wfl" means front left wheel speed. The issue with this approach is ambiguity. For that reason, it is always better to right a long name. Althougth, it takes more time, it is clear to anyone reading which variable of the vehicle you are talking about. Especially since teams cycle only lasts on average 2 years. You will have new comers trying to understand your code. For that reason you should make an extra effort to be sure that your variable are clear.

Should I write fl_w or w_fl? Preferably write w_fl. The reason is that when you do a search on the programing language if all the variable start with FL, it won't help much. But if you start with their own letter it is easier to search. See image below as an example.

List of acceptable variables: m | mass tf | front_track tr |rear_track wd | weight_distribution Ixx Iyy Izz delta | steering_angle| steer_angle steering_angle_at_wheels _ steer_wheels Cf | front_cornering_stiffness Cr | rear_cornering_stiffness wf | wheel_speed_front wr | wheel_speed_rear wfl | wheel_speed_front_left | wheel_speed_fl wfr | wheel_speed_front_right | wheel_speed_fr wrl | wheel_speed_rear_left | wheel_speed_rl wrr | wheel_speed_rear_right | wheel_speed_rr ax | longitudinal_acceleration | long_acc ay | lateral_acceleration | lat_acc az | vertical_acceleartion | vert_acc vx vy vz x y z pitch roll yaw pitch_rate roll_rate yaw_rate