Development and Validation Of a Single Mass Lap Simulation

Development and Validation Of a Single Mass LapSimulation

by

Jeremy R. Noel

Submitted to the Department of Mechanical Engineeringin partial fulfillment of the requirements for the degree of

Bachelor of Science in Mechanical Engineering

at the

MASSACHUSETTS INSTITUTE OF TECHNOLOGY

May 2020

c○ Massachusetts Institute of Technology 2020. All rights reserved.

Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Department of Mechanical Engineering

May 8, 2020

Certified by. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Ian Hunter

George N. Hatsopoulos Professor in ThermodynamicsThesis Supervisor

Accepted by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Maria Yang

Professor of Mechanical Engineering

Development and Validation Of a Single Mass Lap Simulation

by

Jeremy R. Noel

Submitted to the Department of Mechanical Engineeringon May 8, 2020, in partial fulfillment of the

requirements for the degree ofBachelor of Science in Mechanical Engineering

Abstract

In this thesis, a single mass model lap time simulation was designed, implementedand validated in MATLAB. The goal of this simulation was to accurately predict thevelocity of a formula style open wheeled race car on a given track. The simulationwas constructed in MATLAB, and features a function based design that will allowthe core algorithm to be used with more sophisticated vehicle models. The codewas tested and validated using a combination of contrived and collected map data,and a strong correlation of 0.8067 was shown with 95% confidence bounds of 0.8028,and 0.8105. Finally, this thesis outlines proper testing techniques to obtain the datarequired to complete the validation process of this simulation.

Thesis Supervisor: Ian HunterTitle: George N. Hatsopoulos Professor in Thermodynamics

3

Acknowledgments

There are so many people I would like to thank who have made this research

and development project possible. First, of course are my parents and aunt, without

whose support and constant requests to please get my stuff out of their garage, I

would not have found my passion for vehicle design. Next are the former leaders of

the FSAE team, in particular Luis Mora, Cheyenne Hua and Elliot Owen who showed

incredible patience with me as I made enough foolish mistakes to learn for myself just

how hard developing a a functional car can be. Then are my own FSAE cohort, who

made my four years on the team the best possible experience. I thank my friends for

putting up with me living in shop for most of my four years, and especially Elizabeth

Harkavy for her Latex and editing help. Finally I would like to thank Dr. Christopher

Vick, without whom I would never have found myself at MIT. I consider myself truly

fortunate to stand on the shoulders of these giants.

5

Contents

1 Introduction 13

1.1 Formula SAE Competition . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Team Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5 Previous Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Design Of Simulation 19

2.1 Vehicle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Simulation Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Coordinate systems, and Units . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 High level code structure . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Subsystem Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.1 Car Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.2 Path Generation Techniques . . . . . . . . . . . . . . . . . . . 24

2.6.3 Splitting the Lap into Segments . . . . . . . . . . . . . . . . . 29

2.6.4 Driver Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.6.5 Driving Function . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.7 Data Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7.1 Velocity Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7.2 Velocity Overlay on Map . . . . . . . . . . . . . . . . . . . . . 42

7

3 Validation 43

3.1 Validation Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Validation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Creating Useful Test Cases . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3.1 Acceleration Run Test Case . . . . . . . . . . . . . . . . . . . 44

3.3.2 Constant Radius Turn . . . . . . . . . . . . . . . . . . . . . . 47

3.3.3 Variable Radius Turn . . . . . . . . . . . . . . . . . . . . . . . 50

3.4 Utilization of Testing Data . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.1 Small Map Testing . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.2 Full Lap Testing . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Next Steps for Validation . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.5.1 Testing Procedure for Simulation . . . . . . . . . . . . . . . . 54

3.5.2 Testing Sweeps to Ensure Predictive Nature . . . . . . . . . . 55

4 Conclusion 57

4.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A Additional Simulated Lap Plots 59

8

List of Figures

1-1 High level block diagram of acceleration simulation [4] . . . . . . . . . 17

2-1 Vehicle axis system [10] . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2-2 High level block diagram of code structure . . . . . . . . . . . . . . . 23

2-3 Image provided by SAE depicting a single autocross lap [8] . . . . . . 25

2-4 Overlay of extracted points over the original map . . . . . . . . . . . 25

2-5 A car weaves through an autocross slalom section similar to an FSAE

track [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2-6 Overlay of three different gaussian smoothing windows . . . . . . . . 28

2-7 Determining radius and angle from a series of points [3] . . . . . . . . 29

2-8 Lap times of 1000 iterations of random segment locations compared to

calculated segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2-9 Example of a simple map split into three segments . . . . . . . . . . . 32

2-10 element velocity plot in back step solving . . . . . . . . . . . . . . . . 40

2-11 Final element velocity plot in back step solving . . . . . . . . . . . . 40

3-1 Model of standard FSAE acceleration track . . . . . . . . . . . . . . . 45

3-2 Velocity of the car on a straight track shown as a function of distance 46

3-3 Velocity of the car on a straight track shown as a function of distance 47

3-4 Map created using debugging map creator with straights and a constant

radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3-5 Compettiont skidpad course[7] . . . . . . . . . . . . . . . . . . . . . . 49

3-6 The velocity plotted against the distance traveled comparing the sim-

ulation to competition results . . . . . . . . . . . . . . . . . . . . . . 50

9

3-7 Velocity of the U-Turn map . . . . . . . . . . . . . . . . . . . . . . . 50

3-8 The velocity plotted against the distance traveled . . . . . . . . . . . 51

3-9 Velocity of the Variable radius U-Turn map . . . . . . . . . . . . . . 51

3-10 The velocity plotted against the step number overlayed with testing data 53

3-11 Velocity shown as colors on the practice map . . . . . . . . . . . . . . 53

A-1 The velocity plotted as a function of time overlayed with endurance data 60

A-2 Velocity shown as colors on the endurance map . . . . . . . . . . . . 60

A-3 The velocity plotted against the step number overlayed with testing data 60

A-4 Velocity shown as colors on the practice map . . . . . . . . . . . . . . 60





10

List of Tables

1.1 FSAE Competition Points Breakdown . . . . . . . . . . . . . . . . . 14

2.1 Car Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

11

Chapter 1

Introduction

1.1 Formula SAE Competition

The Formula SAE (FSAE) Competition is a collegiate design competition where

students deign, build and race an open wheel formula-style racecar. The competition

has a series of scored events. These events consist of two separate categories, dynamic

and static, and when combined they create a total score upon which a winner is de-

cided. The dynamic events test the performance of the car in straight line acceleration

(75m drag race: 100 points), skidpad (steady state cornering on a dry surface: 75

points), autocross (single lap around a cone track: 125 points) and endurance (22km

auto-cross that includes a change of driver at the midpoint: 275 points plus efficiency:

100 points). The dynamic events make up a total of 675 points [7]. The static events

seek to reward excellence in engineering knowledge as well as design decisions. There

are three events: cost (points awarded based on proper book keeping and overall

cost: 100 points), presentation (a mock business presentation highlighting logistics,

production and technical advancement: 75 points) and design (evaluation of engi-

neering effort, design goals and overall comprehension of the team: 150 points) [7].

The static events make up a total of 325 points. The competition is a race to collect

as many of the 1000 available points as possible. The point breakdown is summarized

in table 2.1.

13

Table 1.1: FSAE Competition Points Breakdown

Event Points Available

Acceleration 100Skidpad 75

Autocross 125Endurance 275Efficiency 100

Cost 100Presentation 75

Design 150Total Points 1000

The FSAE competition originated in 1981, and consisted of a total of 6 teams [2].

The internal combustion (IC) competition rapidly grew and now has multiple compe-

titions across the United States. In 2013 the first electric variant of the competition

was introduced with a partial set of rules. This competition featured 20 registered

teams of which 9 made it to the actual competition[9]. In a similar swell the electric

competition is now flourishing with the 2019 competition boasting 30 registered teams

with 27 making it to competition. 2020 will mark the first year that FSAE has not

hosted an in person competition since its inception, due to the COVID-19 pandemic.

1.2 Team Background

MIT Motorsports is an FSAE team that competes annually in the electric class.

The team is made up of about 40 students who are a mix of mechanical, electrical and

software engineers with the occasional business minded student leading the charge to

raise enough money to stay afloat. The team is entirely student run, and is led by a

few adventurous juniors, who are in way over their heads.

MIT Motorsports began in 2001, a small team lead by Nick Gidwani who led

the team to build the first IC car. The team grew and climbed the ranks of the IC

competition, culminating in a 16th place finish out of 105 teams competing in 2012.

The team then transitioned to the electric competition, and in 2015 successfully built

14

the first electric racecar that ran, although not in time to compete. The team’s

performance grew quickly, culminating in a dominant performance in 2018, when the

team was disqualified after winning the endurance race by over a minute, due to an

alleged overpower event.

This success led the team to try to grow further for the model year 2019 car

(MY19). It was determined that the most effective way to score the required number

of points to win would be through a four wheel drive (4WD) architecture. This deci-

sion was primarily made with the preexisting simulation tools the team had available.

The primary simulation tool was a single mass ordinary differential equation (ODE)

based acceleration simulation. This simulation and its limitations will be discussed

at length in section 1.5. Ultimately the MY19 car proved to be too much to handle

in a single year. Both the attempt at a revolutionary new liquid cooled battery pack

and a 4WD car failed. The team was still able to compete with a rear wheel drive

(RWD) car and a hastily made air cooled battery pack. Still the team found some

success with good performances in both acceleration (2𝑛𝑑) and skidpad (3𝑟𝑑), but did

not complete autocross, and finished out of the top three in endurance.

Ultimately MIT Motorsports maintains its status as a yearly contender for the

elusive first place prize. The team was hungry in MY20, learning from the mistakes

made in the previous year and building a more conservative car on an aggressive

time-line. This strategy seemed to be paying off before the season was cut short. The

team remains hungry as a new design and build cycle begins for MY21.

1.3 Motivation

The primary motivation for this project was to establish stronger simulation tools

for architecture decisions for future design cycles of the MIT Motorsports FSAE

vehicle. The simulation developed in this thesis will help the team to rapidly weigh

the overall effects of different architectures in all dynamic events. This simulation

will also aid in the static score through providing more accurate point estimations

and justifications for design decisions.

15

1.4 Objective

The objective of this thesis is to establish the framework of a full lap simulation

specific to an FSAE electric race car. This simulation should be able to accurately

predict the behavior of an FSAE car at its tractive limit at all times. The simulation

should also be able to provide other key parameters about the lap, ranging from

maximum speed, to maximum power, and total power consumed. All of these outputs

can help to determine sensitivities to a variety of car parameters. This project also

seeks to outline a testing procedure and tests necessary to build a database to be able

to fully validate the simulation across a variety of conditions. In summary there are

four primary objectives for this project:

1. Create a lap time simulation that can take several input formats, including GPS

data, picture style maps, and arbitrary user defined maps. The simulation must

then generate a velocity map as well as other parameters of interest including

power and acceleration.

2. Ensure that the core algorithm used for solving for the behavior of the car is

compatible with more detailed vehicle models such as a bicycle model, and a

two track model.

3. Validate the model with existing data to ensure that the model performs both

logically and matches the data.

4. Outline a testing platform and procedure that will allow the fidelity of the model

to increase as the team is able to collect additional data from the car.

1.5 Previous Simulations

The team has developed and used multiple versions of a linear acceleration sim-

ulation. The first iteration was an ODE based solver that utilized a single mass

model. A high level block diagram of this code is shown in figure 1-1. This was a

suitable simulation for design decisions but did not feature the separation required

16

for testing launch control algorithms in the code. This code was advanced in 2019

with a Simulink based acceleration simulation that did feature an independent con-

trol system[4]. Many of the features in the lap simulation were based on the concepts

displayed in this Simulink model.

Figure 1-1: High level block diagram of acceleration simulation [4]

The tremendous growth and technical advancements attempted by the team in

2019 made painfully obvious the lack of advanced simulation tools available to make

those decisions. The team had focused primarily on the acceleration model when

making the 4WD architecture decision. The acceleration model was supplemented

by the use of Optimum Lap (a commercial lap simulation software). The nature

of Optimum Lap as a single mass model does not allow for explicit specification of

4WD vs RWD. It does, however, provide some basis for how the car will perform in

a dynamic sense. The use of an acceleration simulation as the primary simulation

led to an overemphasis on the straight line capability of the car. The straight line

acceleration is a place where 4WD is excellent, and the simulation did not properly

penalize higher vehicle mass and unsprung mass.

The use of Optimum Lap was the first step in the correct direction. Optimum

Lap is a single mass model much like the one developed in this thesis. While the

Optimum Lap results are useful when no other simulation is available, the inability

to refine the code makes for a less than ideal option. Additionally Optimum Lap

struggles to accurately model complex lap shapes, which created issues for the team

17

in the 2019 build cycle. This may lead to results that do not make sense, or worse,

can be misleading.

18

Chapter 2

Design Of Simulation

2.1 Vehicle Model

This simulation models the vehicle as a single mass with several known parameters.

These parameters include the coefficient of friction of the tire with the road surface,

the drag and lift coefficients (𝐶𝐷𝐴 and 𝐶𝐿𝐴), vehicle mass and the drive-train pa-

rameters. This vehicle model assumes that the vehicle has a tractive capability that

comes from the normal force at the tire patch and the coefficient of friction, shown

in equation 2.8. This tractive capability can either be used to generate lateral or

longitudinal acceleration.

This model has some significant drawbacks. First, with a RWD car, only the

tractive capability of the rear wheel is able to generate longitudinal acceleration.

With the single mass model there is no discrimination between front and rear wheels,

which means this model is unable to accurately differentiate between 4WD and RWD.

Similarly the way that lateral acceleration is generated by the car requires knowing

the steering angle, as well as the slip ratio of the tire. Again this is simplified to just

tractive capability of the imaginary single tire with this model. Despite the simplistic

nature of this model the predictive results that can be achieved are still impressive.

19

2.2 Simulation Design

This simulation works by taking a map that is a series of elements that contain

information about both the length of the element and the radius of the turn that

it approximates. From this data the simulation splits these elements into segments

which contain one turn each. This segment is then split into two further subdivisions

around the apex of of the turn, which is defined as the minimum radius element,

and is therefore the minimum speed of the turn. From this point the simulation uses

backwards distance steps to solve for the velocity of all elements before the apex, and

forward distance steps for all elements that are after the start point. This creates a

segment that is made up elements that are continuous in velocity.

Once a segment’s velocity has been determined the segment is added to all the

previously solved segments. Continuity of velocity is then checked over these elements.

If the velocity is continuous the simulation moves onto the next segment. If it is

not, the previous segment is resolved starting at the new segment velocity until a

continuous velocity profile is created. This method allows the effective generation of

a complete velocity profile for a given map.

2.3 Coordinate systems, and Units

The global coordinate system for this model is based on the generated map. This

global coordinate system is a 2D XY plane, where the start and end points are

arbitrary. It is important to note that all altitude change is ignored. The origin of

the global coordinate system is arbitrarily determined to allow the entire track to

be in the first quadrant. On this global coordinate system a car coordinate system

can be mapped using the standard SAE format, which is shown in figure 2-1[5].

Positive X is the forward facing vector, positive Y is the right pointing vector and

Z is a downward vector. Leading to forward acceleration, gravity, and turning right

all produce positive accelerations in the car reference frame. Roll, pitch and yaw

describe the rotation of the car about the same set of axes. The origin of the car is

20

defined at the center of gravity, which is convenient for this model because it allows

no generation of moments.

Figure 2-1: Vehicle axis system [10]

2.4 Assumptions

This simulation is based on a series of assumptions which are listed and commented

on below.

1. There is no significant change in altitude during the course of a lap 1

2. At the tightest radius in a turn, a car traveling at its maximum possible velocity

will be in purely lateral acceleration2.

3. Each element is a distance step and the car’s velocity is a linear approximation

from the velocity at the beginning of the element (𝑉𝑖𝑛) to the velocity at the

end of the element (𝑉𝑜𝑢𝑡). Furthermore the 𝑉𝑖𝑛 of an element is equal to the

𝑉𝑜𝑢𝑡 of the previous element, and 𝑉𝑎𝑣𝑒 is defined by equation 2.1.3.

𝑉𝑎𝑣𝑒 =𝑉𝑖𝑛 + 𝑉𝑜𝑢𝑡

2(2.1)

1This assumption proves to be good during the annual FSAE competition but will provide someproblems during normal testing of the car. The track that the car is tested at (Palmer Motor-sports Park), features significant altitude change. This will have to be addressed through carefulconsideration of the data collected

2This assumption is the catalyst for how the simulation handles corners, and is found to be bothintuitively true and well supported based on GPS data.

3This linear assumption is acceptable if all elements are small.

21

4. The brakes can always provide more force than the tires can transmit to the

ground 4.

5. The coefficient of friction between the tire and the ground is constant5.

2.5 High level code structure

This simulation is built using a series of MATLAB functions that are called in

series and in loops in an overall MATLAB code. This structure provides a lot of

flexibility which is essential to this project, as the future of this simulation will uti-

lize more sophisticated vehicle models within the same framework. This architecture

allows more complicated vehicle models for longitudinal and lateral dynamics to sim-

ply be dropped into the functions that govern the car’s dynamics. A function based

structure also allows for effective debugging of components of the code independently.

Finally the structure helps to simplify the overall code by allowing the easy reuse of

functions in different locations.

The overall simulation follows a series of steps that is very intuitive, and similar

to how a driver would approach racing on a given track. The first step is to create

a path for the car to follow, and this process is described in section 2.6.2. The map

then gets split into segments, which are each defined as a single turn. A turn can

vary widely in how it affects car velocity, from a slalom section, where a very slight

turn is required, to a hairpin, in which the car will slow almost to a crawl and make

a full 180∘ turn. The splitting of the map into segments is described in section 2.6.3.

The next step is to identify the apex (defined by the assumptions) of the turn. This

function examines one segment at a time and identifies the slowest part of the turn.

This function is described in section 2.6.4. The slowest part of the turn will be the

4This is an excellent assumption, because the FSAE rules require that the car pass a braketest. The brake test consists of the car accelerating, then breaking hard, until all 4 tires performa "lockup"[7]. This is a demonstration that the brakes are capable of overcoming the tractivecapability of the car.

5This assumption is an okay place to start but does not accurately model the tires, which havea load sensitivity that will change the coefficient of friction based on the force applied[11]. This issomething that can be added to a future vehicle model.

22

starting point for the next section, which will actually handle the determination of

velocities at each element. This is the most complicated function and is actually made

up of several subsections to handle all of the different possible cases. Ultimately this

is the heart of the code that will handle the longitudinal and lateral dynamics of the

car at each time step, and is described in section 2.6.5. Finally the user can develop

any set of data visualization tools that are helpful. Two examples are included in

section 2.7. This whole structure is shown in figure 2-2.

Figure 2-2: High level block diagram of code structure

23

2.6 Subsystem Functions

2.6.1 Car Parameters

The car parameter generation function creates a struct MATLAB variable that

encodes all of the different aspects used to describe the car. This could also be done

by simply saving this struct as a .mat file and loading it. By instead utilizing a

function, the simulation allows the user to implement parameter sweeps within the

code without having to manually change the parameter of interest every time. For all

of the testing that was conducted for this project the parameters were not changed.

The parameters and the values used are shown in table ??

Table 2.1: Car Parameters

Name Value Units

Mass 287 KG𝐶𝐷𝐴 1.4877𝐶𝐿𝐴 3.005

Air Density 1.1455 𝐾𝐺𝑀3

Drivetrain Efficiency .99Gear Ratio 3.933Tire Radius 0.2286 Meters

𝜇 1.3[12]Gravitational constant 9.8 𝑀

𝑆3

2.6.2 Path Generation Techniques

There are many ways to create a map for a simulation. Each has its own merits

and use cases. In this project I include and use three different techniques that provide

varied sources from which simulations can be run.

Picture Data Processing

One map generation technique that is particularly useful is the ability to take a

picture and convert it to a point cloud. This is useful because the FSAE competition

24

provides teams with maps for all dynamic events before the competition in the student

handbook [8]. These images can be found online for many different competition

locations and years. This data-set also comes paired with competition results which

include the times and some basic vehicle parameters for each car in each event. The

time of each car in each event gives the most basic data point for a simulation check

which will be used in section 3.3. Additionally, MIT Motorsports has data from

logging at competition for many of the years we competed in dynamic events.

The function described in this section takes a picture, like the one shown in figure

2-3, and looks for a certain color. For this particular map it is a light purple. The

code looks through the image and identifies all the locations of the light purple color,

and records their pixel coordinates. This mapping can then be overlayed onto the

original picture as an effective way to check the code. This is shown in figure 2-4.

One important note is that the image is a mirror of the original image. This will have

no effect on the actual quality, so there is no point in mirroring the original image to

alleviate this.

Figure 2-3: Image provided by SAE de-picting a single autocross lap [8]

Figure 2-4: Overlay of extracted pointsover the original map

25

There is now a point cloud of the map stored as global X and Y positions. This

point cloud will require some post processing before it can be useful to the simulation.

The first step is the conversion of a rasterized point cloud (an artifact of how it was

obtained), to a sequenced series of points that describe the path the car will follow.

This is done by determining a start point, then finding the closest point, and then

repeating the process. This generates a sequenced series of points, which appear the

same as figure 2-4, but will now be correctly ordered.

The final step is to apply some smoothing to the point cloud, which is essential

because the simulation is sensitive to small deviations in point position. The im-

portance of this will become evident in section 2.6.3. This is done using a Gaussian

smoothing function, and the fit is selected by the user. The current process is to

plot several different smoothed overlays, and then to select the one that appears to

best capture the map without losing details. This is especially important in features

like a slalom, shown in figure 2-5, where the movement of the car is small, but has a

large effect on the allowable speed of the car. This series of different sized smoothing

windows is overlayed, so that the user can make a determination. An example of this

overlay is shown in figure 2-6.

The final step is to perform a dilation, which is a unit conversion from pixels to

meters. The scale is easily determined by measuring the scale provided on the FSAE

track in pixels. The culmination of all of these steps leads to a completed point cloud

map that is a faithful representation of what was raced at competition. This can be

compared to the actual autocross length which is given as approximately 800 meters

[8]. The picture conversion tool is most useful when looking back at old tracks, where

the team did not compete or does not have GPS data. This ability allows the team

to get an idea of how they would have performed in dynamic events at competitions

that the team was unable to attend.

Debugging Map Creator

The debugging map creator is an essential tool for debugging and verification of

the simulation. This is by far the simplest map generation tool, and can be used to

26

Figure 2-5: A car weaves through an autocross slalom section similar to an FSAEtrack [1]

create simple, very clean point clouds in almost any shape. The maps generated that

are particularly useful are straight line acceleration, semicircle, and sin functions. The

debugging map creator provides the highest quality output, where the segmenter is

able to produce very smooth radius estimations without smoothing. The drawback

of this method is that all of the track attributes must be coded by hand, therefore to

create a function that accurately represents lap data would take considerable time.

Consequently, this tool is best used for simple track configurations where the creation

is intuitive.

Testing Data

The final tool for creating a map is to use logged GPS data from the car. This

tool is important because it is the only tool that is paired with real car data, which is

essential for validation. This data-set does present some large challenges in preparing

the map for the simulation, and also presents some problems with the assumptions

made. The largest challenge is the accuracy of the GPS coordinates. The GPS

position is coupled with an accuracy, and if the accuracy degrades then the points

can begin to create shapes that the car did not actually follow. The simulation

however will follow these points, creating a discrepancy. This issue will be addressed

with smoothing. The larger issue is that the car while driving a lap will often slip.

One of the core assumptions in this code is that the car does not slip. The slipping

27

Figure 2-6: Overlay of three different gaussian smoothing windows

will cause the car to create a map that has a velocity value that is not attainable in

the simulation. This can be partially addressed by smoothing, but not completely.

The best way to alleviate this issue is to modify the way that testing is performed.

This modified testing approach is described in section 3.5.1.

The first step in converting the testing data is to extract the data from the car’s

vehicle control unit (VCU), which is then converted to a .mat file, and uploaded to the

team server. This data will require a unit conversion as it is recorded in longitude and

latitude coordinates. The conversion is done using equation 2.3, providing position

of all of the points relative to one another, and normalizing them by subtracting the

lowest value.

𝑋 =𝑅𝑒𝑎𝑟𝑡ℎ × 𝑙𝑜𝑛𝑔𝑖𝑡𝑢𝑑𝑒× 10−7 × 𝜋

360−𝑚𝑖𝑛(𝑋) (2.2)

𝑌 =𝑅𝑒𝑎𝑟𝑡ℎ × 𝑙𝑎𝑡𝑖𝑡𝑢𝑑𝑒× 10−7 × 𝜋

360−𝑚𝑖𝑛(𝑌 ) (2.3)

𝑅𝑒𝑎𝑟𝑡ℎ = 6371000 Meters

Once a point cloud has been created the points must be split apart into different

28

laps. This can be done by plotting the longitude against time and finding the point

at which the line goes over the same longitude. This task is extremely simple and

will only have to be done once per data-set. This step will also serve as a trimming

step, where the ends of the data are trimmed such that there are not long portions of

time where the car is not moving. This is particularly important because if the car

is not moving it can result in elements that have a length of zero which would create

a singularity.

The resulting point cloud at this stage is very similar to the PNG output after

being correctly ordered. Therefore the same smoothing techniques will be used here,

resulting in a finished data-set.

2.6.3 Splitting the Lap into Segments

Now that a map has been generated, the map has to be converted into elements.

The first part of this code is to calculate the radius that is created by each set of

three points. This process is done using equations described in Lap Time Simulation,

which is summarized below, and which reference figure 2-7[3].

Figure 2-7: Determining radius and angle from a series of points [3]

𝑃 =360− 2𝐴

2= 180− 𝐴 (2.4)

29

R (the radius of point A) can then be determined using sin rules. R is the most

important output, it describes the radius of the turn the car is making at each element.

This formulation is particularly helpful because it is easy to assign a radius to each

sequential point in the determined map. This means that by creating a looping

function a radius is assigned to each point and stored.

sin𝑃 =𝑎

2𝑅

𝑅 =𝑎

2 sin 𝑝

𝑅 =𝑎

2 sin 180− 𝐴(2.5)

The next step is to calculate the angle that the three points make. This angle will

serve to determine where each of the turns starts and ends, and will also help future

simulations determine a steering angle. Angle A can be solved for using the cosine

rule.

𝐴 = 𝑐𝑜𝑠−1(𝑏2 + 𝑐2 − 𝑎2

2𝑏𝑐) (2.6)

Another aspect that needs to be extracted from the map points is the distance between

every point. Depending on the format and level of conditioning of the data, this could

be a constant or varied distance. The simulation will require a certain element size

to reach an acceptable level of accuracy. The distance between each step will be easy

to calculate, with a little help from an old friend, Pythagoras.

𝑑 =√︁𝑑𝑥2 + 𝑑𝑦2 (2.7)

𝑑𝑥 = 𝑥(𝑛)− 𝑥(𝑛− 1)

𝑑𝑦 = 𝑦(𝑛)− 𝑦(𝑛− 1)

𝑛 = 𝑒𝑙𝑒𝑚𝑒𝑛𝑡 𝑖𝑛𝑑𝑒𝑥

30

The last value that needs to be determined is the beginning and end of each turn.

These values will be used to determine the segment size that is passed into the ac-

tual driving function. This process is relatively simple and compares the angles of

neighboring elements to determine where each turn begins and ends. This requires

some rounding to prevent small osculations around zero from triggering creation of

multiple segments. The importance of the segmenting goes back to section 2.5. If

the segments do not capture the entirety of a curve then the code will not perform as

efficiently, because the driver function will have to run multiple times over the same

section and recalculate points. Poor placement will also have adverse effects on the

calculated lap time.This was proven by selecting the switches randomly, instead of by

the angle change. The random switch selection is repeated a thousand times and the

various resulting lap times were plotted compared to the correct selections in figure

2-8.

Figure 2-8: Lap times of 1000 iterations of random segment locations compared tocalculated segments

31

The segmenter has taken a map and converted from a point cloud to a series of

elements with known length and radii. These elements were then split into segments

that represent individual turns. This format will be used for all of the proceeding

simulation computations. The only other time the point cloud will be used is for

visualization. Figure 2-9 shows how a simple map, made up of two straights linked

by a constant radius turn would be segmented.

Figure 2-9: Example of a simple map split into three segments

2.6.4 Driver Vision

The driver vision function is the simplest function in the code, and is the first

function in the simulation loop that can be seen in figure 2-2. This function takes in

the radii produced in the segmenter, and the segment number. This function looks at

all of the points in this vector, and selects the point with the smallest radius, assigning

that index the starting point tag. This starting point is the apex of the turn and will

subdivide each segment into 2 sections. At the minimum radius, the car should be in

pure lateral acceleration (if there are not other limits). This gives the simulation a

starting point from which it can solve for the rest of the points. Some of these points

will be solved for using a backward distance step and the rest will utilize a forward

32

distance step.

2.6.5 Driving Function

The last core function is the driver function. The driver function has four distinct

modes. Three of these modes allow the driver function to reach every point on the

map. These functions are named based on their distance step direction. The first

mode is called start. Start will determine the velocity at the minimum radius point

determined in driver vision. Backward will often be the next mode. Backward uses a

backwards distance step to solve for velocity, given a known 𝑉𝑜𝑢𝑡(which is the same as

the inlet velocity of the next time step). The backwards step will then solve for 𝑉𝑖𝑛.

The next function is the forward function, and it is how the velocities are determined

from the start point until the end of the segment. The math performed is almost

identical to the equations performed for the backward time step, with the difference

that this version has a known 𝑉𝑖𝑛 which is the same as the final velocity of the previous

distance step. The forward step will then solve for the 𝑉𝑜𝑢𝑡.

The start, backward, and forward modes are able to create a complete map of

velocities of the map. The only problem is there can be discontinuities between the

segments. A discontinuity occurs when the segment(n) ends at a velocity higher than

the starting velocity of the segment (n+1). This does not violate any of the core

equations so must be treated as a separate mode. This mode is called backwards

only. Backwards only starts at the point at the end of the segment(n), and performs

a backward operation with the maximum allowable braking acceleration, and replaces

the velocities that had been in the distance step with the new lower ones. It then

checks to see if the new velocities have met the old velocities, and will continue to

overwrite the velocities until the velocity is again continuous. Then the the code can

continue to the next segment.

All of these different driver modes use very similar code to determine how fast

the car can be going, but every step actually consists of several different calculations

that all will determine different potential velocities for the car. The software will

then select the slowest of these velocities to be the limiting factor, and therefore the

33

velocity of the car. These limiting factors are as follows:

1. Maximum speed: the maximum speed the car could be going if it where to use

all of its tire capability to accelerate forward, given a 𝑉𝑖𝑛.

2. Motor limitations: the amount of torque the motor can provide at any given

point based on a motor curve, gear ratio and the speed of the car. The car can

never use more torque for accelerating than the motor can provide.

3. Grip limitation: the amount of force the car is able to transmit to the ground,

and will always first be used to satisfy the longitudinal requirement(turning),

and then leftover will be utilized to accelerate the car longitudinally (speed up

or slow down).

A combination of all three of these limiting functions is used for three of the modes,

but for the backward only mode only the grip limitation is required. This is because

the backwards only mode is only used in braking (therefore the motor limit does not

apply). The maximum speed limitation is not required because the backwards only

mode is only used when determining velocities less than a previously allowed velocity.

Therefore the maximum speed cannot be violated.

Start Mode

The start mode is the simplest mode to design but unfortunately will only be

used once per segment. The approach to this is a simple balance of forces which

can be seen in Lap Time Simulation[3]. The assumption that all of the available tire

capability is being used in the lateral direction (taken from the assumptions), means

that a simplified force balance is possible and shown in equation 2.8.

𝐹 2𝑡 = 𝐹 2

𝑐 + 𝐹 2𝑑 (2.8)

𝐹𝑡 = 𝜇𝑁

𝑁 =1

2𝜌𝐶𝐿𝐴𝑉

2 +𝑚𝑔

34

𝐹𝑐 =𝑚𝑣2

𝑟

𝐹𝑑 =1

2𝜌𝐶𝐷𝐴𝑉

2

With the following variable definitions:

𝜇 = static coefficient of friction

N = Normal force, with 2 components, static and down force [Newtons]

m = Mass of the car [KG]

g = Gravitational acceleration[𝑚𝑠2

]

v = Velocity of the car[𝑚𝑠]

r = Radius of the turn [m]

𝐶𝐷𝐴 = Coefficent of drag, for the frontal area of the car

𝐶𝐿𝐴 = Coefficient of lift, for the frontal area of the car

𝜌 = Density of air [ 𝑘𝑔𝑚3 ]

These equations can then be substituted back into equation 2.8, leading to

(𝜇𝑅)2 = (𝑚2𝑣4

𝑟2) + (

1

4𝜌2𝐴2𝐶𝐷2

𝐴𝑣4)

(𝜇𝑅)2 = 𝑣4((𝑚2

𝑟2) + (

1


𝐴))

𝑣4 =(𝜇𝑅)2

(𝑚2

𝑟2) + (1


𝐴)

𝑣 = ((𝜇𝑅)2

(𝑚2

𝑟2) + (1


𝐴))14 (2.9)

Equation 2.9 determines one velocity value, for the element with the minimum ra-

dius, but each element is required to have three associated velocities, determined by

assumption three. This will again hinge on the pure lateral acceleration assumption.

If the car is using all of its tractive capability for lateral acceleration then longitu-

dinal acceleration (𝑎𝑙𝑜𝑛𝑔) must equal zero, therefore leading to equation 2.10. Now

the starting element has been fully defined, but it has only passed one of the three

35

limits. The other two limits come from comparing the velocities to the maxspeed

vector for that element. The formation of the maxspeed vector can be found in 2.6.5.

This vector will ensure that the maximum speed allowed by the lateral capability of

the car is not faster than the car could possible be going, and incorporates the motor

limits within it. If the maximum speed vector is lower than the vector created then

the values are replaced.

𝑉𝑎𝑣𝑒 = 𝑉𝑖𝑛 = 𝑉𝑜𝑢𝑡 (2.10)

All of this has led to a fully described element. The problem is several of these

parameters described are velocity dependent. This means that the velocity triplet will

be stored and the element rerun, given the new velocity assumption. Then the old

velocity can be compared to the newly generated velocity to create a remainder. This

remainder will be an apriori error estimate. The segment is run multiple times and

the remainder is found to decrease as the velocity becomes closer to the true answer.

The loop can be exited when the remainder is less than the required accuracy. This

means that the velocity solved for is within the required range (or error limit) of the

true solution. This assumes that the true solution run two times through the loop

would result in an error of zero, because all of the forces would be balanced.

It is not feasible to actually run the remainder to zero because of numerical limits

as well as time. Therefore an error limit must be determined. This error limit will

determine the numerical accuracy of the entire simulation. For the purpose of this

project an error limit of .1 𝑀𝑆

was used. This value can be refined based on the

requirements of the simulation being run.

Upon the satisfaction of all of the above parameters, the starting element has a

determined velocity that meets the given accuracy requirements. This element will

be the spring board from which the rest of the segment’s velocities will be calculated

using the forward and backward approaches.

36

Backward Distance Step

After solving the first point, the simulation will move onto all of the points that

come before the starting point, but after the beginning of the segment. In the case

there are no points in this section, the simulation would simply move onto the forward

distance step solver.

The backward distance step uses much of the same setup as the start mode, but

there are several key differences. The first key difference is that now the 𝑉𝑜𝑢𝑡 value

will be known. This is because of the assumption 𝑉𝑜𝑢𝑡(𝑛) = 𝑉𝑖𝑛(𝑛 + 1). So the first

step for our backward distance step is to assign 𝑉𝑜𝑢𝑡. The next step will require a

𝑉𝑎𝑣𝑒. The loop will use the previous steps 𝑉𝑎𝑣𝑒 as a first guess. This is not required,

but it will help to reduce the number of iterations that are required in order to reach

the targeted error.

The heart of the backward step is to use the 𝑉𝑎𝑣𝑒 and radius of the turn to estimate

the amount of force required to achieve the correct lateral acceleration. This is done

using equation 2.11. Now the amount of leftover tire capacity can be determined.

This is a simple magnitude calculation that is performed using equation 2.12. It is

important to first check that the force required to make the turn is less than the total

available force. If it is not, then the car is going too fast. This results in a negative

acceleration, which will reduce 𝑉𝑎𝑣𝑒 in the next loop. This is done by setting a flag

to fix the imaginary value that would have been obtained in equation 2.12.

𝐹𝑐 =𝑚𝑉 2

𝑎𝑣𝑒

𝑟(2.11)

𝐹𝑙𝑜𝑛𝑔

√︁𝐹 2𝑡 − 𝐹 2

𝑐 (2.12)

The code now has two separate options; one if 𝐹𝑙𝑜𝑛𝑔 is positive, where the car

will be accelerating, the other when 𝐹𝑙𝑜𝑛𝑔 is negative, and the car will be slowing

down. If 𝐹𝑙𝑜𝑛𝑔 is equal to zero either option may be used because there will be no

acceleration. If the force is positive, it means additional power is being added by the

motor. 𝐹𝑙𝑜𝑛𝑔 represents the most possible force that could be applied, but the motor

37

provides an additional constraint. The motor limiting is specified in section 2.6.5.

After determining the maximum force the motor is capable of delivering, the lesser

of the two values between tractive capability and motor force is taken. This ensures

that the car is adhering to both the grip limit and the motor limit. The final step is

to calculate the longitudinal acceleration using a force balance and Newton’s Second

Law. The summation of forces comes from two places. The first is the longitudinal

force calculated in the previous step, and the second is the drag, associated with the

car’s aerodynamics. The full equation is shown in equation 2.13.

𝑎𝑙𝑜𝑛𝑔 =𝐹𝑑 − 1

2𝜌𝐶𝐷𝑎𝑉

2𝑎𝑣𝑒

𝑚(2.13)

The final step is to find the new values of 𝑉𝑖𝑛 and 𝑉𝑎𝑣𝑒, which can be done easily

using 𝑉𝑜𝑢𝑡, which is known, as well as the length of the element, which is also a

known value. The value of 𝑉𝑖𝑛 is determined according to equation 2.14, and 𝑉𝑎𝑣𝑒 is

determined using equation 2.15. This has now created a complete velocity triplet. As

with the starting element, these velocities must be checked to make sure they do not

violate the maximum velocity that was calculated at that element. The two velocity

triplets are compared, and the minimum is selected for each position.

𝑉𝑖𝑛 =√︁𝑉 2𝑜𝑢𝑡 + 2𝑎𝑙𝑜𝑛𝑔𝑑 (2.14)

𝑉𝑎𝑣𝑒 =𝑉𝑖𝑛 + 𝑉𝑜𝑢𝑡

2(2.15)

This completed velocity element will be passed back into the function to calculate a

remainder based on the difference between the calculated velocity between iterations.

This remainder will be treated in the same manor as the remainder for the starting

mode, and will be required to meet a certain error bound before allowing the element

to be considered correct. Once the error requirement has been met, the simulation

will move on to the next backward step element until the beginning of the segment

is reached.

38

Forward Distance Step

The final of the initial three modes is the forward distance step. The forward

distance step will fill in the end of the segment between the start point and the last

point in the segment. The forward distance step will have almost identical equations

to the backward distance step with two key differences. The first difference is the

knowns and unknowns. For the forward distance step 𝑉𝑖𝑛 is known, from the assump-

tion 𝑉𝑖𝑛(𝑛) = 𝑉𝑜𝑢𝑡(𝑛− 1). The force determination to calculate 𝑎𝑙𝑜𝑛𝑔, is the same as

with the backward step, and therefore uses equations 2.11,2.12 and 2.13. The sec-

ond difference will come in the calculation of 𝑉𝑜𝑢𝑡, using equation 2.16, which is very

similar to equation 2.14, but has 𝑉𝑜𝑢𝑡 switched with 𝑉𝑖𝑛.

𝑉𝑜𝑢𝑡 =√︁𝑉 2𝑖𝑛 + 2𝑎𝑙𝑜𝑛𝑔𝑑 (2.16)

The final step for the forward step is the same as the backward step, and 𝑉𝑎𝑣𝑒, is

calculated using equation 2.15. Then the same maxspeed checks are performed. This

will begin the same iteration loop until the error is satisfactory, at which point the

simulation will move onto the next element.

Backward Only Mode

The final mode for the driving function is the backward only mode. This is

the mode that checks for discontinuities in the velocities between segments and is

triggered if there is one. It is important to first realize that there can never be a

discontinuity where the newest segment starts at a higher speed than the previous

segment ended. This is due to the implementation of the maxspeed function which is

described in section 2.6.5. When a discontinuity exists, a modified implementation of

the backward distance step will be used. The starting point for this function will be

the last element in the segment before the discontinuity. For the first element to be

resolved 𝑉𝑜𝑢𝑡 is set to be 𝑉𝑖𝑛 of the first element of the newest segment, just as in the

normal backward step. The force balance equations are also the same, until equation

2.12. This equation will be modified after being solved. 𝐹𝑙𝑜𝑛𝑔 in this mode will be

39

dedicated completely to braking, which leads to two things; first 𝐹𝑙𝑜𝑛𝑔 will always be

positive, second there is no upper bound, which is shown by the braking assumption.

The backward time step then continues normally, generating a complete velocity

triplet. This velocity triplet is then compared to the existing velocity triplet. There

are two different possible cases. In the first case the entire new velocity triplet is

smaller than the old velocity triplet, as shown in figure 2-10. If this is the case the

old triplet is replaced with the new triplet and a backward distance step is taken to

continue resolving. In case two at least one value of the old velocity triplet is smaller

than the new velocity triplet. If this is true, the discontinuity has been repaired. The

two triplets are then patched together, 𝑉𝑜𝑢𝑡 is taken from the resolve, 𝑉𝑖𝑛 is taken

from the original velocity, and 𝑉𝑎𝑣𝑒 is calculated according to equation 2.15. This is

shown in figure 2-11. The function then kicks itself out of the loop and the simulation

is allowed to move onto the next unsolved segment.

Figure 2-10: element velocity plot in backstep solving

Figure 2-11: Final element velocity plotin back step solving

Maximum Speed Vector

The maximum speed vector is a function that will utilize the forward distance

step. The purpose of this vector is to determine the maximum speed that could be

40

attained at any point in a segment. This is an important limit, because it prevents

discontinuities from occurring within the segment in places where the car is not using

much of its lateral capability. This vector is generated by taking the 𝑉𝑜𝑢𝑡 of the

previous segment, or in the case of the first segment, zero, and using it as 𝑉𝑖𝑛. From

there, forward distance steps are used to determine the maximum possible speed

that could be reached at each element. A maximum speed vector is created for each

segment so that it can be compared to each velocity triplet.

Motor Limit

The motor limit command will utilize a torque speed curve for the motor in the

car’s powertrain. This command will use the car velocity to determine the maximum

torque the motor can apply. This torque will then be translated into a force at the tire

patch using the given powertrain efficiency, tire radius and gear ratio. The command

then outputs the maximum force the powertrain is capable of producing.

2.7 Data Visualization

The two data visualization plots that are most useful in validation of this simula-

tion are velocity plots and a velocity overlay on the map. The velocity plots provide

more information to the user, but the velocity overlays give a much more intuitive

feel for what the data should look like.

2.7.1 Velocity Plot

There are several velocity plots that are generated with this simulation, each is

useful in different situations. The first is the simplest, velocity as a function of element

number. This plot is most helpful when there is real data that can be overlayed and

the same number of steps are used. The second velocity plot is a velocity distance

plot. This plot provides a more accurate scaling for looking at data. The distance

vector is generated by taking a cumulative sum of the length of each element. The

final velocity plot is a velocity time plot, which displays the velocity as a function of

41

time. Similar to the distance vector, the time vector is generated using a cumulative

sum.

2.7.2 Velocity Overlay on Map

The velocity overlay map is extremely useful for intuitive checking of the simula-

tion. This figure plots the velocity at each time step as a color that goes from red at

the slowest velocity to green at the fastest. This allows the user to quickly look at

the results and determine if the simulation is slowing down in the tight corners and

speeding up in the straights. This ability to intuitively validate the code has proven

useful on many occasions.

42

Chapter 3

Validation

3.1 Validation Goals

During the development stages of each of the functions described in the previous

chapter, small test cases were utilized to help find and eliminate errors. While this is

an important part of the development, this small scale testing will not be discussed,

due to their specific and tedious nature. The validation will instead focus on utilizing

known parameters of the car to be able to predict the performance from recorded

testing trips and competition. This is a large goal, and therefore will be broken down

into sections that are described in section 3.2. This approach allowed debugging to

occur at each step, which made finding bugs much more manageable, and ultimately

led to achieving the stated goal and accurately predicting the performance of the car.

3.2 Validation Structure

The validation structure was designed to start small and work up to being able

to test the full stack of code. The tests followed this progression:

1. Simple contrived track, uses only longitudinal dynamics, an acceleration run,

described in 3.3.1.

2. More complicated contrived track, uses longitudinal and lateral dynamics, track

43

looks like the letter U with constant radius, described in 3.3.2.

3. Most complicated contrived track, further stresses the lateral dynamics, track

looks like the letter U with variable radius, described in 3.3.3

4. Small sections of real testing data, the data is kept short which allows for careful

selection and conditioning of data to improve the point cloud quality, described

in 3.4.1

5. Full lap simulation, most strenuous test of the full stack, described in section

3.4.2

Each of these steps provides a new challenge for the simulation to overcome.

Following this structure, many bugs were uncovered sequentially. This procedure

made the debugging process manageable, and prevented wasting large amounts of

time looking for problems when there were a lot of changing variables.

3.3 Creating Useful Test Cases

The validation structure described in section 3.2 will require the generation of

several different environments for the simulation to use as test cases. In an ideal

scenario each of these test cases would be paired with real data that was collected

specifically for this purpose. Due to the COVID-19 pandemic this was not possible,

as all testing trips were canceled. Instead test cases were designed to use competition

data. This is useful because the car is at a known configuration and mass for all of

competition, and uses a fresh pair of tires. All of these help to eliminate factors that

would otherwise be difficult to control in other testing data-sets.

3.3.1 Acceleration Run Test Case

The first and simplest track is a straight line, shown in a very exciting figure 3-1.

This map is designed to be the same length as the acceleration event in the FSAE

competition (75 meters)[7]. As a result, the data can be compared to the acceleration

44

event from the competition. The simplest way to conduct this comparison is by using

the time taken to complete the "lap". The simulation results in a laptime of 3.7483

seconds, which can be compared to the competition result of 4.121 seconds[6]. In

this case the simulation performance is much better than that of the real car. This

is something that is expected for several reasons. First, the simulation is always at

the very limit of the car’s tractive capability, something a driver can only aspire to

achieve. Second, due to the nature of the acceleration event, the car has relatively

cold tires. This will reduce the 𝜇 of the tire some as compared to the number that is

used from Tune to Win[12].

Figure 3-1: Model of standard FSAE acceleration track

45

Beyond the simple laptime, it is important to also look at a velocity distance plot.

This plot is shown in figure 3-2. This plot looks exactly as it is expected to look, with

the peak acceleration at the beginning and with a taper towards the end. The taper

comes from a combination of the motor reaching its power limit, and the aerodynamic

drag increase. While data for this event was not available to do a direct comparison,

this plot passes an intuitive check.

Figure 3-2: Velocity of the car on a straight track shown as a function of distance

Finally the map was modified to be significantly longer, 1000 meters, and the

simulation was run again. This verified that the car would reach a steady state

velocity after a long time. This steady state should be reached based on the drag

of the car and the motor curve. The results are shown in figure 3-3. This can be

46

compared to the recorded max speed of the car, which is between 33.5 and 35.8 𝑀𝑆

.

The simulated speed is 33.4𝑀𝑆

, which falls within that range.

Figure 3-3: Velocity of the car on a straight track shown as a function of distance

3.3.2 Constant Radius Turn

Now a second layer of complexity can be added. This complexity comes in the

form of a constant radius turn, as shown in figure 3-4. This will stress the code in

several ways. First it will stress the segmenting code. The segmenting code must both

correctly convert the point cloud into a series of radii, and then identify correctly the

three segments shown by the orange X’s. Next the code will have to correctly evaluate

47

the velocities of the car and determine that the car is capable of going at a constant

speed for the whole time. This will all come from the driving function. While it is

easy to intuit the correct shape for this velocity plot, by making a smart choice for

the radius of the turn, competition data can again be leveraged.

Figure 3-4: Map created using debugging map creator with straights and a constantradius

The competition data leveraged in this validation step is the skidpad event data.

The data available from the skidpad event is only a time, for a somewhat known

distance. A map of the skidpad event is shown in figure 3-5, making the simple

assumption that the car at competition went through the middle of the cones1, the

radius of the turn can be determined to be 9.125 meters. The MY18 car was able to

perform the full circle in 5.36 seconds [6]. Using the assumption that a constant speed

is maintained during skidpad, which is the goal of the event, the speed of the car can

be determined as shown in equation 3.1. This result can be compared to the steady

state speed achieved while turning in the simulation. The two are plotted together in

figure 3-6. Again the simulation predicts a higher velocity than that reflected by the1The best skidpad drivers will hug the inside cones of the circle, reducing the total distance

traveled. The minimum radius is the radius of the inner circle plus half of the track width. Whilethis is possibly how skidpad was driven at competition, the difference in length is small so the simplerapproximation will be used

48

data, with a velocity of 11.18 𝑀𝑆

. This error can be largely attributed to two things.

First, the driver is not at the limit of the tractive capability at all times during the

event, whereas the simulation is. Second, is the possible difference in the radius that

was actually traveled in the event. Both of these errors point to the simulation being

faster than the real result, which it is.

10.6967 =2× 9.125× 𝜋

5.36[𝑀

𝑆] (3.1)

Figure 3-5: Compettiont skidpad course[7]

An additional part of simulation that is tested in this case is the backwards only

solving. By looking at figure 3-6, the velocity is continuous across all time. This is

the first hint that the backwards only mode is working. This mode is utilized between

the first straight and the turn, and the simulation is able to link the two sections with

a nonlinear braking function. When comparing this slope of braking to the slope of

forward acceleration, it looks to be a little bit steeper. This fits in well with the way

the model is addressing this section because no motor limit is being applied. The

continuity and slope show that the backwards only function is working as expected.

49

Figure 3-6: The velocity plotted againstthe distance traveled comparing the sim-ulation to competition results

Figure 3-7: Velocity of the U-Turn map

3.3.3 Variable Radius Turn

The next test case is a variable radius turn. Unlike in the previous example this

will require the simulation to determine change in longitudinal velocity while also

turning. Unfortunately this is not well approximated by any competition results, so

the results of this test case will be examined from a purely intuitive standpoint. To

generate this map a sin function was used, with a magnitude of 9.125 meters, so

the resulting map will appear similar to the constant radius turn. Again straights

are added to both sides to further stress the simulation by determining the braking

required.

The resulting figures look similar to those of the constant radius but the simula-

tion has correctly addressed the variable radius. The simulation is now able to have a

variable velocity during the turn, and therefore creates a smoother overall map. Fig-

ure 3-8, also shows the expected result. Since the radius is minimized in the middle

of the turn, the velocity plot shows that the simulation accurately predicts that the

velocity is also minimized.

This series of tests has shown that the simulation not only behaves as was ex-

50

Figure 3-8: The velocity plotted againstthe distance traveled

Figure 3-9: Velocity of the Variable ra-dius U-Turn map

pected, based on basic intuition, but also closely matches with a data-set that is

widely available to FSAE teams. The utility of this series of checks is not only their

simplicity but also the minimal amount of data required. At this point the simulation

appears to be an accurate predictor of car velocity in a variety of settings.

3.4 Utilization of Testing Data

The next step is to look at the simulation compared to data taken from logging laps

in testing. This will utilize the GPS point cloud converter that was described in 2.6.2.

There are several steps that are taken while doing this. Splitting the process into steps

helps ensure that bugs are discovered when the function the code is performing is not

overwhelmingly complex. Therefore the bug hunt is more manageable.

3.4.1 Small Map Testing

The simplest way to make this problem more manageable is to look at only part of

a lap. This reduces the number of segments so that a problem can quickly be isolated

and examined. The first test data examined was a ten second sample. There are also

51

some negative effects when looking at a small sample, the dominate one being it is

difficult to see a clear relation between the real data and the simulation. This difficulty

makes the examination of smaller samples an important step while debugging, but

when the code is working the figures produced are not very interesting.

3.4.2 Full Lap Testing

After following the steps above the user can be reasonably confident the simulation

does not have any major bugs. This leaves the most important validation step,

comparing a simulated lap to a real lap. There are some important things to note

about this comparison:

1. The values for the car parameters are set based on the testing sheet and not

adjusted.

2. The smoothing value chosen for the point cloud was based on a comparison

similar to what was described in section 2.6.2.

These simulation settings are crucial to simulation validation. By not subjectively

changing these values, the validation shows that the simulation is making an accurate

prediction based on the underlying vehicle parameters. The simulation produces the

following figures for a practice lap set up at Palmer Motorsports Park. Figure 3-11

shows the track consisting of large and small radius turns as well as a hairpin; then

the course is run in reverse. The driver drove the course on slightly different tracks

in each direction. This is helpful to show the two directions more clearly.

The more interesting figure from a validation perspective is figure 3-10. The

first observation from this figure is how well the simulation is able to predict the

trends in the velocity of the car. The two plots show a 0.832 correlation factor

with 95% confidence bounds at 0.8233 and 0.8403. This overall trend is clear simply

by looking at the data and is solid evidence that the simulation is working. Upon

closer examination there is one large difference between the two data-sets; the testing

data appears relatively smooth, especially when compared with the highly variable

52

Figure 3-10: The velocity plotted againstthe step number overlayed with testingdata

Figure 3-11: Velocity shown as colors onthe practice map

values produced by the simulation. This is attributed to the GPS map that has been

generated. As the car moves, the GPS can artificially create smaller radius elements,

which cause the simulation to slow down and then quickly accelerate again. This is

not a real phenomenon but rather a byproduct of how the simulation is designed.

This can be partially eliminated by using more aggressive smoothing functions on the

data. The downside of this approach is it will also lead to larger errors between the

"cleaned" map and the true GPS data from the car. A balance must be found, that

produces a sufficiently smooth map without losing detail. Ultimately it can be found

that this variability did not have a significant effect on the overall predictive nature

of the simulation, but is an area for future work.

Another important discrepancy is occasionally the simulation goes slower than

the actual car. This should not be possible because the simulation should always be

utilizing the maximum tractive capability of the tires or be limited by the motor.

However there are times when the driver will exceed the maximum tractive capability

of the car and begin to slip. While slipping, the car is capable of performing a very

tight radius turn at a high rate of speed, something the simulation is unable to predict.

53

This is an inherent flaw in the simulation but does not appear to be a major error

contribution based on the data. Another reason for this discrepancy could be that

the GPS data conversion to radii does not perfectly reflect the path the car took.

This is again something that is difficult to predict and will add to the total error.

Despite the error sources discussed, the simulation is still able to accurately predict

the velocity profile of the practice lap and ultimately leads to a predicted lap time

of 53.23 seconds, compared to the real lap time of 52 seconds. While this is a clear

indication that the simulation is not perfect, it shows that the simulation achieves a

high level of accuracy.

3.5 Next Steps for Validation

To further the user’s confidence, the following two steps should be taken to increase

the reliability and ensure the accuracy of the simulation. The first is modifying the

testing procedure to better accommodate the needs of the simulation. The second is

a series of tests as outlined in section 3.5.2.

3.5.1 Testing Procedure for Simulation

MIT Motorsports has spent the past two years developing extensive testing proce-

dures. These procedures create records of what testing was performed as well as where

and what the conditions were for all tests. These records made the validation per-

formed on testing data possible, because the condition of the car was known. These

procedures need to be expanded upon in order to improve the quality of simulations

data, specifically by making the following changes:

1. The car should be weighed with the driver at the beginning of every trip. This

will ensure that the weight used for simulation is accurate. This is especially

important during the fall testing season when the vehicle mass often fluctuates

significantly with the sensor package being utilized.

2. The first lap that is driven on a course should be a GPS logging lap. This

54

lap should be driven slowly and in the proper racing line. This will give the

simulation a clear and higher quality GPS track to follow and will help to

eliminate many of the problems that can arise from looking at the GPS data

from a flying lap.

3. Driver mistake tracking needs to be improved. While the current testing pro-

gram has the capability to take extensive notes about the test, this ability is

not often used. In order to ensure that all problems in a lap, such as sliding or

missing cones, are written down, extensive note taking and monitoring must be

enforced. This will help to make sure the comparison between the simulation

and test is fair.

4. A filled out car setup sheet should accompany each data-set. This setup sheet

will go beyond simple mass and aerodynamic recording to describe the actual

setup of the car, which will be useful in future simulations that have more input

variables.

By implementing these changes in the testing program MIT Motorsports will be

able to reliably create data-sets for the simulation. This large repository of clean and

well created data-sets will not only be useful in the closing stages of validating the

simulation, but in the validation of future more complex vehicle models.

3.5.2 Testing Sweeps to Ensure Predictive Nature

After implementing the new testing procedures the testing team will be able to

create clean and useful data-sets for the simulation. The next step is to perform

variable sweeps, to empirically determine the car’s sensitivity to different parameters.

These variable sweeps will be mirrored in the simulation to validate that the sensitivity

of the two is the same. This is an important series of tests. One example of the

testing sweep’s utility is in setting a mass goal for the car. It is obvious that less

weight is better when designing a racecar, but being able to predict the impact on

performance that every kilogram makes, in each aspect of the competition, will lead

55

to better engineering decisions. For the simulation in its current state a series of three

parameter sweeps would be most beneficial.

1. Aerodynamic sweep: The best case would be to independently sweep 𝐶𝐷𝐴 and

𝐶𝐿𝐴, but that does not seem feasible within the limitations of the team. Instead

the two will be adjusted together, as this is a simpler procedure. This can be

done by removing aerodynamic elements from the car, such as the front wing,

rear wing, and diffuser 2

2. Mass sweep: Variable amounts of ballast are added to the car as close to its

center of gravity as possible.

3. Motor Power: This sweep can be done in several different ways; one option is

to limit the maximum power provided, while another would be to artificially

adjust the power curve3. Either of these approaches would provide a useful and

replicable data-set.

At the conclusion of this testing the simulation will have been validated not only on

the value of its output, which is done by looking at the results and comparing them to

their testing counterparts, but also on the values of their sensitivities. This two step

validation process helps to ensure that the correlations that are seen in the results

are not just artifacts of extremely good luck.

2This will not be a perfect test because by removing either of the wings the center of pressure willchange position in the car, unbalancing the aerodynamic package. These tests still provide usefulresults, as long as the user is aware of this problem.

3This will incur some controller error because when artificially limiting the motor there will besome undulations around the set point. The data should be reviewed before simulation

56

Chapter 4

Conclusion

This thesis sought to develop and validate a distance step based lap time simula-

tion. The code that was developed was able to accurately predict both the velocity

profile and the total time required to complete a lap, when given only information

about the track and the vehicle’s parameters. This capability shows that the simula-

tion is able to correctly evaluate vehicle performance based on the vehicle’s parameters

to correlate to actual performance with a correlation factor of 0.8067 with 95% con-

fidence bounds of 0.8028 and 0.8105. The validation done in this thesis is sufficient

such that the simulation can begin to be used in making architecture decisions for

the MY21 design cycle.

This thesis then described a framework from which future vehicle testing can be

done. If the plans outlined in this thesis are followed, the confidence in the model

will continue to grow. This testing plan will also give future simulation architects on

the team a better data-set to fully verify the future models created. This simulation

represents a huge leap in the MIT Motorsports simulation arsenal, and will be an

invaluable resource in deciding future car architectures.

4.1 Future Work

This simulation represents the simplest possible vehicle model. The assumptions

that are made in this vehicle model make the simulation prohibitive to answering

57

some of the key questions that are required when deciding on a vehicle architecture.

Thus one of the most pressing pieces of future work is updating the vehicle model

that is used. Other important updates include the segmenter and error estimation.

Updating the vehicle model will come in a series of steps. The first step is to

utilize the Pacejka tire model to incorporate a load sensitivity into the coefficient of

friction. This will be a simple implementation because a Magic Formula Tire model

already exists in other simulations utilized by MIT Motorsports. The next step will

be to change the vehicle model from a single mass model to a bicycle model. This

conversion will be much more involved. The longitudinal dynamics will not present

much of an issue as they are already well encoded in existing functions. The lateral

dynamics will present new challenges not yet tackled by any simulations the team

uses. The architecture of the code is well equipped to be able to meet this challenge

as the lateral dynamics can be independently verified before being added to the full

simulation stack.

The segmenter needs to be updated in order to be more comprehensive. When

given more complicated and less clean data-sets the segmenter struggled to minimize

the number of segments that were identified. This not only had adverse effects on

the solve time of the simulation, but also negatively impacted the accuracy. By

changing the segmenter structure to better identify segments, both of these issues

can be reduced.

Lastly the error estimation needs to be made more adaptable. The code already

has an error estimate for each individual element. However it would be helpful to

allow the user to define a total simulation tolerance which would automatically adjust

the allowable error per distance step.

The final area of future work is the real-world validation of this simulation. This

area of work was originally going to be addressed by this thesis but due to the cancel-

lation of in-person classes during the spring semester of 2020, testing was not possible.

This validation will instead fall upon future team members of MIT Motorsports, fol-

lowing the procedures outlined in section 3.5.

58

Appendix A

Additional Simulated Lap Plots

59

2018 endurance lap data

Figure A-1: The velocity plotted asa function of time overlayed with en-durance data

Figure A-2: Velocity shown as colors onthe endurance map

Additional run at Palmer Motorsports Park one

Figure A-3: The velocity plotted againstthe step number overlayed with testingdata

Figure A-4: Velocity shown as colors onthe practice map

60

Additional run at Palmer Motorsports Park two



Additional run at Palmer Motorsports Park three



61

Bibliography

[1] William Byrd. Autocross 101. Website, January 2014.

[2] Dean E. Case. Formula sae - competition history 1981-1996. SAE TechnicalPaper 962509, SAE International, 1996.

[3] James Hakewill. Lap time simulation. Graduate thesis, Mechancial EngineeringDepartment, Jan 2000.

[4] Cheyenne Hua. Modeling and control of a four wheel drive formula sae car.Undergraduate thesis, Massachusetts Institute of Technology, Mechancial Engi-neering Department, May 2019.

[5] SAE International. Vehicle dynamics terminology. Technical StandardJ670_200801, SAE International, January 2008.

[6] SAE International. Formula sae electric 2018 results. Competition result, SAEInternational, Warrendale, PA, June 2018.

[7] SAE International. Formula SAE Rules 2020. SAE International, Warrendale,Pennsylvania, version 1.0 edition, Jul 2019.

[8] SAE international. Student Handbook Formula SAE electric. SAE International,Lincoln, Nebraska, Jun 2019.

[9] SAE International. Formula sae electric. https://www.sae.org/attend/student-events/formula-sae-electric/about, 2020.

[10] MathWorks. Coordinate systems in vehicle dynamics blockset.https://www.mathworks.com/help/vdynblks/ug/coordinate-systems-in-vehicle-dynamics-blockset.html, 2020.

[11] William F. Milliken and Douglas L. Milliken. Race Car Vehicle Dynamics, vol-ume 1. Society of Automotive Engineers, Warrendale, PA, first edition, 1995.

[12] Carrol Smith. Tune To Win. Aero Publishers, Fallbrook, CA, 1978.

63

Development and Validation Of a Single Mass Lap Simulation

Documents

Transcript of Development and Validation Of a Single Mass Lap Simulation