virtual vehicle systems simulation

virtual vehicle systems simulation
VIRTUAL VEHICLE SYSTEMS SIMULATION
A
MODULAR MULTI-CPU APPROACH IN REAL-TIME
by
G. Edzko Smid
A dissertation
submitted in partial fulfillment
of the requirements for the
degree of
DOCTOR OF PHILOSOPHY
1999
Oakland University
Rochester, Michigan
Doctoral Advisory Committee:
Professor Ka C. Cheok
Professor I. Schochetman
Professor M. Das
Professor K. Li
Professor G. Honderd
The Simulation of Automobile
where the World is Virtual and Time is Real,
will render a Sensation
of Genesis and Creation
of a Vehicle with Spirit and Feel.
i
Acknowledgements
The research that is presented in this dissertation could not have been conducted without the
fruitfull discussions and without the excitment and joy of creating the virtual driving simulation.
I would hereby like to express my full appreciation to Ka C. Cheok who has been my advisor,
collegue and best friend, for the scientific and moral support along the way. Furthermore I would
like to thank my committee. A special appreciation to Jim Overholt for detailed discussions and
good times.
Coming to the United States I realized that Delft University of Technology had provided me with
the sufficient background in systems and controls, to be able to adapt easily in a new environment
and to contribute effectively on collaboration projects. The atmosphere in Delft will always be an
example of a motivating environment with a good balance of professionalism and joy. In particular
would like to acknowledge Ton van den Boom, Ben Klaassens, Stefano Stramigioli, Michel
Verhaegen and Wim Jongkind. I owe my special thanks to Ger Honderd, as advisor for my Masters
and also as doctorate committee member. My thanks go to Naim Kheir for the opportunity to come
to Oakland after my graduation in Delft. In the first period of my stay, we have worked on a series
of projects for TACOM, Ford, Chrysler, ITT Automotive and TechnoResearch. The teamwork
during that time and the dynamic discussions were a strong motivation to continue my stay. Many
thanks with this regard to Kazayuki Kobayashi, Teik-Khoon Tan, Shinishi Nishizawa and Sandro
Scaccia. Also I would like to express my gratitude to Claudio Bonivento and Claudio Melchiorri
and the students at the Laboratory of Automation and Robotics (LAR) for the opportunity and
the joy to spend a summer at the Department of Electronics, Computer Science and Systems
of the University of Bologna during my graduate time. The opportunity to be involved with the
technology team at Echlin Automotive in spring 1996, and later with Dana Corporation contributed
to my assistantship. It offered me the ability to combine graduate school with the experience in
a proffesional environment. Therefore my respect to Mike Dougherty, Mohamad Qatu, Jack
Dawson, Bill Spadafore, Devendra and Satyendra Kumar and Dave Llewellen.
Beyond the work during the years of research that is described here, I have always enjoyed a
wonderfull time and great hospitality with the family Cheok, who have soon become my host
family in the United States. Also I’d like to thank my friends with whom I spent many weekends
enjoying life and exploring the country. Last but not least, I would like to thank my parents and
family for their inexhaustible support throughout my study.
ii
Preface
In many countries one is not anymore considered to be privileged to own a vehicle. The automobile
as a means of transportation has become a commodity, a requirement of mobility that one cannot
do without. When we go shopping for a new vehicle, most of us will take technology for granted
and we bargain on horse-power, sunroof, power windows and color.
The understanding of the dynamics of driving and the capability to design safe and stable vehicles
is the primary requirement for building quality cars. With increased development speed, the high
level of quality and complexity and a growing competitive global market, a design process without
virtual prototyping and simulation is becoming inadmissible.
This dissertation presents a new simulation configuration for analyzing and designing vehicle
dynamics systems. The configuration consists of a simulation network structure, a real-time
modular vehicle dynamics model and a novel fuzzy-logic based tire model. The system that
has been developed is an enabling tool to do just the virtual prototyping of mobility systems.
Simulation studies are now possible where a human can drive a virtual vehicle in any maneuver,
while analyzing the vehicle behavior.
The manuscript is organized as follows. Chapter 2 presents the vehicle model in a modular
configuration. The next chapter details the tire model tire that is incorporated in the vehicle model.
Chapter 5 highlights on the ability to execute partitions of the simulation through the simulation
network environment. This environment is especially configured for the purpose of simulating
vehicle dynamics interactively by means of popular simulation tools like Simulink. Chapters 6.4
and 7 report on the study for timing and stability. Finally, Chapter 8 shows that the behavior of the
system relates to actual driving an scenario, and presents the validation efforts of the model.
Rochester Hills, Michigan
G.E. Smid
iii
Nomenclature and Convention
The variable naming convention in this thisis follows the standards used in most simulation and
engineering literature. The coordinate systems convention can be seen from Figure 1, and is
semantically described as “ forward, lateral left, and up, and up”. Typically the SAE
standard and is characterized as “ forward and lateral right, and up”. The system in this
dissertation complies with SGI graphics representation, but can be easily transformed to any other
system. The coordinate system rotations and calculations are included in Appendix C.
For vectors, variables and paramteres that apply to one of the corners of the vehicle, a lower right
index is included in the subscript of the name, that denotes the corner which it applies to. The
vehicle corner numbering can be read from Figure 1. Naming suffixes and indexes for vectors ( )
and matrices ( ) is according to notation
frame Operation
var,i
from frame
Operation
to frame
Frame can mean either of the three frames , or . The frame refers to the earth (or origin)
frame, refers to the vehicle (or car) reference frame, and refers to the wheel frame. Forces are
typically named , and torques with the subscript denoting the name or the origin of
the force or torque. The overbar denotes explicitly that a variable is a vector (generalized vectors
have an underbar). The following variable names are used in this thesis.
! ! "
! ! ! % "
& '
& "
&(
"
)+*
"
)-,
"
$#
$#
$#
$#
Transition matrix of a discretized system. Dependant on integration method
Suspension anchor location with respect to the vehicle frame of wheel Length in -direction between c.g. and front axel
Friction reduction factor
Input matrix of a discretized system. Dependant on integration method
Damping effect of the camber angle
Location of the center of the wheel in the vehicle frame of wheel Length in -direction between c.g. and rear axel
Damping effect in the dynamics steering model
Location of the tire-ground contact point in the vehicle frame of wheel Modified longitudinal tire stiffness
Modified cornering tire stiffness
Damping coefficient of the brake
Damping coefficient for the steering system
iv
X-axis
TF
2
1
.
Al
C.G.
Ai
Y-axis
Top-View
Bl
LT
LS-δS
4
3
LT-δT
Bi
Ci
TR
Figure 1: Naming convention for the vehicle geometry.
/-02143$5
/-62143$5
/-7 8 9 : ;+143$5
/=<>143$5
[email protected]
ACB4D
FGE @ H I J K 9L1
FE NPO K QR1
FE NPO K SR1
FE O T J JU1
FGE 7 J 9 V K 9+1
FGE 6 81
FE XP9 Y @Z1
FE [\1
FE ]\1
^
3$5 _a`
b
5
b 7c5
; faO g @
de
; fa7 O g @
dX
; fa7 O g @
hi
; fa7 O g @
hP0
7
Torsial damping coefficient for the transmission shaft
Damping coefficient for the suspension model
Slip damping coefficient in tire stick model
Damping coefficient for the tire deflection
Auxilary product matrix of a discretized system for non-linear terms
Graphics update frequency, or frame rate
Force vector for the suspension and wheel deflection of corner M
Longitudinal shear friction force
Lateral shear friction force
Anti-roll force in the suspension
8W
Slip force vector for the M wheel
Stick friction force
Aerodynamic force on the chassis
Longitudinal shear force
Lateral shear force
Gravitational acceleration
Integration step size per frame
Integration step size per sub-sample
Inertia matrix for the vehicle chassis
Inertia for the wheel
Inertia of the engine
Inertia of the transmission
v
k man o p
jk l
q v
r-s2t4u$
rxwyt4u$v
r-z2t4u
rx{yt4u
r q | t4u
r q | } s k=t4u
r+~t4u
r-€2t4u
r-2t4u
‚
u
ƒ„{…u
ƒG~u
–Z—™˜ š
– q qœ›G
q
ž
–ZŸ™˜ š
t= t+w Š }
t+{
u
¢£
¢ ‘s
‘”“¤u
‘¥
‘Ÿ¦u
v
v—
vŸ
§
v
¨©
v
¨q
ª«
›Gq 
ª¬
›G
ª¥cv q
ªw
›G
ª q ­ } l ›Gq 
q
ª{
›Gq 
ª®u
ª‘u
¯ —°u
¯ Ÿ°u
u
±
m² ³u
Kingpin inertia
Stiffness coefficient for the steering system
Torsial stiffness for the transmission shaft
Anti-roll stiffness coefficient
Stiffness coefficient for the suspension model
Stiffness coefficient in the dynamics steering model
Tire elasticity in the stick slip model
Stiffness coefficient of the tire
Longitudinal tire slip stiffness
Lateral (cornering) tire slip stiffness
Patch length of tire-ground contact
ƒ„{+†ˆ‡ s ‰ } Š ‹Œ s Ž } Š ‹ ‡
Nominal length of the suspension system (
ƒG~†’‘”“L†ˆ‡ s Ž } Š ‹Œ s • } Š ‹ ‡ )
Nominal length of the tire radius (
)
Mass of the vehicle (diagonal matrix)
Moment about the kingpin
sub-sampling factor
Mass of the wheel
Brake pressure booster constant
Gearbox ratio for gear ¡
Steering gear ratio
Vehicle position in earth reference frame
Transformation matrix for translating global to vehicle frame coordinates
Effective wheel radius (with deflected tire)
Euler angle transformation matrix
Nominal wheel radius (for unloaded tire condition)
Slip ratio
Space trajectory of the vehicle corner by displacement and rotation
Space trajectory of the wheel by spin travel in the steered direction
Coriolis matrix
Overhear time per frame
Execution time for one iteration of vehicle dynamics
Brake torque
Enging shaft torque
Frame rate interval time
Torque from the transmission onto the axes
Torque on the vehicle chassis caused by slip
Torque on the vehicle chassis caused by the suspension
Track width of the front wheels
Track width of the rear wheels
v—
Location of the vehicle corner on the trajectory
vŸ
Location of the tire on the trajectory
Patch width of tire-ground contact
Terrain altitude
vi
´ µ³¶
·¸\¹ º »
·¼ ½¾¹ º »
·¿ ÀÁ¹ º »
ÂÃ
¶
ÂÄ
¶
Å+Æ
ÇÈ É
Ê-Ë
Ì
Í È ÎÉ
Ï
Ï Ã¿
Ð
¹ º»
Ñ µ³¹ º»
Ñ Ò ÓLÔ ¹ º»
ÑÕ
¹ º»
ÑÒ
¹ º»
ÖC¹ ºÔ »
×ÙØ Ú Õ
Ûܹ º»
Ý Þ߶$à áaâ
Ý µß¶$à áaâ
ãÞä¶
ãµä¶
í ÈÉ
Actual suspension length
Brake pedal angle
Kinpin angle
Throttle angle
Suspension deflection
Tire deflection
Understeer gradient
Non-linear state driving functions
Notation for the model of a simulation process.
Model of the human driver and the terrain
Index library index value of the function parameter
Slip coefficient for tire-ground contact
Membership value for the fuzzy tire model switch
Vehicle Euler angles
Steered wheel angle (i.e. actual wheel rotation)
Steering wheel angle (i.e. steering setpoint)
Angle at the steering gear pinion
Camber angle
Spoke angle
Vehicle gyriscopic angular rates
Wheel spin angle
Spacial velocity of the vehicle corner by displacement and rotation
Spacial velocity of the wheel by spin in the steered direction
Ò æç
Ò ëç
Elevation of the anchor location above the terrain ãÞå
Òè éì ê ç
Elevation of the center of the wheel above the terrain ãµ$å
è éê
Non-linear output driving functions
vii
è éÒ ëç
èé
Contents
Acknowledgements
ii
Preface
iii
Nomenclature and Convention
iv
1 Introduction to Vehicle Simulation
1.1 Objective
1.2 Real time simulation
1.3 Approach
1
1
3
3
2 Virtual Vehicle Modeling and Simulation
2.1 Introduction
2.2 Modular Closed Loop Dynamics
2.3 Conclusion
6
6
7
11
3 Fuzzy model of tire traction dynamics
3.1 Introduction
3.2 Stick Friction with Fuzzy Logic Switching
3.3 Implementation
3.4 Simulation results
3.5 Conclusion
12
12
13
17
18
20
4 Numerical Integration of the Vehicle Model
4.1 Transformation and Integration Methods
4.2 Conclusion
21
21
30
5 Simulation Platform with Integrated Networking Environment
5.1 Introduction
5.2 Methods for multi-processing
5.3 Multi-processing of dynamics models
5.4 Implementation through Indexing
5.5 Virtual Environments
5.6 Modules for Subsystems
31
31
32
34
40
45
46
viii
5.7
Conclusion
48
6 Timing and Synchronization
6.1 Introduction
6.2 Human-in-the-loop Model
6.3 Real time versus Simulation time
6.4 Communication and Synchronization with SPINE
6.5 Prediction and Correction with Luenberger Observer
6.6 Conclusion
49
49
49
50
55
55
62
7 Stability
7.1 Introduction
7.2 Model Stability
7.3 Simulation Specific Stability
7.4 Application Dependant Stability
7.5 Conclusion
63
63
63
67
76
78
8 Verification
8.1 Introduction
8.2 Vehicle Kinematics and Dynamics
8.2.1 Static load at the tires and suspension
8.2.2 Steady state cornering
8.2.3 Constant torque acceleration and braking
8.2.4 Ackermann Steering Verification
8.2.5 Stopping distance
8.2.6 Circular Skid Pad
8.2.7 Yaw acceleration while braking under split- î condition
8.2.8 Braking in a curve
8.2.9 Double Lane Change
8.3 Telemetry for Real-Time Verification and Validation
8.4 Tire model verification
8.5 Conclusion
80
80
81
81
82
84
85
86
88
90
92
92
94
96
96
9 Conclusion and Recommendation
9.1 Conclusions
9.2 Recommendations
9.3 Retrospect and Prospect
97
97
98
99
A Details on Modeling
A.1 The driver environment
A.2 Steering Model
A.3 Engine and Transmission Model
A.4 Brake Model
A.5 Wheel Spin Dynamics
101
101
102
106
107
107
ix
A.6 Suspension and Tire Deflection
A.7 Anti roll
A.8 The vehicle frame
108
112
112
B Details on the Tire Slip Model
B.1 Theoretical Derivation
B.2 Applicable formulas
B.3 Considerations
114
115
119
121
C Coordinate Systems
C.1 Displacement Coordinate Transformations
C.2 Angular Velocity Coordinate Transformation
C.3 Angular Displacement
C.4 Linear Velocity Coordinate Transformation
C.5 Coordinate Systems
123
123
126
127
127
128
D Software Reference
D.1 File Structure
D.2 User Interface
D.3 Prototyping with Simulink
130
130
131
135
E Development and Implementation
E.1 Geometry models
E.2 Initialization procedures
E.3 Main algorithmic cycle
E.4 Vehicle Dynamics Implementation
E.5 SPINE - server (VVSS)
E.6 SPINE - client
E.7 Parameter Defaul Values
E.8 State Reference Index Library
E.9 Peripherals and User Interfaces
138
138
139
141
142
145
147
147
149
149
Curriculum Vitae
154
Keyword Index
155
References
158
x
List of Figures
1
Naming convention for the vehicle geometry
iv
1.1
The Vision for the Virtual Vehicle System Simulation (VVSS) setup.
4
2.1
Overall virtual vehicle simulation system model with three partitions and human
in the loop.
Closed loop system interconnected model for the VVSS.
2.2
3.1
3.2
3.3
3.4
3.5
3.6
4.1
4.2
4.3
4.4
5.1
5.2
5.3
5.4
5.5
5.6
6.1
The general characteristic curve for the friction force as a function of sliding velocity.
Schematic diagram of the modified fuzzy tire model.
The stick tire model is modeled as a double spring-damper system between the
trajectory of the vehicle and the trajectory of the wheel.
Graphical display of the fuzzy logic sigmoid membership function.
Polar slip friction coefficient representation.
Simulation results with the fuzzy tire model for acceleration and braking.
Graphical intepretation of different integration algorithms for the differential equation ðx
ï ñ’ò .
Three different transformation methods for approximating continuous to the discrete time domain, with the corresponding stability regions.
A general example of a second order mechanical model with force input and
position output.
interconnected discretized closed loop system.
The proposed implementation for the Virtual Vehicle System Simulation (VVSS)
in the Simulation Platform with Integrated Network Environment (SPINE).
Three variations of configurations for Multi-CPU simulation models.
Timing diagram for double dependant replaced state variable.
Indexed states represent state values through indirect addressing.
The simplified model of the underlying tree structure that represents the graphic
virtual scenery
The virtual environment can be adapted to meet the requirements of any intended
study.
The Optimal Control Model (OCM) for the human operator.
xi
8
10
13
14
15
16
17
19
22
24
25
27
32
33
39
41
45
46
50
6.2
6.3
6.4
6.5
6.6
Snapshot of the VVSS simulation output with online statistics.
Minimum integration interval selection for real-time simulation.
SPINE communications timing diagram.
Timing diagram in the scenario of synchronization failure.
Example of a second order linear system for predicting state values.
The root locations for a quarter car suspension model for various values of the
stiffness and damping parameters.
7.2 Pole location transformation for various integration schemes.
7.3 Example of a second order linear feedback system with three general partitions.
7.4 Example of a second order linear system with three general partitions.
7.5 A general second order feedback system with forward and backward integration
methods.
7.6 Stability regions for a second order polynomial and for the second order example
feedback system.
7.7 Four stability regions for approximation variations on general second order system.
7.8 A simple open loop integrating system is used to test the accuracy of simulation
results with SPINE.
7.9 Comparison of simulation output in the VVSS and in a Simulink model through
SPINE.
7.10 Comparison of the values for position, simulated in the VVSS in the case when a
submodel is being simulated in Simulink through SPINE.
52
53
54
56
59
7.1
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
Telemetry aquisition and communication system will be used for real-time on-line
validation.
Validation data for steady state load distribution.
Suspension deflections, vehicle velocity and roll angle for steady state cornering
validation test.
The trajectory during steady state cornering.
Lateral forces on front tires for steady state cornering.
Torque profile and velocity and position output for constant torque accelerating
and braking.
Ackermann steering verification test.
Typical trajectory profile for stopping distance.
Typical trajectory profile for stopping distance.
Throttle command and roll angle for circular driving test.
Vehicle velocity and heading in a circular driving test.
Planary trajectory graph for circular driving test.
Trajectory and yaw profile for split- ó brake test.
Tire forces under split- ó braking conditions.
Trajectory and yaw profile for braking in a curve.
Suspension deflections and heading profile when braking in a curve.
Trajectory and asociated steering command for double lane change.
xii
65
68
68
69
70
71
73
75
75
77
81
82
83
83
84
85
86
87
87
89
89
90
91
91
92
93
93
8.18 Lateral forces and lateral acceleration on the vehicle during lane change.
8.19 Dual-ô dynamic sliding and static stick friction verification test table.
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
94
95
The Motion platform with driving environment mounted on top.
The graphical illustration of the definitions for caster and camber angle.
The second order steering system model.
Ackermann cornering geometry.
Dynamic model of the powertrain.
Schematic diagram of the hydraulic brake system.
Model diagram for wheel angular dynamics.
Schematic representation of the mechanical construction of the quarter car suspension model.
Model for quarter car suspension translational dynamics.
Front view of the mechanical configuration of the suspension system with lateral
forces decomposition.
Model for the vehicle frame translational dynamics.
Model for the vehicle angular dynamics.
102
103
104
105
106
107
107
B.1 Tire-road contact patch geometry.
B.2 Strain condition in non-sliding portion of the contact patch.
B.3 Longitudinal and lateral normalized slip forces for different slip angles across slip
ratio.
B.4 Longitudinal and lateral slip against slip angle.
B.5 Polar representation of the longitudinal and lateral slip.
114
115
C.1 Coordinate frames from reference to body.
124
D.1 Image of the graphical user interface for the Virtual Vehicle System Simulator.
D.2 The VVSS library in Simulink with the blockset that provides the necessary functionality for SPINE.
134
E.1 Software flow model for Multi-CPU Simulation.
E.2 Hardware setup of the Simulation Platform with Integrated Network.
143
145
A.9
A.10
A.11
A.12
xiii
109
110
111
112
113
120
121
122
136
List of Tables
7.1
Nomenclature and Convention.
iv
Transfer functions for four variations of integration methods for the linear system.
72
C.1 Advantages and disadvantages of the three most used transformation methods.
128
D.1 The list of file names with a short description, of the files that are associated with
the VVSS and SPINE.
D.2 Available command-line options with the functionality.
D.3 Available Key-press options with the functionality.
131
133
133
E.1
E.2
E.3
E.4
139
148
149
150
Overview of the file formats that can be loaded into the geometry tree of VVSS.
Default Parameter Values.
Reference table for the VVSS indexes.
Reference table for the VVSS indexes for the quarter vehicle corners.
xiv
Chapter 1
Introduction to Vehicle Simulation
The revolution in the computer hardware industry has created the technology for conducting
analysis and simulation of numerous engineering applications. We have arrived in a time where
sufficient computer power is in most situations available, and where it has become the responsibility
of the engineer to exploit the computers to solve the solutions to his problem. One of the successes
of increased computer power is found in the area of solid modeling or Computer Aided Design
(CAD), where high performance rendering of complex graphics models allows for interactive
designing models. Also in the entertainment industry the use of high-end graphics computers for
arcades and movie productions has shown to be successful.
1.1 Objective
In this dissertation I will demonstrate a third use of the available graphic capabilities. It is in
the area of the automotive industry. Whereas the aerospace industry has successfully adopted
simulation technology for engineering and training, the automotive society is traditionally more
used to conventional tools and engineering methods. It is only in recent years that the virtual
simulation of full vehicle systems has become a serious effort for the automotive industry. Most of
the large companies (the Big Three and their European and Japanese competitors) have developed
their own facilities to simulate vehicles in virtual realistic environments. Each of them in a slightly
different setting, each of them with different research objectives.
Commercial packages like ADAMS, DADS or VDANL [1] are available, as well as commercialized academic packages like CarSim and Madymo. However, generally they contain black-box
simulators and are expensive. This means that a file of configuration parameters defines the simulation environment, but there is no easy access to the models. Also, these simulators will typically
utilize a pre-defined scenario for the driver. This can be either a driving scenario (steering, throttle
and barke trajectories) or a driving behavior characterization (delay, bandwidth, gain). The simulators will usually generate graphical output in the form of curves and plots on axes. Additional
1
2
software needs to be aquired to vizualize the data in a 3D scenery. Hence, most of the commercial
solutions will not be (or are expensive to be) customized and do not give the user the ability to
run arbitrary interactive test scenarios, and do therefore not give the subjective feel of a systems
performance. They are usually not designed for solving the vehicle dynamics model in real time
or interactively.
In January 1996 a collaboration was initiated between ITT-Automotive and Oakland University in
which Oakland implemented a full-vehicle simulation for the purpose of real-time simulation with
hardware-in-the-loop. The details about the modeling are described in the final project report [9].
The task was to develop and implement a full vehicle dynamics model with 16 degrees of freedom
motion dynamics. The model was developed in MATLAB and later implemented in EASY-5 õ
using FORTRAN code. The objective for ITT was to test and demonstrate their ABS system
performance on the behavior of vehicles by allowing its engineers and customers to drive a vehicle
in a virtual realistic environment, in which the vehicle dynamics were incorporated. The model
was developed toward the application for ITT, and did not satisfy the requirements for conducting
a wide variety of driving manouvers.
The project was succesfully demonstrated at the 1997 SAE Congress in Detroit. Customers could
drive a virtual vehicle on a test track (split- ö and slalom) and were able to turn the ABS system on
and off. The Department of Electrical and Systems Engineering has since continued its efforts in
the vehicle simulations (See [57], [35], [55], [56]).
In the simulation of vehicle dynamics, a closed-loop system will be defined that includes the driver,
a virtual environment and the mathematical synthesis of an automobile. The following statement
phrases the objective of the research in this thesis,
It is the principle objective of this research is to develop a system that can emulate
the behavior of a vehicle, using a multi-processing environment, and that can present
the solution in a user-interactive immersive virtual realistic environment, which can
be used as a tool in the design process.
The objective statement suggests a network for real-time multi-CPU simulation and the development of a driver interface with a graphics front-end that can provide the simulation output to the
driver.
Immersion of the human driver opens a wide area of research in the project. A human driver will
feel to be immersed in the simulation when the environment looks, feels and performs realistically.
In order to achieve this level of perception, the simulation required full 3D audio-visual feedback,
force and motion feedback and an absolute alignment with absolute time. This term interactive in
the objective implies the real-time evaluation of a full vehicle dynamics model. The research in
this dissertation emphasizes on visual feedback and real-time simulation.
÷
EASY-5 is a unix-based simulation environment developed by the Boeing Company. Mainly used by large
companies for complex simulations of hydraulic systems.
3
1.2 Real time simulation
Real-time is typically referred to as the utmost strict requirement to provide a numerical output at
a specified fixed time instance. Special-purpose computers with a real-time operating system are
often used for the control of hardware-in-the-loop systems. For the purpose of interactive vehicle
simulation, the human driver could be considered hardware-in-the-loop. The term real-time will
have the similar definition. However, under-performance will not necessarily be disastrous. The
term real-time in the context of simulating vehicle dynamics will be used in the following definition:
The simulation of the vehicle dynamics is performed in real-time when the dynamics
are numerically integrated, in parallel with the graphics rendering process, over a
time interval that equals the graphics update frame interval, and the application is
generating the virtual environment in the selected frame-rate.
The objective for the multi-processing environment is to allow engineers to communicate with
the real-time vehicle dynamics simulation. The simulation platform with integrated network
environment (hereafter referred to as SPINE) combines the convenient accessible simulation
interfaces like Simulink with the virtual realistic driving simulation.
The bottom-line goal of the research is to provide a computational vehicle dynamics which is
based on underlying physical relations. Vehicle dynamics is the branch of engineering which
relates forces to overall vehicle accelerations, velocities and motions, using Newtonian laws of
motion. It encompasses the behavior of the vehicle as affected by powertrain, tires, aerodynamics,
gravitation and chassis characteristics.
1.3 Approach
Towards accomplishing the objective on page 2, several problems have been solved. These
problems and their solutions will be chronologically addressed in the successive chapters. These
solutions are the contributions of this thesis.
ø A well-defined set of vehicle dynamic relations has been compiled that synthesize a vehicle
model for general driving purpose simulations and well fit for real-time digital simulation.
ø A tire model has been designed, that relates physical parameters to dynamic behavior, and
that will evaluate meaningfull results for all speeds in all directions.
ø A multi-computer network structure has been developed and implemented which allows
multiple computers to simulate vehicle subsystems concurrently in real-time.
ø The vehicle dynamics model has been implemented in a graphics workstation, and a virtual
realistic animation has been adopted to render the simulation output. Particular attention
has been paid to the real-time requirement of simulation.
4
These solutions are the contributions of this thesis. The above items have been integrated in the
virtual vehicle system simulator (hereafter referred to as SPINE). Two additional chapters address
the studies for stability and validation.
As is well understood, modeling and simulation can have no merit without validation and verification. The notion for ensuring the validity of a model for a system is an essential step in the systems
engineering process [44]. The question that need to be answered is
Are we doing the right thing, and are we doing it right?
Figure 1.1: The Vision for the Virtual Vehicle System Simulation setup. A motion table with the
driver seat and peripherals, surrounded by stereo vision and sound. The Vision for the Virtual
Vehicle System Simulation setup. A motion table with the driver seat and peripherals, surrounded
by stereo vision and sound.
In order to validate the vehicle models, three methods can be used. First, validation with simulation
data from an established software has been conducted for ITT-Automotive (See [9]). Second, offline validation would require a series of well-defined and well-excited scenarion test-data that can
afterward be correlated with simulation results. In this thesis however, it is suggested that a real
vehicle will be equipped with a tele-metry equipment. For now the system is exposed to a validity
check in nine test scenario verification experiments.
The intensions for the virtual vehicle simulation laboratory cover a large amount of effort. The
conclusions in Chapter 9 cover the state of research and where it should go from here. The
important aspect for an organized project management is to remain in focus with the objective, to
understand the applicability and to emphasize on the benefits.
5
The research in virtual realistic driving is not finished upon the defense of this dissertation. The
VVSS and SPINE will continue to be supported in the time to come. The vision for the virtual
vehicle systems simulation is an interactive feedback motion platform as is illustrated in Figure
1.1. Features and functionality as well as performance criteria will have to be modified for the
particular applications.
Chapter 2
Virtual Vehicle Modeling and Simulation
In this chapter the simulation model for the vehicle dynamics of the VVSS will be explained. The
model is shown to consist of three partitions. The descriptor matrix for each partition is presented,
as the representation of the nonlinear model. The chapter presents a compact but complete vehicle
dynamics model for real-time simulation.
The aspects of choosing the suitable integration method are addressed in Chapter 4. It is described
there, how the models in this chapter are interconnected and numerically solved. The implementation is furthermore detailed in Appendix E. In particular, Section E.4 describes the resulting
mathematical formulation for implementating the derivated models that have been presented here.
Stability issues will be further addressed in Chapter 7.
2.1 Introduction
The vehicle system is considered to be constructed from a rigid frame and four wheels, hence a
five-body system. The frame has 6 degrees of motion freedom. The wheels will be able to spin,
and move up and down along the suspension displacement. The two front wheels will be able to
steer. A total of 16 degrees of freedom. The vehicle model was derived at Oakland and has been
presented at CAINE [57]. The mathematical derivations that lead to the presented model can be
found in Appendix A.
The model, as presented here, should be viewed upon merely as an archetype. By itself, it is empty
and purely formal, nothing but a facultas praeformandi, a possibility of representation which is
given a priori. The character and behavior of any vehicle will come about during configuration
and parameter value assignment. In such a way, it serves the objective for virtual vehicle driving,
which is to retro-fit any wheeled ground vehicle in the simulator.
The model can be partitioned in three submodels. Partitioning is beneficial for simulation, especially with the use of real-time integration methods [50].
6
7
2.2 Modular Closed Loop Dynamics
An important aspect in the modeling methodology is the modularity. Chapter 5 will explain about
modularity in more detail. The derivations in this chapter for the dynamics will be targeted towards
the capabilities for modular simulation.
The most suitable modeling methodology, with respect to modularity and to digital simulation, is
the discrete-time state-space representation, with extension to non-linear dynamics. The following
paragraphs will discuss the sub-models that are part of the vehicle system model. In the Newtonian
modeling method, the forces on a body are assumed as inputs, and the dynamic motion of the
body is assumed as the states or the output. When the state-space matrices are derived, they can
be substituted in the full system model. This strategy is also used for the modeling of the Jumbo
Container Crane [32].
The alternative popular mechanical modeling approach would be Lagrange’s method. For a state
ù and an input ú , the Lagrangian ûü ùý úaþLÿ +ü ùý úaþ -ü ù þ is defined as the difference between
the kinetic and potential energies. The dynamic behavior resulting from Lagrangian dynamics has
the form
ü ý þ ü ý þ$ü þ
(2.1)
where is a set of generalized coordinates, and the sum of the forces and torques. The form can
then be transformed into a state space model ù Lü ùý ú ý þ , where Lü þ represents the physics of the
problem [40]. The advantage of Lagrange’s method is the consistency of modeling. If the designer
is complete and accurate in formulating the problem, then Lagrange’s method provides almost like
a “cookbook” solution. However, in solutions of control problems, using the Lagrangian method,
the physical meaning and the interpretation of the resulting model is hidden, and it will be hard
to analyze, modify or add physical components of the sytem. Also, a condition for the Euler
Lagrangian dynamic analysis is that ûü ùý úaþ must be analytical in the region of interest.
The VVSS is a closed loop system that incorporates the human driver in the loop. The user inputs
will change the torque and angle on the wheels. The wheels on their turn will apply inputs to the
vehicle frame model. The vehicle system will then be rendered in the drivers’ environment where
the driver will react and generate new inputs to the simulation. This human-in-the-loop model is
graphically illustrated in Figure 2.1.
When the drivers’ actions and the terrain data are taken as inputs, and the vehicle configuration as a
set of parameters, then a representation of the simulation system can be expressed in the following
non-linear state-space form
!
x¯ u¯ ü x¯ ý u¯þ
x¯ u¯ ü x¯ ý u¯þ
"
x
¯
y
¯
For complex physical systems, the direct feedthrough matrix
is generally zero.
(2.2a)
(2.2b)
#
µslip
.
zg zg
$
Model
Transmission
Engine &
Brake
Model
Steering
Model
%
αth
αb
θcmd
TG
Tb
&
Model
Tire Slip
Wheel Spin &
Tire
Deflection &
Suspension
Model
Suspension and
Wheel Dynamics
SII
Fslip
ωw
Fdefl
Model
Dynamic
Frame
Vehicle
Gravity G
Wind Fwind
Vehicle
Properties
SIII
Θ
p
'
Terrain
Model
Driver Environment
SI
8
Figure 2.1: Overall virtual vehicle simulation system model with three partitions and human in
the loop.
9
)+( * ,
.( * ,
/
with x u and x u being non-linear functions of the states x and the inputs u. Note that these
¯ ¯
¯ ¯
¯
¯
non-linear functions are independant of time . Time varying parameters in these functions are
considered constant or near-constant. This condition implies some limitations in the generality of
the formulation in that Equations 2.2 model the system around a certain equilibrium condition.
)( * 0 ,
1 2 3
.( * ,
4
The system is thus characterized by the four matrices , , and and the non-linear driving
functions x u and x u . A compact descriptor model for the system can be formulated as
¯ ¯
¯ ¯
follows
57x6
where, for a system with
as
D
states and
E
¯
y
¯
<=>
8:9;
[email protected] B
x
¯
u
¯
(2.3)
F
inputs and outputs, the descriptor matrix
<== I1 H J HLK K KM1IH J N
== .. . . ..
== . . .
== 1QN J HRK K KS1QN J N
=> 3IH J HLK K KM3IH J N
; 9 ... . . . ...
G
3QT J HUK K KV3QT J N
I2 .H J HOK K KM2IH .J P
..
..
..
.
2QN J HLK K KS2QN J P
4:.H J HLK K KS4:H. J P
..
..
..
.
4WT J HRK K K4WT J P
) H * x u¯. , ¯
.
). N * x. u- H * x¯¯. , , u¯¯
. T * x.. u¯, ¯
@ BB
BB
BB
C:BBB X
;
will be given
(2.4)
Using this representation in Equation 2.3, the vehicle dynamics model that is given in Figure 2.1
will be formulated. From Figure 2.1, it can be seen that the model can be partitioned in a series
and
, for the steering, brake and powertrain, for the suspension
of three submodels ,
and wheel dynamics and for the chassis respectively.
;IY ;IY Y
JZ
;IY Y Y
In this section we will summarize the vehcile model in the representation of Equation 2.3. Appendix
A contains the detailed derivations for each of the elements of the submodels. The appendix and
the nomenclature are referred to for the explanation of the variables and parameters.
The steering model, brake model and engine and transmission models are described by the analytical descriptor matrix
=>
<==
[ [O[O[
\
]^ ^
[\[O[O[ `Wa]b * * _+_ c d - gh - @C B
(2.5)
B
W
`
j
i
O
[
O
[
[
[
B
,fe
;IYQ9
where x is empty. Hence, there are no dynamic states. The matrices 1 , 2 and 3 in Equations
2.2
^
¯
_
+
_
are empty. The inputs are the steering command k l Pm , the brake and throttle angles
and c d ,
10
Interaction with
human driver and
terrain
n
op
op p
op p p
Figure 2.2: Closed loop system interconnected model for the VVSS.
t+v
ws
and the average wheel spin velocity
and the steered wheel angle ,
rq s , and the outputs are the brake torque tu , the traction torque
yzz w | }~ ‚ ƒƒ
z{y t u ‚ ƒ
z{  u ƒ
u
+€  :„ … y¯ t+s v „
¯
Qp x rq s p x w
where the brake torque tu is given in Equation A.12, and †W‡ is the steering gear ratio.
(2.6)
The wheel spin, deflection and suspension deflection model is characterized as a double spring
damper system plus an inertial spinning body. The inputs are the tire and suspension deflection
and the torques acting on the wheel. The descripting matrix the becomes
‹ŽI‹‘‹ “ ’ •s ” – ˜ — –™ — ‡ ‚ ƒƒ
… ‹ Š … š … š›œ ƒƒƒ
‹Ÿ‹ ‹‘‹
Š
‹Ÿ‹ª© ©
‹
ƒƒ
ƒƒ
‹Ÿ‹ p ‹‘
‹
‹
(2.7)
¦
p
¦
ƒ
™—
‹Ÿ‹ ‹‘‹
–
¬ — ~ ­ ®Š ¯
‹Ÿ‹ ‹‘‹
–
„
‹Ÿ‹ ‹‘‹
–¬— ° ¯ ‰ Š
Š± ‰Š
with
yzz “ s ‚ ƒƒ
yzz –f˜ — ‚ ƒƒ
yz{ – ™ — ‚ ƒ
z{M“ ² s ƒ
z{ ´ — ƒ
Š y
–¬ ¬— ~ ° ­ ®Š ¯ „
x
u
(2.8)
r
A
„
…
:
„
…
+
t
v
¯
¯
–
—
¯
³
¯
‰
Š
p pQx s p pQx tu p p x
Š± ‰Š ’
¬
™
¬
°
–
—
–
—
–
—
where ~ ­ ® ¯ is given in Equation A.21,
in A.20 and
¯ in 3.4. “ s can be found in
Equations A.19.
‰ Š This model applies to each corner
Š of the vehicle.
Š ± ‰ Š The wheel axle centerpoint
¨
yzz Œ
‹ ‹Œ‹j‹O‹O‹
zz ‹Œ‹ž‹O‹O‹
zz ‹¢¡ ¡ ‹j‹O‹O‹
¡
zz ‹Œ¡¡ £¥‹Œ
ˆ
zz{ p ¦¤ ¨§ ¡ ‹j‹«L‹
‹Œ‹Œ‹j‹O‹O‹
p p ‰ Š x ‹Œ
‹Œ‹j‹O‹O‹
‹Œ‹Œ‹j‹O‹O‹
11
•µ ·Q¶ ¸
is solely modeled as an additional output for the purpose of rendering graphics in the
location
animation stage.
Finally, the vehicle chassis dynamic model is characterized by the translational and rotational
motion dynamics. The inputs are the forces and torques that act on the body and the outputs are the
position and the roll, pitch and yaw. Further details can be found in AppendixVDdetails Section
A.8, Equations A.23, A.26 and A.27. The descriptor matrix is given by,
ÀOÀÁÀÁÀ ÂÅÇ
Ã¥Ä Æ À À Ï ÐÐ
È Á
À ÀÁÀ ÀŒÀÉ
À À ÐÐÐ
È
È
È
Œ
À
À
¥
Ã
Ä
O
À
À
¥
Ã
Ä
À
¹Iº º ºQ»½¼¾¾ ÀOÀ ÅUÊ Ë Å À ÀŒÀÉÅ À µ Ì Ê ÀÀ ÐÐ
(2.9)
¾¾ À
Î
Ì
Í
Á
À
À
Œ
À
É
À
À
À
¾¾ ÀOÀÁ
¾¿ Æ À Æ ÀŒÀÉÀ À Ñ
where the coriolis and cenrifugal force matrix Ê Ë is explained in A.24 and the Euler angle transformation matrix ÌÎÍ inA.25. The inputs and outputs are given by
× µ Ù¶ Ú Û Í Ü Ý ¸¥Þ µ Ù¶ ß Ü ¸ à Ý ¸¥Þ µ Ù+¶ á Ü Ü Ý ¸ âÞ µ Ù+¶ 㸠ä Ú Ï ÐÐÐ
µÓÓ ¶Ò Ï ÐÐÐ
¸GØ
µ
Ð º º º »èç µ Ó ¶
å¶
ºx º º » ¼¾ µ Ô ¶ uº º º » ¼¾
Õê
é
y
× µ æ+¶ Ú Û Í Ü Ý ¸Þ µ æ+¶ ß Ü ¸ à Ý ¸fÞ µ æ¶ á Ü Ü Ý ¸
Ö
µ
¶
¯
Ñ
¯
¾¾¿ µÊ Õ ¶¶ ÑAÖ ¯ ¾¾¾¿
¸
µ
(2.10)
With the formulation in this section, the model for the vehicle simulation system can be depicted
in a chain of submodels as in Figure 2.2.
2.3 Conclusion
With the models in this chapter and the necessary details in Appendix A, a stand-alone basic
scheme for a vehicle dynamics model has been formulated. Three partitions have been presented
in Expressions 2.5, 2.7 and 2.9.
Some of the submodels are simplified, but will suit general prupose vehicle driving simulation
studies. Note that a novel tire friction model is developed in Chapter 3.
Chapter 3
Fuzzy model of tire traction dynamics
A fuzzy logic tire friction model is introduced to improve the representation of the characteristic
of the friction behavior. The model is based on the model by Howard Dugoff with the addition
to make the solution stable for low speeds. The new model constitutes from previous efforts by
Dugoff, but incorporates an additional spring-damper system and a fuzzy logic “switch”. Without
the modification, the existing Dugoff tire model is numerically unstable in the region where slip
velocity is small, because of the possibility of division by zero.
This chapter explains the details of the fuzzy logic tire model, demonstrates the implementation
and shows simulation results.
3.1 Introduction
One of the major barriers for the development of a ground vehicle simulator is the modeling
of the constraints regarding the tire ground contact. The lack of these constraints is the major
cause for flight simulators to be successfully used for many years. The tire dynamics in different
driving scenarios have been investigated intensively. Some of the more outstanding efforts by Fiala
[19], Howard Dugoff [16] and more recently for example by [3], [43] and the Delft University of
Technology [49] and [51]. Empirical studies have been conducted as well [23]. Tire manufacturers
have done extensive studies on tire behavior, however the results are of strategic value and thus
proprietery.
The general friction force curve is drawn in Figure 3.1. The problem with most of the existing
tire models is that the solution of the slip force is a function of the slip velocity (like it is drawn
in the figure). However, especially for low-order numerical simulation, the responce of the model
for very low speeds will become noisy and inaccurate. In many situations it may even drive the
simulation into a limit cycle. As a result, the vehicle model could only be simulated for a minimum
velocity. It woult not be possible to come to a halt or to backup the vehicle.
For the purpose of a the VVSS, a novel tire model has been developed, which overcomes this
12
13
|F|
Fstick
Fcoulomb
Fviscous
v
Figure 3.1: The general characteristic curve for the friction force as a function of sliding velocity.
problem. It is based on the work of Dugoff, but modified to incorporate stick friction at low slip
velocity, by adding a differential position force feedback loop. The physical derivation as proposed
by Dugoff is outined in Appendix B. The following sections discuss the fuzzy tire model in more
detail. The objective is to relate the expressions for the forces between the vehicle and the terrain
surface to physically meaningful parameters and variables. The “magic formula” by Pacejka, as
well as many of the neural network based models do not. They will therefore not be considered
any further.
3.2 Stick Friction with Fuzzy Logic Switching
The derivation in Dugoff’s model solves for the forces on the tire and the wheel carcas caused
by sheer and stress. The derivations imply that the tire should be rolling and the vehicle should
be moving in order for the model to return meaningfull results. (This implication can also be
noted from Equation B.3 where the expression for has the tire’s longitudinal velocity
in the
denominator.)
ë
ìí
ëIîï
As a result, a tire will not be exposed to any forces from the ground contact, when the slipratio
. This can also be seen in the left graph in Figure B.3 in Appendix B. In practice, it means
that a vehicle will slowly slide down a slope, eventhough the surface is very rough, thus having a
high slip coefficient. In numerical simulation the model renders unstable results for slow speeds,
and is singular for zero velocity.
To compensate for this behavior, a feedback loop is imposed from the integrated slip ratio to the
moving forces. The feedback is designed as a second order spring damper model between the tire
carcas (which is the point where the rubber touches the rim) and the ground contact point. It is
applied from the position output to the force input. Fuzzy logic is applied to transition between
this spring damper model and the Dugoff tire model.
The design of the combination of the Dugoff model with the additional feedback loop is shown
14
ΣF
òp
ð
1
õF
÷
Mvs
vehicle model
slip,i
òp
1
s
òp
1
s
ñ
Shear Friction
υv
+ FFr
|Fz|
ö
+
Kstick
ø
slip angle
Fuzzy Logic
ô
-
slip magnitude
µSt
Stick Friction
Dstick
ö
υw
normal load
on the tire
FSt
vv=p
arctan(vv,vw)
+
δ=max(vv,vw)
δ
reset
1
s
vw
Re
effective tire radium
Re
ð
ΣT
ð
1
Mws
wheel spin model
1
s
ωw
1
s
ó
θw
Figure 3.2: Schematic diagram of the modified fuzzy tire model. On top, above the dashed
rectangle, the simplified vehicle model. In the bottom of the dashed rectangle, the wheel spin
model. The tire model consists of the Dugoff shear friction model, a spring-damper stick friction
model and a fuzzy-logic switch.
in the model diagram in Figure 3.2. The model shows that next to the dynamic friction force
feedback, there is an additional force feedback from the integrated velocity difference. This force
represents the stick-friction.
Fuzzy Logic is an intuitive non-linear linguistic rule-based method of inferencing. Two rules are
switching the force feedback, based on fuzzy sigmoid membership functions. The input force to
the vehicle motion model (top of the diagram in Figure 3.2) for tire consists of the shear and stick
slip forces as
ù
ú
ú
ú
û ü ý þ ÿ þ û û ù
ú
û ú
û (3.1)
where the index denoting the corner of the vehicle for the slip force, is included for consistency in
the overall vehicle model. Furthermore,
, since both
and
represent the tire
force, each for different operating conditions. The sum of the membership functions in Equation
15
v
v
v
s
w1
2
1
u
v
s
v,t=kh
w
u
w1,t=kh
3
4
Figure 3.3: The stick tire model is modeled as a double spring-damper system between the
trajectory of the vehicle and the trajectory of the wheel.
and
are the trajectories for the
vehicle and the wheel spin velicities, and
and
are the positions on these locations at time
.
!
3.1 therefore needs to be always 1. The input torque to the wheel becomes
# $" % & ' ( ) ' *,+ - % & ' ( ) . ) '
(3.2)
/0 1 is a sigmoid membership function, given by
/0 1 2435 6 7 8 9 : 2 ;=<?> @ A 8 ;=B C D
(3.3)
Figure 3.4 shows the plot for the membership function in Equation 3.3. In the equation, E represents
the gradient factor and F represents the center of the switching region. This center point is based
*,+ . This maximum defines the slip velocity, which is the command
on the maximum of G and HI
where
value for the fuzzy switching.
The following equation summarizes the fuzzy switched tire model
JK / " 0 1 - 0 1 ) . N
"- RS ) . V W
/
0
1
Q
3
M
P
2
O
"- % & ' ( ) ' L /" 0 1 - 0 1 ) T N
3 M 2PU O /0 1 Q "- RS ) T X
The stick model force
- 0 1 is given by
"- 0 1 ) . Y % 1 ' M ) . O Q 3[ % 1 ' 2 M ) . O Q \
BZ
BZ (3.4)
(3.5)
16
Membership functions for the fuzzy tire model
1
µ =1/
St
4(|x|−6)
1+e
µ =1−1/
Membership
Fr
4(|x|−6)
1+e
0.5
0
−6
0
6
max(v ,v )
v
w
Figure 3.4: Graphical display of the fuzzy logic sigmoid membership function.
]_I^` a b c de f#g b h i j kl c d4mn_g b h i jpo kl c d q
(3.6)
I^` a b
, and to represent the physical
In order for small numerical errors to accumulate in the force
property that a pair of rolling tires will not accumulate opposite lateral forces, a high-pass filter with
low cut-off frequency is applied. The trajectories and
are thus computed as the high-pass
filtered integrals of the differences of the vehicle and wheel spin velocities and .
pl
p^ l c j s?tevua bw p ^ l c j4m
p ^ ] c j s?t4evua bw p ^ ] c j4m
p]
x^ l c j y
x^ ] c j y
r^ l
r^ ]
(3.7)
(3.8)
z
In other words, the velocity difference is integrated, and the result is subjected to a “decay” factor
in time. Using the discrete time domain, the trajectories can be expressed in the -transform
representation as
k^ l=w { ye uua a b b {=} t?x ^ l=w { y
(3.9)
o | u a b
k ^ ] w { ye u a b {=} t?x ^ ] w { y
(3.10)
o|
`~ c € and `~ c d are depend on the particular
The longitudinal and lateral shear friction forces
terrain surface. Their values are derived from the Dugoff tire model in Appendix B. The inputu
output map for , the most relavant factor in the expression for the friction forces is given for the
17
 ν (vehicle speed)
v
Forward
„+µ
−µ
Braking
ĵTraction
 ν (wheel speed)
w
Traction
Braking
‚Reverse
Figure 3.5: Polar slip friction coefficient representation.
…
…
longitudinal force in Figure 3.5. The absolute value for is read from the graph as a function of
the vehicle and wheel speed velocities. When is to the upper-left side of the dashed line, its sign
is negative.
3.3 Implementation
At the implementation level, the algorithm can be assembled according to the above equations and
the results of Appendix B (In particular Equations B.34 to B.43).
‡† ˆ‰
The calculation of
using the the dynamic equations in the Dugoff model, can result in
time consuming numerical problems, especially when the velocities are small. A condition for
computing the equations that relate to the Dugoff model is introduced in the actual code, since the
equations need not be solved for low speeds, because the stick model will then be applied.
if (fabs(WheelSpin)>fabs(WheelTravel[PF_X])) mspeed = fabs(WheelSpin);
else mspeed = fabs(WheelTravel[PF_X]);
membership = 1/(1+exp(4.0*(mspeed-6.0)));
patch_dispx[i] -= (WheelTravel[PF_X] - WheelSpin)*dt;
18
patch_dispy[i] += WheelTravel[PF_Y]*dt;
patch_dispx[i] *= membership;
patch_dispy[i] *= membership;
if (membership<0.9) {
SlipDir = WheelTravel[PF_Y]/abs(WheelTravel[PF_X]);
SlipRatio=(WheelSpin-WheelTravel[PF_X])/mspeed;
Vs = WheelTravel[PF_X]*sqrt(SlipRatio*SlipRatio+SlipDir*SlipDir);
mu = (mu0) * (1 - AS * Vs);
CoefDen = mu*abs((FTire[i])[PF_Z])*(1.0-SlipRatio);
SlipNorm = CS * SlipRatio / CoefDen;
Alpha = CA * SlipDir / CoefDen;
SlipMag = sqrt(Alpha*Alpha+SlipNorm*SlipNorm);
if (SlipMag<0.5) CoefDen = (1.0-SlipRatio);
else CoefDen = (1.0-SlipRatio)*SlipMag/(1.0-1.0/(4.0*SlipMag));
SlipForce.set(
CS*(SlipRatio/CoefDen*(1-membership)+
(patch_dispx[i]-(WheelTravel[PF_X]-WheelSpin))),
-CA*(SlipDir/CoefDen*(1-membership)+
(patch_dispy[i] + WheelTravel[PF_Y])),
0.0);
} else
SlipForce.set(
CS*(patch_dispx[i] - (WheelTravel[PF_X]-WheelSpin)),
-CA*(patch_dispy[i] + WheelTravel[PF_Y]),
0.0);
3.4 Simulation results
Figure 3.6 shows a logic switched coupling of the stick friction model and the Dugoff model in
the left, and a smoother fuzzy aggregated coupling of the models in the right hand side. For the
fuzzy logic switched model, the membership functions in Figure 3.3 have been used.
The figure shows a scenario for acceleration, and braking, followed by a positive constant torque
forward, and reverse constant torque reverse.
19
Forces with Logic Switch
Forces with Fuzzy Logic
vv
vw
Speeds (m/s)
Speeds (m/s)
vv
vw
6
0
10
20
30
40
50
0
10
0
10
20
30
40
20
30
40
5000
Forces (N)
Forces (N)
5000
0
−5000
−10000
6
0
10
20
30
Time (s)
40
50
0
−5000
−10000
Time (s)
Figure 3.6: Simulation results with the fuzzy tire model for acceleration and braking. The top
graphs show the velocities, the bottom graphs the associated longitudinal slip forces. The left
graphs shows the slip forces when using a digital logic switch for the friction models. The right
graph shows the smooth transition when using fuzzy logic switching.
20
3.5 Conclusion
A new fuzzy logic based dynamic tire friction model has been derived, to simulate realistic force
response, for all vehicle and wheel speeds. The fuzzy tire model is based on physical characteristics
and properties of slip friction and stick friction. The stick friction properties have been modeled
as a spring-damper system for the longitudinal and the lateral directions for in case of slow driving
scenario, hence in the situation of no slip.
The model presents a set of analytical equations that is incorporated into the vehicle model,
allowing it to simulate a vehicle in driving scenarios of any vehicle velocity.
Chapter 4
Numerical Integration of the Vehicle Model
The vehicle model and the fuzzy logic tire model have been defined in the precesing chapters.
The next step towards implementation and numerical simulation is the selection of a suitable
integration method. Integration methods are studied by many scientists in a wide field of research.
The emphasis in this thesis is on the real-time application and the non-linear character of the model.
In this chapter, first an overview of integration methods for real-time application and accuracy will
be given. Then the discussion focuses on the interconnected system for digital real-time integration
algorithms. Examples are given for illustration.
4.1 Transformation and Integration Methods
The closed loop system of the vehicle system has been modeled in three submodels in Chapter 2.
The next task towards simulating, is to translate this model so that its behavior can be calculated
in a computer. This task is discussed in the following sections.
When a continuous time system is simulated on a digital computer, its response is computed at
closely spaced discrete times. Output results are generated by joining the closely spaced calculated
response values with straight line segments, approximating a continuous curve. The accuracy and
speed of computation depends on the integration scheme that is used and on the choice of the
integration step size.
Especially for the real-time simulation of continuous dynamic systems, the choice of numerical
integration methods is an important consideration. In real-time simulations, the choice of numerical
integration methods is generally based on different considerations than those used in numerical
solutions in off-line predictive studies, when there is no real-time requirement.
For example, in real-time simulation, a fixed integration time interval is used, since the simulation
must always produce the next value of each dynamic state variable at or before the time the variable
will occur in real-time. This requirement sets a lower limit on the mathematical step-size which
Š
21
22
f
f
fn
f
fn+1
fn+1
fn
fn+1
fn
fn-1
‹t →
nh
(n+1)h
x
nh
(n+1)h
a. Forward Euler Integration
n+1
x
=x n + h (3f n -f n - 1 )
2
n+1
Œ
fn+1
nh
(n+1)h
x n+1 =x n + h (f n+1 +f n )
2
d. Bilinear Integration
‘_ ’ “
=xn+hfn+1
f
fn
fn+1
fn+0.5
fn-1
‹t →
(n+1)h
c. Backward Euler Integration
f
fn
nh
t→
b. AB-2 Integration
xn+1=xn+hfn
f
(n-1)h
t→
(n-1)h
t→
x
fn-1
nh
(n+1)h
h
=xn+ (5fn+1+8fn-fn-1)
12
(n-1)h
t→
x
nh
(n+1/2)h
(n+1)h
=x +hf
Ž
e. 3rd Order Implicit Integration f. Modified Euler Integration
n+1
n+1
n
n+1/2
Figure 4.1: Graphical intepretation of different integration algorithms for the differential equation
.
23
can be used for integration.
”
The need for a fixed time-step is in fact somewhat of a blessing, since it means that the -transform
methods, originally developed for the analysis of sampled data systems can be utilized for dynamic
error-analysis of real-time digital simulations. Care has to be taken, to verify that stiff subsystems
or marginally stable poles in the continuous sytem do not cause instability after transformation.
From Figure 4.2 it can be seen that part of the left half plane in the -domain is mapped outside the
unit circle for the forward Euler transformation. In other words, stable poles in the continuous time
domain can result in unstable poles in the discrete-time domain when the unsuitable integration
scheme is used. This aspect will be further addressed in the following section..
•
Another consideration is that in real-time simulation, the integration algorithms cannot require
external input data prior to the time when it is available in real-time. This eliminates many implicit
integration methods that are popular in non-real-time applications. To avoid this limitation, a
suitable partitioning of the model into sub-models can be usefull in the sequencial calculation.
An emphasis to partition the vehicle dynamics can therefore be noted from the preceding section
concerning the development of the model.
–
There will be a maximum allowable integration step size for any given dynamic simulation using a
specific integration method, for which the dynamic accuracy of the simulation is barely acceptable.
One important aspect is the computer power that is used. From the above real-time requirement, it
follows that the CPU cannot take more than seconds to complete all the calculations associated
with each integration step. Section 6.3 will discuss this matter as well, once the vehicle dynamics
formulation has been defined.
–
—˜ ™–
Hence, real-time simulation of a dynamic system must be considered as a sampled data system.
.
The system response is evaluated at equally separated points in time
It must be understood that discretization of the system automatically implies the selection of an
integration scheme. After the transformation, the linear system in Equation 2.2 is transformed to
a system that describes the new states
as a function of the previous states and the previous
inputs
and the new inputs
.
ž›
ž› œ?
š› œ?
š›
Ÿ ¡
Since the resulting system incorporates an integration scheme, care must be taken in the selection
for this integration method, as a more complicated scheme (like a
order Runge-Kutta) will
increasingly intensify the mathematical effort to compute the solution of the system. The advantage
of a complex and more accurate integration scheme is that a larger step-size can be selected.
However, this advantage fails when the system behavior is non-linear.
–
Six of the popular integration methods are shown in Figure 4.1. From this overview it is clear that
the methods in Figures 4.1a and 4.1c, respectively the forward and backward Euler integration
methods, are the least computationally intensive. As the trade-off, they generate the largest
simulation error, when used to compute the output response of a system.
The next more complex method with improved accuracy, will be the bilinear (or Tustin, or
trapezoidal) integration method. Note that the implementation of the modified Euler method in
Figure 4.1f would result in the bilinear transformation scheme, when using a fixed integration step
size.
24
¢jω
£
Im
s-plane
z-plane
σ
(a) Continuous Domain
£
-1
Re
(b) Forward Euler Transformation
£
Im
z-plane
-1
1
1
(c) Bilinear Transformation
Re
Im
z-plane
-1
1
Re
(d) Backward Euler Transformation
Figure 4.2: Three different transformation methods for approximating continuous to the discrete
time domain, with the corresponding stability regions.
25
§
¥
¤
©¨
¦
¤
©ª
¦
¤
©
Figure 4.3: A general example of a second order mechanical model with force input and position
output.
The bilinear method is demonstrated in Figure 4.1d. These three methods have the following
transformation equivalents
´
±± µ·¶ ¤
± ´
¤
²
«­¬ ¦®¯ ±± µ·¶ µ ¤
±± ´¸ ¤
±³ µº¹
µ·¶ ¤
°±±
Forward Euler Approximation
Backward Euler Approximation
(4.1)
Bilinear or Tustin Approximation
Detailed derivations and formulation aspects on these three schemes can be found in Chapter 13
in [38]. An important consideration for the choice of integration approximation method is the
mapping of poles from the -plane to the -plane. Figure 4.2 shows how the area of stable poles in
the continuous domain is translated to the discrete domain. From a stability perspective, the better
choice for the integration method will be either the backward Euler, or bilinear transformation.
¦
µ
A combination of the forward Euler and Bilinear approximation methods in Equation 4.1 is used
for the VVSS. To illustrate how they are implemented, consider the continuous time interconnected
system in Figure 2.2.
Subsystem Transformation
»
The computation of integrations inside the individual subsystems are implemented with the bilinear
transformation method, shown in Figure 4.1 . For example, for a system with force input and
position output, as given by Figure 4.3 we would integrate as follows:
©ª ¼ ½?¾ ¯ © ª ¼4¹ ¥ ¤ ¬ © ¨ ¼ ½?¾¸ ¹ ©¨ ¼ ® ´ ?¶ « ¿À©Iª Á µ  ¯ ¥ ¤ ¬ ´¸ µ·ºµ ¹¶ ¤¤ ® ©I¨ Á µ Â
and subsequently
(4.2)
26
È ÃË Ä
ÃÄ Å?Æ4Ç ÃÄ4ÈÊÉ#ÃË Ä Å?ÆÌÎ
ÍÐÏÒÓ?Ñ Ô
ÃIÕ Ö ×ÇØÉ
ÏÌ ÖÖ È ÙÙ Í IÃ Ë Õ Ö ×
Ó
(4.3)
The selection of the above integration methods is based on the fact that maximum accuracy is
desired for the dynamics response of the internal subsystems. At the same token, the simulation
will have to be conducted in real-time. This means that a fixed integration step size will have to be
used, and no iteration schemes can be applied for evaluating a single point in time. Hence, only
explicit methods are applicable.
Ú
The application of the integration method leads to a discretized approximated system
continuous system in Equation 2.3. It will result in the discrete state space system
ÏÌ ÕÕ ÖÖ ÈÙÙ ×× É Ý Õ Ö × x ÈÞ_Õ Ö × u ÈvßÕ x u× Í
Ó
¯
¯à ¯
¯
Çy á x Èâ u ÈãÕ x u× ä
¯
¯
¯à ¯
¯
x
¯
Ö
Ç
ÚÜÛ
of the
(4.4a)
(4.4b)
åÇ æÏ È Ï
The inverse -transform applied to Equation 4.4b will give the following solution to for the system
response at
Ä Å?Æ Ç Ýºç xÄ ÈvÞ ç Õ uÄ Å?Æ È uÄ ×Èè çºÉ ßÕ xÄ Å?Æ uÄ Å?Æ ×ÈßÕ xÄ uÄ × Í
¯
¯
¯
¯
à¯
¯ à ¯
Äy Å?Æ Çá x¯Ä Å?Æ Èâ u¯Ä Å?Æ ÈãÕ x¯Ä Å?Æ à u¯Ä Å?Æ ×
¯
where the lumped matrices ݺç , Þ ç and è ç are given by
Æ
Ï
ݺç ÇØÉ=é Ó Ì Ý Íê É éºÈ ÏÌ Ý Í
Æ
Þ ç Ç ÏÌ É é Ó ÏÌ Ý Í ê Þ
Æ
è ç Ç ÏÌ É é Ó ÏÌ Ý Í ê
x
¯
(4.5a)
(4.5b)
(4.5c)
(4.5d)
(4.5e)
System Interconnection
ëì ëì ì í î
ëì ì ì
Now take the system in Figure 4.4. This system is a decoupled version of the model of the VVSS,
given in Figure 2.2. Assume that the subsystems ,
and
are discretized with the bilinear
integration method, as discussed in the preceding paragraphs. The resulting transfer functions for
the subsystems are now given by
y
¯
Õ Ö ×Ç ë ç Õ Ö × u Õ Ö × , or in short y Ç ë ç Õ Ö × u ä
¯
¯
¯
(4.6)
27
Interaction with
human driver and
terrain
u
¯
ï
ôõ ö
x
¯
ðñ ò ó
÷ ôõ ö
x
¯
ðñ ò ó ó
ø ôõ ö
ðñ ò ó ó ó
x
¯
ù ôõ ö
Figure 4.4: interconnected discretized closed loop system.
ú=û
, each of the three subsystems will be
In the process of evaluating the system at a given time
computed consecutively. Figure 4.4 shows the model for the VVSS in discrete time representation.
The submodel with the human driver and terrain is denoted by the operator
. For the first
subsystem , we must realize that the input u
at is computed from the output of the
¯
third system at the previous time interval , hence
ü ô ýö
þ÷ ÿ
ú
÷
uþ ÿ ü xþù (4.7)
¯
¯÷
÷
Obviously, if ü
has any dynamics, they will be integrated using forward Euler. In the following
ô ýö
derivations, the subscripts , and will be employed for the system matrices and to
ú
ðó
denote which subsystem they apply to. The output of the first subsystem is computed as
x
¯
þ÷ ÿ
÷
þ÷
ñ òó
x
¯
ñ òó ó
x
¯
ñ òó ó ó
x
¯
ñ òó
u
¯
þ÷ ÿ
÷
u
¯
þ÷ (4.8)
þ÷
Then, for evaluating the second subsystem, we realize that the input is the output x of the first
¯
subsystem that has just been computed. Incorporating this gives
x
¯
þø ÿ
÷
And for the third subsystem similarly
x
¯
þù ÿ
÷
þø
þù
ñ òó ó
õ
ñ òó ó ó
x
¯
þ÷ ÿ
x
¯
þø ÿ
÷
÷
x
¯
þ÷ x
¯
(4.9)
þø (4.10)
The above equations can be formulated using the -transform for the linear terms, as
x
¯
÷
ôõ
ö ô õ ñ ò ó ö ÷ ñ ò ó
u
¯
xþ uþ ÿ
xþ uþ
ô
¯÷ ¯ ö
ô
÷ ó ¯ ÷ ¯ ö
ñ òó ó
(4.11)
28
x
x 8 9 x8 :
x 8 9 x8
"! # $&%' ( # $ )*+, - . . ( /10 2, - . . 3 ¯ 40 %5, - . .67 . . # ¯ ¯ 0 ( %7 . . # ¯ ¯ 0 (1;
0
8
9
x
x x8 :
x 8 9 x8
x
¯ < "! # $&%' ( # $ )*+, - . . . ( /10 2, - . . . 3 ¯ 4%5, - . . .67 . . . # ¯ ¯ < (4%7 . . . # ¯ ¯ < ( ;
0
x
¯
(4.12)
(4.13)
The above process of evaluating system response implies the application of the Tustin bilinear
method for the connecting subsystems.
Notice that the matrices
and
have function for the subsystem interconnectivity, the
2, - . .
2, - . . .
system can be completely described in a large state space representation as
=>?
$
x
¯
x0
¯
x
¯<
@A
=>?
B
%
=>?
@ A =>?
@A
x
+, - .DC
C B x¯ 0 B
2, - . .E+, - . .DC
¯
%
x
CF2, - . . .G+, - . . .
¯<
x8 9 x8 :
x8 9 x8
5, - .H! 7 I . # ¯ x8 ¯9 < x8 : (%J7 I . # ¯ x¯8 < 9 (1x3 8
5, - . .H! 7 I . . # ¯ x8 ¯9 < x0 8 : (%J7 I . . # ¯ x¯8 < 9 (1x3 8
5, - . . .H! 7 I . . . # ¯ ¯ < 0 (%J7 I . . . # ¯ ¯ <
0
=>?
@A
2, - . B
C
@AC
u
¯
B
(4.14)
(13
It is important to notice that the above explicit formulation incorporates the bilinear integration
scheme. This notion implies that the system matrix is not constructed from intuitive equations of
motion anymore. Only forward Euler formulation will do so. The following example demonstrates
this point.
EXAMPLE 1 Embedding of integration scheme.
Assume the following linear system of three integrators:
O
P
KL
0
LM
P
LN
P
<
Using the bilinear integration method, this system is described by the following set of simultaneous equations
P 8 R KS TVU O 8 : R O 8 W
04Q 0 0
:
P 8R M S T U P 8 : R P 8 W
04Q 0- 0
0:
P 8R N S T U P 8 : R P 8 W
04Q < - U Y RZ W - 0
Notice that new state values (i.e. for X
S ) appear in the right hand side of these
Q
equations. The above equations can be evaluated,
using the new state values immediately in
P 8
0P 8
P 8
<-
:
29
the second and third equation. We can express the result of this implicit process in an explicit
form by substituting the expression for [\ ] ^ _1\ in the second equation and then substituting
the expression for [` ] ^ _1\ in the third. Rearranging of the result after substitution gives
[\ ] ^ _1\4ab[\ ] ^ced fg ^
`
[` ] ^ _1\4ab[` ] ^ceh f[\ ] ^ced h f V
i g^
`
j
[ j ] ^ _1\4ab[ j ] ^cek f[` ] ^ceh k f i [\ ] ^cld h k f m g ^
From this last equation, we could not tell at sight that
[j
is the integral of [` .
Generally, a system of simultaneous equations will be transformed to produce an explicit expression
for the state values using linear algebra. The following example will show this process.
EXAMPLE 2 Linear vector solution of differential equation using Tustin
Take again the linear triple integrating system from example 1. Consider the set of three
simultaneous equations. After separating state values for n4ao p cbq r f and n4abp f to the left
and right side of the equal-sign, the following system will appear
stu
| } stu
qwvxv
y h z`
q{v ~
y
v
k z` q
| } tus
| } tus
| } tus
|}
[\ ] ^ 1_ \
q v€v

[ \ ] ^
df
[` ] ^ 1_ \ ~ a
h z` qv ~ [ ` ] ^ ~ c
v ~ g^‚
[ j ] ^ 1_ \
[ j ]^
v
v€k z` q
Multiplying left and right side with the inverse of the matrix on the left, will result in
stu
| } tus
[\ ] ^ 1_ \
qwvxv
y
[` ] ^ 1_ \ ~ a
h z`
q{v
y
[ j ] ^ 1_ \
v
k z` q
stu
|}
qŒv€v
a
h z`
qv ~
h k z Ž  k z` q
stu
|}
qvv
a
h f‘q’v ~
h k z `  k f“q
| } \„…† stu
qv‡v
h z` qˆv
~Hƒ
v‡k z` q
| } stu
„…†stu
qv‡v
h z` qˆv ~
v‡k z` q
stu
| } stu
[\ ] ^
df
[` ] ^ ~ c
d h z`
d h k zŽ”
[ j ]^
| } stu
| } tus
|}
[\ ] ^
df
v ~ g ^ ‹‰ Š
~ [` ] ^ ~ c
[ j ]^
v
| } tus
|}
[\ ] ^
df
[ ` ] ^ ~ c
v ~ g ^ ‰‹ Š
[ j ]^
v
|}
~ g^‚
The individual state equations of this solution are equal to the ones in the preceding example.
For example the state equation for [ j is given by
`
[ j ] ^ _1\4ab[ j ] ^clh k f V
i [\ ] ^clk f[` ] ^ ‚
which cannot be immediately observed from the system model diagram. In this example we
have transformed the discrete model into an explicit form. The representation is the solution
to the state transition equation.
30
The method of matrix inversion of Example 2 cannot be used for the non-linear system of the VVSS.
These linear examples with linear models however, illustrate the complexity of the approximated
discretized model when using the bilinear integration method.
The non-linear model is organized in such a way that the structure of the state transition matrix
approaches lower triangular shape as much as possible. The lower triangular shape allows for
immediate substitution of state values for •–—˜V™b˜ in the sequencial evaluation process, as was
illustrated in Example 1. The ideal formulation for the system is thus given in Expression 4.14.
The aim towards this structure fails whenever there is internal feedback. For internal feedback,
only values at the previous time step •–"—˜ are available for the states that are fed back. The
integration method for the feedback loops will thus be forward Euler š
4.2 Conclusion
The requirement of real-time simulation adds a serious constraint to the selection of a numerical
integration method. The discussion in this chapter highlighted on the necessity for an explicit
formulation of the state equations, after incorporating the integration approximation method.
The bilinear integration method applies well in the case of decoupled interconnected systems. In
cases when internal feedback appears, the forward Euler approximation method has to be used.
The bilinear method is not too complex so that it can be used for real-time simulation, yet it is
stable and sufficiently accurate to simulate the vehicle dynamic response in a reliable fashion.
›
In the reccomendations, a Luenberger observer is suggested, to estimate state values, so that the bilinear integration
method can still be used, but based on estimations of the state values.
Chapter 5
Simulation Platform with Integrated
Networking Environment
In this chapter, the multi-processing configuration for real-time simulation is introduced. The
name in the title will be referred to in short with SPINE. The objective is to implement the VVSS
in such a way that other workstations can interact with the vehicle model during the simulation,
while minimizing disturbance to the simulation performance. It will be shown that by simulating
parts of the vehicle model in a remote workstation through SPINE, a change in integration scheme
takes place. The implications of this change will be discussed. Furthermore an observer system
will be introduced to predict simulation output when a workstation does not respond in time.
5.1 Introduction
Modular thinking has introduced a new realm of engineering of a fundamental systems approach.
Methods on modularity are diverse and are associated with many disciplines. The common
philosophy, is that subsystems can be considered individually, without loss of generality in the
overall systems requirements.
The next step in the exploration towards virtual vehicle system simulation is modularity. The
VVSS will become effective and efficient for virtual engineering and prototyping when partitions
and submodules of the vehicle model or the virtual environment can be substituted.
At the same time it will be beneficial in several ways, to simulate these modules remotely. It is
beyond doubt that simulation performance can be improved, when different modules are executed
on different machines. This will allow for multi-rate multi-processing in a integrated system
structure. Furthermore, it will contribute to the generality of the simulator, when attributes to the
virtual environment (like terrain, the vehicle platform, optional armor etc.) can be replaced as
modules in a multi-purpose simulation facility.
31
32
ž
Stereoscopic Scenery Display

Full Observer/Commander
Virtual Mission Immersion
œ
Pentium-PC
Traction
Control
œ
Pentium-PC
Anti-Lock
Brake model
TCP-IP
œ
Pentium-PC
Active
Suspension
œ
Pentium-PC
Collision
Warning
100 Base-T
Pentium-PC
Driver Cab
Interface
Pentium-PC
Intelligent
Peripherals
Human Driver
Human Driver
Pentium-PC
Engine and
Transm Contr
Pentium-PC
Trajectory,
Navigation
Silicon Graphics
Reality Engine
250 MHz
4xR10000 CPU
IRIX-Performer
Stereoscopic
Visualization
Bilateral Force and
Motion interface
Surround Audio
Figure 5.1: The proposed implementation for the Virtual Vehicle System Simulation (VVSS) in
the Simulation Platform with Integrated Network Environment (SPINE).
As a third, not the least important argument, system modularity allows the researcher to extract
one module from the simulation, and replace it with another (high detail) module, in order to gain
more fidelity and hence more accurate simulation results for the particular subsystem. Modeling
several high fidelity models through SPINE in this manner implies the simulation of a high detail
model with intelligent load distribution. Or an engineer could replace a submodel of the vehicle
system to analyse new control concept systems.
Finally, it will be advantageous to Oakland University, to be able to conduct additional research
gradually, for future improvements on the VVSS. The modular design in this chapter contributes
to these goals.
5.2 Methods for multi-processing
Multi-processing needs to be viewed upon as a method for performing the computation task of, in
this case simulation. To speak in general terms, assume the following model to be the system that
we would like to simulate:
Ÿ¡ ¢¤£
(5.1)
Three methods for multi-processing in the application of simulation will be discussed, each with
33
CPU1
CPU2
CPU3
¥¦
¥§
¥¨
(a) Configuration 1
CPU3
®e±
CPU2
®e°
CPU2
CPU1
©H¬
CPU1
CPU1
© ª«
®e¯
© ª­
(b) Configuration 2
(c) Configuration 3
Figure 5.2: Three variations of configurations for Multi-CPU simulation models.
34
a different partitioning of ² . First there is the proper model partitioning method. As shown in
Figure 5.2a. The model has internal chain connectivity. It must be object-oriented, decoupled and
the total system will have to have a cascaded configuration.
The disadvantage for multi-processing is that, if a model is divided into several partitions, each
partition can only use the simulation results of the previous time step for every other partition,
since the current results for the other partitions are being computed simultaneously in parallel. In
other words, the decoupling introduces a time delay into the system, because the interconnection
between the subsystems can only be defined in an explicit manner. As a result, the response of
the system for input actions will be retarded and there is the possibility of the system becoming
unstable. From the point of view of mathematical integration technique, the bilinear method is
replaced with the Euler method at each subsystem interconncetion.
A solution for the time delay and the instability problem would be, to cancel the delays by adding
a zero in the origin of the pole-zero map of the system, for each interconnection. Technically this
would change the integration method between the subsystems from forward Euler to backward
Euler. The implementation however, would mean that the CPU’s have to wait for eachother to
finish their computation. In other words, a system solution for ³ ´Jµ¶·¶ will be ready after ¸
simulation clock cycles, where ¸ is the number of interconnected subsystems. This solution would
defeat the purpose of parallel computing and multi-processing.
Then there is sequencial simulation, as demonstrated in Figure 5.2b. This method could be
implemented using semaphores or waitstates to synchronize communication and processing. CPU
1 will evaluate a partition of the system, communicate with CPU 2, and then wait for the output of
CPU 2 before it will finish the simulation cycle.
This method does not exploit double computer power for parallel processing. In fact, the simulation
is pseudo single-processing.
The third method is based on concurrent computing of states, as shown in Figure 5.2c. The required
inputs for solving the equations of a (submodel for a) state will be made available by the first CPU.
In this fashion, high frequency dynamics in the model can still propagate high bandwidth to the
output. However, the bandwidth of the output of the submodel will be limited.
The last method results in a generalized formalization of multi-processing, at the cost of decrease
of bandwidth for parallel simulated states. Since this configuration allows us to select parallel
subsystems in the form of specific dynamic states, this method is adopted for SPINE. The next
section will detail about the third configuration.
5.3 Multi-processing of dynamics models
The setup for the multi-processing vehicle simulation is presented in Figure 5.1. The mathematical
approach for the interaction of modules with the vehicle simulation is presented in the following
paragraphs. The concept is to replace one or more states in the general vehicle dynamics state space
system matrices, with outputs of a model that is simulated elsewhere on the integrated network.
35
For the interaction this means that in each integration step, the VVSS will request the modules for
replacement of system states, and then return a set of updated states.
The vehicle dynamics model has been presented in Chapter 2, and is given in the form of the
nonlinear state space representation in Equation 4.14. To introduce the concept of replacing state
variables in a system, a general case of state-replacement for a linear system will be presented as
an example first.
EXAMPLE 3 Substituting a state in a linear system and adding a state.
º¤
¹ »J¼ º½ ¾ ¿ ¿ ¿ ¾ º À ¾ ¿ ¿ ¿ ¾ º Á  Ã
Consider a linear homogeneous system, consisting of the state
Ä »Å Æ ÇbÈ É Ê where each element is given by
Ï Ï
º À Ë Ì Í1½»bÎ ÏÐHÀ Ë º Ë Ì ¾ÒÑ ¾ ÓÔ¤Õ È ¾ Ö× × × Ø1Ù
at
(5.2)
Suppose that state variable º Ú represents an element in the dynamic model. The equation for
Ä
the state º Ú at time »Å Æ ÇÈ É Ê is described by
ßàà º½ Ë Ì ã ää
ä
àà
àà ... äää
àà º Ú â1½ Ë Ì ää
Ûº Ú Ë Ì Í1½4»ÝÜ ÐÛ Ú Ë ½× × × ÐÛ Ú Ë Á Þ àà º Û Ú Ë Ì ää ¿
ààá º Ú Í1½ Ë Ì ää
..
.
º Á ËÌ
(5.3)
å
Û
The submodel for evaluating the state º Ú may contain additional states. In this case a state
will be added to the total system. An additional row in the transition matrix will express the
dynamics of the new state;
ßàà
àà
àà
ã ää
º½ Ë Ì
ää
ää
..
.
àà º Ú 1â ½ Ë Ì
à Û
º Û Á 1Í ½ Ë Ì Í1½4»ÝÜ ÐHÛ Á Í1½ Ë ¡
½ × × × ÐHÛ Á 1Í ½ Ë Á Í1½ Þ ààà º Ú Ë Ì
àà º Ú Í1½ Ë Ì
áà ..
.
º Á ËÌ
º Û Á Í1½ Ë Ì
ää
ää
ää ¿
ää
(5.4)
ä
å
Û
and an additional column is added to represent the contribution of the added state º Á Í1½ to the
Ä
states º À for Ñ1»È4¿ ¿ ¿ Ø . The states are expressed for »bÆ Ê ÇeÊ , and are based on values for
36
the states at æçè
computer.
é
. This means that the system is explicit can can be computed by a digital
The above example mentions that the state value ë ê ì í î ï1ð is based on values of states at time ñHòóô .
The same holds for the other states in the system. Whilst after each simulation cycle the state
values for ñ¡òõóô will be exchanged. This notion will be important to understand the timing
implications of parallel simulation.
Since the vehicle dynamics model is nonlinear, we will discuss the state-replacement now for the
nonlinear case.
EXAMPLE 4 Substituting a state in a non-linear system.
If each state ö ÷ is assumed to be described by a nonlinear function ø
a nonlinear system as
þÿÿ
þÿÿ
ö ð í î ï1ð ÿÿ
ð ÿÿ ø ÿÿ
ÿÿ
ç ÿÿ
í
î
ï
1
ð
ÿ
ö
..
.
þÿÿ
ø þÿÿ
÷ ù öú û üú ý , then we can write
ÿþ
ö ð íî ÿ ü ð íî ..
..
. û
. ü íî
ö íî
ÿþ
ö ð íî ÿ ü ð íî ..
..
. û
. ü íî
ö íî
..
.
(5.5)
ì
For this case, replacing the functional model for state ö means that each model for ö ÷ , where
ð
ç that is dependent on the state value will be changed to reflect the new model ö ì .
The superscript notation is introduced for state
is computed in remote process 1. In formula
þÿÿ
ð íî
ÿÿ ö
ð
ÿ ...
ÿÿ ì 1ð í î
ÿÿ ö ð
ö ÷ í î 1ï ð çbø ÷ ÿÿ ö ì í î
ÿ ö ì ï1ð í î
..
.
ö íî
. It is used to denote that the new state
ö ì
ÿþ
ÿ ü ð í î .
û .. ü íî
where for ö ì , the new model is given by
öì
for
ç û ç
(5.6)
37
()) ,+, # $ 0 11
)) ,, . 11
)) ,, .. 11
) , " . #$ 1
!" # $ % ' " ))) ,,, " # $ 111
& )) ,, 1
" % #$ 1
* - ... 2
/ #$
Substituting Equation 5.7 into 5.6, shows that : # $ %
time ;=<?> by means of " # $ .
6 77
77
+,, 4 0 11 777
#$ 7
.
3 - .. 2 777 9
4 5 #$ 7
8
(5.7)
depends directly on states and inputs at
The problem here is that the value for state @ is not updated until communication for exchange of
data takes place. Hence, parallel simulation of a submodel will introduce time delay in the system.
This notion can also be understood when considering that Equations 5.6 and 5.7 are concurrently
computed for each integration step. Substituting 5.7 into 5.6 shows that A : # $ % B now depends on
state values A C " # $ for the following integration steps D , before the value of state @ is updated. The
concept of state equation replacement by a parallel model will thus introduce one integration time
latency or phase lag. In order to understand the timing of the system, we will take a closer look at
example 4.
The evaluation of state A C " # $ % is based upon the state values at EFHG!I . Likewise the evaluation of
the remaining system will be computed with values for the state A C " at time EFHG!I .
The trade-off for using the method of parallel simulation that is presented here, is that “fast” states,
or states with a large bandwidth will show degradation of dynamic performance caused by the
inferior integration method, when simulated in a parallel CPU.
Note that a submodel for state with a small bandwidth, which requires inputs with small bandwidth
may still expose high frequency dynamic behavior internally. The system will experience minimum
loss of fidelity when the bandwidth of the signals that are exchanged between the processes is
low, with respect to the integration time interval. The selection of the integration step size in this
respect is further discussed in Section 7.3.
The phase lag increases when yet another state AKC LJ is remotely computed, on which
The following example will illustrate this scenario.
AC "
depends.
EXAMPLE 5 Simulation of a non-linear system with two dependant parallel subsystems.
The possibility exists that the delay in the system will increase when two subsystems are
simulated on SPINE. This happens when one of the subsystems is dependant on the other. For
example, with
, we would have
MONP
38
YZZ ]\] R
ef
ZZ ]] S U V _ S fff
..
ZZ ]]
f
ZZ ]] R T _ . U V _ fff
ZZ ]] R Q S S S ff
ZZ ]] T U V _ S ff
ZZ ]] R T ` S U V _ S ff
ff h
.
R!Q T S U V=W X Q T S ZZ ]]
f
ZZ ]] R a ..
ZZ ]] Q _ S U V _ S fff
ZZ ]] Rcab U V _ S ff
Z ] R a ` S UV _ S f
..
.
[ ^
g
R d UV _ S
Q
where for the additional replaced state model Rcab ,
YZZ \]] R
ef
ZZ ]] S U V _ b fff
..
f
ZZ ]]
ZZ ]] R T _ . U V _ fff
ZZ ]] R Q S S b ff
ZZ ]] T U V _ b ff
Z ] R T ` S U V _ b ff
QR ab U V _ W X Q ab ZZZ ]]]
ff
.
S
ZZ ]] R a ..
f
ZZ ]] Q _ S U V _ b fff
ZZ ]] Rcab U V _ b ff
Z ] R a ` S UV _ b f
..
.
[ ^
g
R d UV _ b
k ll
ll
ll
ll
ll
\]] i U V _ e ff ll
S S ll
l
.
^ .. g ll h
i j U V _ S ll
ll
ll
m
(5.8)
k ll
ll
ll
ll
ll
\]] i
e ff ll
S U V _ b ll
h ^ ... g lll n
i j U V _ b ll
ll
ll
m
(5.9)
The time index in the above expressions is chosen so that the delay can be explained with
Figure 5.3.
RQ a U V _ b
R S UV
RQ T U V _ S
RQ T U V _ S
RS
For example state
depends on the output of state
. Similarly, state
requires
as an input. Thus, the propagation of a dynamic behavior to a state
will take as
much as 3 integration step sizes, eventhough originally there might mathematically be a direct
relation from input to output for this behavior.
Time delay introduced in the system when a subsystem is simulated in parallel, technically, because
the prediction of the dynamics of the state values in the system is lost when a state model is separated
from the system model, and is simulated in parallel to the rest of the system instead. To compare
the situation with teamwork, realize that efficiency is lost, when a task for one person is now being
delegated to two persons who only communicate for one hour per week.
39
Simulation execution
Communication checkpoint, exchange state values
x1,k-3
o
xn,k-3
o
x1,k-2
xn,k-2
prq
prq
pts
~
xp,k-1
~
x
k-2
x1,k+1
xn,k
xn,k+1
prq
pts
~
xp,k
~
x
q,k-1
k-3
o
x1,k
xn,k-1
prq
pts
~
xp,k-2
o
x1,k-1
q,k
k-1
~
xp,k+1
~
x
q,k+1
Time (T s)
k+1
k
Figure 5.3: Timing diagram for double dependant replaced state variable.
As was explained in Chapter 2, the prediction is implicit in the vehicle dynamics system, since
the continuous time model has been transformed to the discrete time model using the bilinear
integration method.
The remote states can be evaluated correctly, if the coefficients of the explicit state transition
matrix would be available. However, this will require many of the vehicle dynamics modeling to
be computed in the remote CPU.
As an illustration of this argument, the following example will demonstrate the simultaneous
simulation of a state in a parallel process.
EXAMPLE 6 Parallel simulation of a state using SPINE.
When a state model is simulated remotely through SPINE, a time delay is introduced. The
cause for the delay is swiching of the integration method to forward Euler approximation. To
illustrate this phenomenon, consider the integrating system from Example 1
Take the simple third order linear system from Example 1. Suppose we would like to replace
the second subsystem, i.e.
y
uv
z!{
zc| }
wv
In the simulation of the parallel process we will model state
zc| } 
v € wv
z!{ 
v€
z~
xv
zc}
as
40
‚ƒ…„ †
‡!ˆ ‰ Š ‹Kˆ
are available, and we cannot use
However, since only values at
approximation method, the solution of the discretized state equation will be
for the bilinear
c‡ Œ  ‰ Š ‹Kˆƒ ‡cŒ  ‰ ŠŽ † ‡!ˆ ‰ Š ‘
which implies the application of forward Euler integration.
The bilinear integration method could of course be solved by modeling state
of
and
from the equation in Example 2, as
‡!ˆ ’ ‚ “
”K’ ‚ “
c‡ Œ  ’ ‚ “
as a function

– ” Šc—
c‡ Œ  ‰ Š ‹Kˆƒ ‡cŒ  ‰ ŠŽ †c‡!ˆ ‰ ŠŽ•  † r
This solution will generally require more state variables and the inputs to be available, and the
explicit representation of the state equations. These two requirements are generally difficult
to meet. If they cannot be met, it means that the simulation performance degrades.
In the preceding example, two requirements for solving the delay problem are highlighted. They
are:
1. All the state values and inputs need to be available, and
2. The explicit expressions for the state equations need to be known
In the case of the vehicle dynamics model of the VVSS however, we do not have the explicit
representation of the state equations since the model is non-linear. The conclusion is that the
parallel simulation of the states will demand the use of the Euler integration method for the
particular state. Only in some cases we could incorporate additional states and inputs to reconstruct
the expression for explicit bilinear integration, but this is generally not the case. The implications
for accuracy and stability of this conclusion will be discussed in Section 7.3.
5.4 Implementation through Indexing
The objective for parallel simulation through SPINE, is so that states or submodels of the vehicle
model can be selected and configured dynamically, without re-organizing the structure of the
vehicle dynamics model itself.
In other words, the system must be able to allow for any state at any given time, to be separated
from the model and be computed in a parallel process through SPINE. The methodology that has
been adopted to achieve this objective is called indexing, which makes use of a pointer table. The
pointer table in the application of SPINE will be referred to as index library ˜t™ š › . The method
has been widely used in computer science, in the application of interrupt handling.
The idea is that instead of the actual state values, a pointer is used in the state equations. The
pointer directs the simulation to the location of the state value. The computer science community
41
ž!¡
œt žKŸ ž¦¤ ¡¥
žK¤ ¡§
ž!£ ¡
..
œt .ž!¡ ..
œt ž!. ¢c Figure 5.4: Indexed states represent state values through indirect addressing. The library index
œt ž!¡ allocates the pointer £ž ¨ which is the index reference pointer for the actual state value ž!¡ .
ž¦¤ ¡¥ žK¤ ¡§
The contents of the pointer can be changed to reference another state value, for example or .
adopts the term indirect addressing for this method. This concept of pointer technology has been
adopted from the science of computer architecture, where an interrupt pointer table is used to
identify the locations of interrupt handler routines. The use of the index library is further explained
in Example 9.
In the application of the virtual vehicle system simulation, it means the following. As soon as we
would like to replace a state with the output of a parallel simulation, we will only need to change
the pointer for the particular state, to direct the execution of the simulation to the location of the
ž£
ž
new value. The notation is adopted to denote the pointer to the state value . The concept of the
state value pointer is shown in the diagram in Figure 5.4. The following example shows the use of
state pointers for a linear system.
EXAMPLE 7 Parallel simulation using state pointers.
Assume the linear integrating system in Example 1. The implicit state equations, using the
bilinear approximation method will now be expressed in terms of the state pointers.
© ¥ ª « ¬K¥­¯© ® ¥ ª «°± ² ³ ® «
© § ª « ¬K¥­¯© ® § ª «°´ ²µr¶ © ® ¥ ª « ¬K¥!°·© ® ¥ ª « ¸
© ¹ ª « ¬K¥­¯© ® ¹ ª «°º ²µ ¶ © ® § ª « ¬K¥K°·© ® § ª « ¸
³«
The input is considered to be a zero-order hold input for simplicity. By default the pointers
represent the location of the state value;
© ® ¥ ¶ » ¸¦¼ © ¥ ¶ » ¸
© ® § ¶ » ¸¦¼ © § ¶ » ¸
© ® ¹ ¶ » ¸¦¼ © ¹ ¶ » ¸
42
When we would like to replace the model for state
equation will be simulated in a parallel process, as
½c¾ , as in Example 6, the second state
c½ ¿ ¾ À Á ÂKÃį½cÅ ¾ À ÁÆÇ È½!Å Ã É
and the pointer to the second state will be changed to
½cÅ ¾ Ê Ë ÌÍ ½c¿ ¾ Ê Ë Ì Î
The initialization of a remote process through SPINE takes place when a state request form is
submitted to the VVSS. In the request form, the remote processor will list a set of state indexes
(See Section E.7) which it will need to receive, and a set of state indexes for which it will submit
values at each simulation interval.
After initilization, the computation of the vehicle dynamics model will use the values of the remote
process Ð
Ï Ñ Ò Ó , for the states that are defined in the submitted request form as outputs of the remote
simulation.
When the remote simulation terminates, it will close the SPINE connection with the VVSS. The
original state values will automatically be replaced in the vehicle dynamics model, and the pointer
ÐÔ Ñ Ò Ó will be restored to direct to the original state value. Details on the technical implementation
of the state pointer concept are explained in Sections E.2 and E.3.
Parallel simulation has also an impact on the remaining vehicle dynamics system as it is simulated
in the VVSS. Recall that state values are updated in each simulation before each integration step.
This means that during the update of the states Ð Á ÂKÃ , each value for Ð Á is available. Only if states
Õ and Ö are computed in the same process, and if Õ?× Ö , then the values for the states Ð Ø À Á ÂKÃ are
available to Ð!Ù À Á ÂKÃ for evaluating bilinear approximation. Otherwize forward Euler approximation
will be applied for evaluating Ð Á ÂKÃ .
It is therefore important to consider the dynamic behavior of the state values that will be replaced
in the vehicle model. The following example will demonstrate this case.
EXAMPLE 8 Implication for integration when simulating ½c¾ in parallel.
Consider the parallel simulation of a state in Example 6. The original system, using the
implicit bilinear approximation for internal state integration was described by
½!à À Á ÂKÃą½!à À ÁÆÚ cÈ Û Á
½c¾ À Á ÂKÃą½c¾ À ÁÆÜ ÈÝ Ê ½!à À Á ÂKÃ!Ɛ½!à À Á Ì
½ Þ À Á ÂKÃą½ Þ À ÁÆß ÈÝ Ê ½c¾ À Á ÂKÃKƽc¾ À Á Ì
ÛÁ
The input
is again considered to be a zero-order hold input. By simulating the equation
for
in a parallel process, we cannot longer use
for computing
, nor
for
. The following table shows how the equations of the system approximation are
½c¾
½ Þ À Á ÂKÃ
½!Ã À Á ÂKÃ
½c¾ À Á ÂKÃ
½c¾ À Á ÂKÃ
43
changed. The table is chronologically, in that is shows the exchange of state values, then the
evaluation of the models in the main system (left) and the subsystem (right) for the integration
.
step at time
àá…â ã
ä
àá…â ã
àá…â ã=íã
å cç æ è é ê
ç!ë é ê !å ì
ç!ë é ê îKë á ç!ë é ê íï ãcð ê çcæ è é ê îKë á cç æ è é ê íñ ã ç!ë é ê
ç ò é ê îKë á ç ò é ê íó ã çcæ è é ê
(In case this document is in color, the equations for the states that are computed remotely
are printed in red.) Alike in the preceding examples, the original system with bilinear
approximation could be modeled, as the following set of explicit state equations
ä
àá…â ã
àá…â ã=íã
å cç æ è é ê
ç!ë é ê ð ê å!ì
ç!ë é ê îKë á ç!ë é ê íï ãcð ê
cç æ è é ê îKë á cç æ è é ê íñ ã ç!ë é ê íï ñ¦ô è õ ð ê
ç ò é ê îKë á ç ò é ê íó ã çcæ è é ê
íOñ ó ô è õ ç!ë é ê íï ñ ó ô ÷ ö ð ê
if they are available. This explicit form would not require a change of the integration method.
The original system for the VVSS however, is not explicitly available in the bilinear approximation expressions.
Implications for the stability of the system as a result of switching integration methods are discussed
in Chapter 7. Besides the change in integration scheme there is another important consideration
for using SPINE to simulate subsystems. In Chapter 6.4 the timing aspects of the total simulation
and animation will be discussed. In the aim for real-time simulation there are two parameters that
can be tuned for optimized performance. They are the frame-rate ø and the subsampling factor ù .
The consideration here is that communication for data exchange on SPINE takes place only once
per frame. Hence, the more integration cycles in a frame (hence, the higher the number ù ), the
larger the integration interval for the state that is to be replaced.
In order to administer replacements in the state variable pointer, a library index has been defined
with the locations of the pointers to the actual values.
The index library ú is a table which holds the pointers to the pointers ü û , which on their turn locate
the current state value for ü . The contents of the index table ú can be found in Appendix E.7. In
order to be consistent throughout the modeling, reference to state variables and parameters must
always be made through the pointers ü û . The following example will be used to demonstrate the
use of the pointer table.
EXAMPLE 9 Replacing the model for braking (simple ABS)
44
A simplified model for ABS brake logic is presented as an example on how to use SPINE to
replace a partition of the vehicle dynamics. The brake system computes a brake torque ,
based on the brake pedal angle . When the longitudinal vehicle speed is 10% larger than
(spin times effective radius) than the brake torque will be minimized.
the wheel travel
The actual model for the brake torque is not of interest in this example. We will assume
ýcþ
ÿKþ
ýcþ ÿKþ The diagram for the brake model is as follows.
Brake Logic
ÿKþ
þ
ýcþ
In the index library in Tables E.3 and E.4 of Appendix E we find the indices for the following
pointers as
! #" ÿK þ ýc þ ! #$ For implementation of this example it means that the first string will contain the indexes with
a terminating character,
102 202 105 205 2 -160 -260 *
The VVSS will respond by sending the values for the requested states. Realize that pointer that consists of three values. For example,
is is a
12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 *
From then on, the VVSS only expects the value of the states that will be sent from the remote
process (the two brake torques ! ).
ýcþ
0.0 0.0 *,
and the VVSS will respond by sending the values for the requested states as before. The
process will continue until the connection closes. The VVSS will then restore the pointers for
the torque to the refer to the original torques.
The process can be depicted in the following chronological order of tasks
45
root
Viewpoint
Vehicle
Light
World
Figure 5.5: The simplified model of the underlying tree structure that represents the graphic virtual
scenery
Time
%&' (
VVSS
Values of Requested states
%&' (-,#(
12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 *
Values of Requested states
%&' (-,#. (
12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 *
Values of Requested states
%&' (-,#/ (
)*
Submodel
Request form of indexes
*+
102 202 105 205 2 -160 -260 *
)*
*+
)*
Simulated state values
0.0 0.0 *
Simulated state values
*+
0.0 0.0 *
12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 *
..
.
5.5 Virtual Environments
A powerfull feature for the VVSS is that the virtual sceneries, and therefore the simulation scenarios
are uncoupled from the numerical simulation. It is possible to configure the VVSS to load different
virtual scenes, so that the simulation can be used for a slalom test, an icy slope, for uneven pothole
or ditch terrain driving or even for multi-vehicle traffic simulation.
Furthermore, the VVSS can be configured to run any platform vehicle. This allows us to simulate
a sports car, and compare performance with for example a HMMWV 0 in the same experiment. Or
in another scenario, compare drivability of an armored Dodge truck with an armored HMMWV.
These examples of applications are not random. Oakland University faces many opportunities to
conduct research in these areas. The VVSS will be facilitated to comply with specifications of any
1 A High Mobility Multi-Wheeled Vehicle (HMMWV), generally called “hummer” is an all-terrain all-purpose
military utility vehicle. The US-Army maintains approximately 500,000 of these vehicles.
46
Figure 5.6: The virtual environment can be adapted to meet the requirements of any intended
study.
of the required studies.
In an overview of the variety of applications that VVSS can have, the next list is a collection
of examples of modules that can be implemented for the VVSS. The VVSS has the default
configuration as shown in Figure 5.6 with a Lotus Esprit, in a village landscape.
5.6 Modules for Subsystems
As the application for VVSS, the PC’s that are connected to the VVSS can be used for detail studies
on subsystems. During the studies, an engineer can simulate concept models, run test scenarios
on a selected virtual test track, or actually drive a virtual vehicle, that is “equipped” with a concept
system.
The following is an overview of submodules that can be developed as extensions to the VVSS.
Suspension The suspension module can be replaced, to account for a more accurate description
of the mechanical behavior in a certain car. In particular this module can be replaced with a
concept active suspension 2 system. For example in the tutorial by [17], the active suspension
can be implemented and tested.
With the facility for VVSS, future research activities like [7] can be evaluated in an interactive
simulation environment, before heading to a test-track facility.
3 The objective for Active Suspension is to minimize the sprung mass acceleration with constraints on the suspension
deflection and road holding. The desired dynamics of the system is that of a passive suspension with “skyhook damping”.
47
Steering System More accurate steering dynamics (See also Appendix A) can be simulated by
developing a steering module. A steering module can be modeled for steering complience,
electronic steer by wire, or to do more detail studies on noise vibration and harhness (NVH)
characteristics of the steering models (for example, see [58], [52], and [53])
Tire Friction The tire friction dynamics model as it is implemented, is presented in Chapter 3.2.
However, as was explained in the introduction of this proposal, that also other efforts have
resulted in reasonable models for tire dynamics. A tire friction module can be implemented
to study other friction models and support the effort for more accurate characterization of
tire models.
Free-Body A custom free-body model can be inserted in a situation where the vehicle platform
cannot be represented by the presently implemented chassis model. A set of dynamic
equations for a chassis, implemented as a submodel enables any vehicle platform to be
simulated with the VVSS.
Engine-Transmission Studies on engines or transmissions can be conducted using the VVSS. A
model for an engine (for example, diesel injection engine or electric motor) or a transmission
(hybrid vehicle or continuous variable transmission) can be inserted as a module that replaces
the current generic model (see Appendix A).
Traction Control Previous studies at Oakland University on traction control can now be conducted
with the VVSS by replacing the traction module in the VVSS. (for example, Hydro-lock by
Dana Corporation)
Brake Systems Driving scenarios with advanced brake systems can illustratively be simulated
using the VVSS, by replacing the current brake system with an ABS, or brake by wire.
Advanced Controls Recent studies on driving safety have spawned many concepts for vehicle
stability controls. Control systems for diagonal braking, or combined braking and suspension
forces [2] can be evaluated by designing a module for the VVSS. Or control systems for multivehicle scenarios, like the leader-following project that Oakland University was involved
with (See [10], [14], [11]), can be simulated in a virtual realistic environment, using the
VVSS.
Collision Avoidance Previous work at Oakland University for the US Army has been conducted
in a contract to develop a collision avoidance and traffic monitoring system for a HMMWV
(See [48]). Especially safety systems like collision warning and avoidance are investigated
recently [63]. The VVSS enables these traffic safety systems to be evaluated, in a multivehicle traffic environment, using adequate sensor models.
Navigation Systems The graphical interface and terrain models in the VVSS can be addressed
to study control concepts for GPS and advanced navigation systems. Solutions for deadrecogning and signal filtering can be studied when a suitable model is developed for a module
in the VVSS.
48
5.7 Conclusion
The SPINE simulation network configuration has been introduced in this chapter. The application
of pointer addressing of state values, for the purpose of a flexible reconfiguration of the dynamic
model is new and allows for the setup of the general multi-CPU parallel simulation structure.
This chapter discussed the impact on the simulation performance and in particular on the integration
method in detail. The problem is that the separation of the model into different computer environments forces the integration of states to utilize the forward Euler approximation method. The
effects on accuracy and stability that are implied from the change to forward Euler approximation
are explained in Chapter 7.
Chapter 6
Timing and Synchronization
The issues of real time with respect to integration step size and communication delays are addressed
in this chapter. Integration step size requirements are inferred from the frame rate and the execution
performance of the computer hardware. A Luenberger observer is introduced that will predict
simulation output from a parallel subsystem on SPINE, when it does not respond in time.
6.1 Introduction
At this point we have developed a full vehicle dynamics model and a methodology for simulating
partitions of the model on different processing units via SPINE. As was illustrated in Figure 2.1, the
objective of virtual vehicle system simulation is to simulate the closed loop model which includes
the human driver in the loop.
The interface between the vehicle dynamics model and the human driver has not yet been discussed.
Therefore, this significant aspect of the system will be addressed in the first section. Then the
requirements and trade-offs for the system for executing in real-time will be addressed.
If one of the processing units in SPINE is not able to compute its simulation output and return it
to the VVSS host in real-time, the system could become unstable or generate unreliable output.
This problem will be addressed in Section 6.4, and a suitable solution to resolve it is presented in
Section 6.5.
6.2 Human-in-the-loop Model
Since world war II, studies have been conducted to model human behavior as an active feedback
control device. Several frequency domain methods have been published [45]. When time-domain
control synthesis techniques became popular, an optimal control model (OCM) for the human
operator was introduced [33]. The diagram of this model is shown in Figure 6.1.
49
50
disturbances
Human Operator
+
8ν
5Delay
y
Observation noise
6Estimator
Corrector
7
Feedback
Gains
+
8ν
Neuromotor
Dynamics
u
δ
4
Virtual
Vehicle
System
Simulator
9y
Observation noise
observed variables
Figure 6.1: The Optimal Control Model (OCM) for the human operator.
Different models for the human operator have been designed, depending on the particular application [25]. Through experimentation and identification [26] an average time constant of 0.15
seconds has been found for the neuromotor dynamics first order characteristics. This result allows
us to conclude that an average data input rate of at least 15 Hz (less than is used for the visual
output), will be sufficient to aquire human output data.
Obviously, this assumption is based on the average human response time and general applications
for driving simulation. When for example, performance vehicles like the Formula-1 race cars,
with proffesional drivers are to be simulated, this OCM may have to be modified to reflect the
appropriate responsive model. At this time we will assume the OCM to be sufficient : , leaving the
reader with the remark that numerous research efforts are being conducted to characterize human
responses in various scenarios.
6.3 Real time versus Simulation time
The term “real time” was defined in the context of simulation in the introduction on page 3. In this
section we will study the constraints for the integration process of the vehicle dynamics in order
to meet the objective for real-time as stated.
The vehicle dynamics model is simulated in a Silicon Graphics ONYX-II computer with 4 processors and reality engine graphics boards. The timing event for the visual output is generated
by the hardware of the computer. This timing facility will be used as a reference to real-time. The
hardware can be configured to generate a particular frame rate (i.e. 72, 36 or 24 Hz), and how to
operate this frame rate ; .
Figure 6.2 shows the profile of CPU utilization during a real simulation. The activity of CPU 4
is plotted at the line app. The graphics culling, database management and computing viewpoints
is executed on CPU 2 (repectively called cull, dbase and compute). the actual drawing of the
scenery is done by CPU 1 (task draw). In Figure 6.2, each color represents an individual simulation
< The human response model will have to be revised when the motion platform is installed, and when force and audio
=
feedback are added to the human driver environment
For the operation we can select from FREE RUN, PHASE LOCK, or PHASE LIMIT. The latter setting is used for
the VVSS.
51
interval. For example, the interval with the white color will start by calling the application in CPU
4. It will pass its state information to the culling and database process in CPU 2 and 3. On their
turn, they will pass their outputs to CPU 1, for the drawing task. However, as soon as data is passed
from CPU 4 to the culling and database processes, another simulation interval will be computed
in CPU 4, indicated in yellow. It will be the objective to fully exploit CPU 4.
During each frame, a minimum number of tasks needs to be completed by the processor that
computes the vehicle dynamics. Chronologically they are:
1. Compute the next state of the vehicle dynamics.
2. Update states from the vehicle dynamics which are animated in the animation to the graphic
scenery rendering processes in CPUs 1, 2 and 3.
3. If there is data ready from SPINE in the network connection buffer, then
(a) receive the data from the buffer. Interpret the input and insert the new values for the
states into the vehicle dynamics model,
(b) compile a set of current or future state values for the remote processes and pass them
to the transmit buffer for SPINE.
4. Process keyboard and mouse inputs, and optionally receive peripherals for vehicle dynamics
inputs.
5. Wait for the next frame rate synchronization > .
Figure 6.4 shows a conceptual timing chart for the simulation. Vertically it displays the time
in video frames. Typically CPU 1...3 will be dedicated to processing graphics. CPU 4 will be
assigned to computing the vehicle dynamics and communication with the SPINE.
As was eluded to before in Section 4.1, the selection of sampling time is critical with respect to
convergence and real-time. In order to get more freedom for the selection of integration step size,
we will apply subsampling for the evaluation of the vehicle dynamics.
Subsampling means that for task 1 in the above task list, the output for the vehicle dynamics model
will be integrated ? times, using a sub-sampling integration step size @BA . The result is a frame rate
integration interval of
@[email protected] F
(6.1)
The actual duration of one frame, hence one total simulation interval, depends on the selected
video frame rate,
GH C J I
J
=14, 24, 36, ... 96 Hz
K Task 5 only applies for the selected timing operation property.
(6.2)
52
Figure 6.2: Snapshot of the VVSS simulation output with online statistics. Each color represents
the execution of an individual frame. Each row represents a processing unit.
53
Real Time Integration Step Size for Various Frame Rates
0.02
Frame rate (Hz)
0.018
14
18
24
36
48
60
72
Capacity
Integration step size (s)
0.016
0.014
0.012
0.01
0.008
0.006
0.004
0.002
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Subsampling (n)
Figure 6.3: Minimum integration interval selection for real-time simulation.
It is now important to guarantee that execution of the task list (Tasks 1...4) will not exceed LM
seconds. Denoting the time that it takes for the computer to execute Tasks 2...4 by N O , and the time
that it takes to compute one iteration step of the vehicle dynamics model by N P , this requirement
can be expressed by Q
N ORSTN P-ULM
(6.3)
At the same time, we must guarantee that the simulation of the vehicle dynamcis will evaluate a
total amount of LM seconds per frame, in order to be real-time. In other words,
V
PW L S M
(6.4)
From the above discussion, the maximum constraint for real-time simulation can be expressed for
V P in terms of the time that it takes to execute the task list,
V
PX N OYRZS STN P
This constraint is graphically represented in Figure 6.3, for several values of [ , where for N
(6.5)
OWE\ ] \ \ ^
_ The requirement in Equation 6.3 applies to the sequencial processing of the simulation of the vehicle dynamics.
54
Silicon Graphics ONYX
CPU 1...3
CPU 4
TCP Buffer
SPINE
Buffer
t=kh
Video Frame 1/36 sec.
1 Vehicle Dynamics
Read Peripherals
(optional)
`n Vehicle Dynamics
Read new data
Send current data
Process Mouse and Keyb
1 Vehicle Dynamics
State Update Information
Video Frame 1/36 sec.
Video Frame 1/36 sec.
d
Current State Information
(data request)
d
(data reply)
Read Peripherals
(optional)
Send to VVSS
Wait for data
Receive new data
Computing
states and outputs
of the submodel
(i.e. in "Simulink")
a
b
n Vehicle Dynamics
Update Graphic States
if new data in Buffer:
Read new data
Send current data
Process Mouse and Keyb
1 Vehicle Dynamics
t=(k+2)h
t=(k+3)h
(i.e. in "Simulink")
Graphic States
bifUpdate
new data in Buffer:
t=(k+1)h
PC-Pentium / DSP
Receive new data
Computing
states and outputs
of the submodel
d
Current State Information
(data request)
State Update Information
(data reply)
Read Peripherals
(optional)
c
`n Vehicle Dynamics
Update Graphic States
if new data in Buffer:
Read new data
Send current data
Process Mouse and Keyb
1 Vehicle Dynamics
Send to VVSS
Wait for data
Receive new data
Computing
states and outputs
of the submodel
(i.e. in "Simulink")
Current State Information
(data request)
Send to VVSS
Wait for data
State Update Information
(data reply)
Receive new data
Computing
states and outputs
(i.e. in "Simulink")
Figure 6.4: SPINE communications timing diagram. The vertical axis represents time. The left
column represents the VVSS, the right column a parallel simulation process in Simulink. The
arrows between the VVSS and the Simulink denote data exhchange of state values.
sec, e fhgEi j i i k l sec, which are realistic estimates. For example, the VVSS is currently configured
for mBfgni j i i o sec, and p#gnq at 36 Hz. If it was desirable to decrease the integration step size,
we would need to lower the frame rate to 24 Hz, and use for example mBfgEi j i i r s sec at pTgnt k .
The same idea applies to the modules. The sub-systems could be evaluated in a smaller integration
step-size. The module will be integrated for the respective number of times, before actually
communicationg with the VVSS. The advantage is that more accuracy or stability at greater
stiffnesses can be achieved. That is, if the processor can perform the higher integration frequency
in real-time.
55
6.4 Communication and Synchronization with SPINE
Section 5.4 explained how remote simulation through SPINE is organized. The preceding section
argued, that the VVSS must keep in pace with the frame rate timing event, in order to maintain
real-time simulation results. A problem arizes when an update for the state values from a remote
simulation process does not arrive in time. The timing diagram in Figure 6.5 illustrates this
particular scenario.
Consider the system outputs at time uvxw . The computation of the system outputs in y requires
the previous system states z{ | } ~B{B   z € | } ~B{ and the outputs of the remotely simulated states z  ‚ | } ~B{
to be available. However, the remote processor was not able to provide the states in time for the
communication checkpoint.
In this case, the VVSS will effectively use the latest values for z  ‚ for for simulation, eventhough
they are outdated. This method acts like a zero-order hold “prediction” on the state values. A
stability problem occurs when this integration interval becomes too large for the solution of the
simulation to converge.
A secondary effect is that the accumulated time in the remote simulation will no longer synchronize
with the accumulated simulation time in the VVSS.
The implementation aspect of SPINE concerns with the network linkage between the processing
units. A 100 base-T local network interconnects the units by means of a HUB. The simulation has
shown to suffer under heavy network traffic, although this problem can easliy be eliminated, by
disconnecting the local network from the internet backbone.
Furthermore, the simulation applications on SPINE will communicate through a network adaptor,
which will allow them to use buffered communication. The adaptors will then independantly
perform the handshaking and protocol tasks to exchange data. Latency and transmission times
are marginally if not degrading the performance of the simulation, and are therefore not further
discussed in this dissertation.
6.5 Prediction and Correction with Luenberger Observer
A more sophisticated method to solve the problem from the preceding section, is to try to use
predicted outputs of the remote simulation, when the values for the states do not arrive in time.
Several schemes are available to implement this method.
The mechanism is generally referred to as an observer [20]. An observer will estimate the state of
the process, based upon the observed output. The concept of an observer was introduced in 1966
by Luenberger [42].
The generic “Luenberger observer”, however, appeared several years after the Kalman filter, which
is in fact an important special case of the Luenberger observer - an observer optimized for the
noise present in the observations and in the input to the process [4]. Kalman filtering technique
was successfully used for tracking application at Oakland University before in [48].
56
Simulation execution
Communication checkpoint, exchange state values
x1,k-3
o
xn,k-3
o
x1,k-1
xn,k-2
prq
k-3
x1,k-2
o
xn,k-1
~
xp,k-2
prq
k-2
k-1
o
x1,k
x1,k+1
xn,k
xn,k+1
prq
~
xp,k-1
~
xp,k
Time (T s)
k+1
k
Figure 6.5: Timing diagram in the scenario of synchronization failure.
The design of observers and extended Kalman filters for non-linear systems has been addressed by
several authors, such as Thau [62] and Kou et. al. [36]. At the same time, it has been proven that
one can simplify the estimation of complex non-linear system states via the use of the so-called ƒ ,
ƒ„… , or ƒT„…„† tracker formulation [39]. New techniques for neural networks could possibly
be used for this application [61].
Generally the Kalman filter assumes the structure of the observed system to be known in advance.
With the input measurement ˆ ‡ ‰ , the real-time estimation ‹ Š ‰ ŒB of the state ‹ ‰ ŒB , and the predicted
result Ž Š ‰ by the observer is
‹ Š ‰ BŒ E
Ž Š ‰–•
‹ Š ‰h‘Z’ ˆ ‡ ‰‘“D‰ ” ‡ ‰
‹Š ‰
(6.6)
(6.7)
where the term “ ” ‡ ‰ is the correction term, based on the error between the current output observations Ž ‡ ‰ and the predicted output;
” ‡ ‰— Ž ‡ ‰ „ • ‹ Š ‰ ˜
The formalization of the optimization problem for choosing
will result in the cost functional
™ Eš
(6.8)
“D‰
that will minimize the error
›xœ ž ¡
 ž Ÿ ” ‰£¢ Eš–¤ ” ¥‰ ” ‰¦–§ ¨ª© š–¤ ” ‰ ” ¥‰ ¦B«—˜
‡ ‡
‡ ‡
 ‡
”‡ ‰
,
(6.9)
The last term in the above expression has a physical meaning. It represents the sum of the variances
šD¬ ” ‡ ‰ ­ for each state. The solution for the functional in Equation 6.9 results in a discrete-time
57
algebraic Ricatti equation ® ,
²
¯° ±B²³E´-¯° ´hµD¶·¸°—¹º´-¯° »µT¼ »ª¯° »µD¶½—° ¾ ¿ ª
» ¯° ´hµYÀ
¯° ±B²
½—°
(6.10)
The solution
represents the covariance matrix of the estimation error,
the measurement,
·¸° is the excitation noise. The new correction gain isisthen
or observation noise and
given by
²
ÁD° ±B²³E´-¯° ±B² »µ¼ »ª¯° ±B² »µD¶Z½—° ¾ ¿ À
´
(6.11)
From Equation 6.6 it can be seen that the transmission matrix must be known in advance and that
the estimates will converge to reflect the measurements in the predicted output. These properties
Á
are in fact characteristic to the filter. The bottleneck is that for finding , we need to have
statistical data on the state measurements and the noise. However, these statistical data are usually
not available.
It is insightfull to step away from the prediction correction technique and realize the timing problem
of the VVSS that we face. That is: when an output value of the remote process arrives in time, it
will be assumed to be error-less (i.e. no measurement noise), and the value will be used to estimate
the prediction model parameters and predicted state values. If the output value does not arrive in
time, the current state of the model will be solved to derive prediction of the value.
In second consideration we must realize that the measured values will typically not reflect the
output of a linear time-invariant system. This means that simply solving a least squares problem
will not necessarily guarantee an accurate estimate. It is therefore important to select a system that
contains sufficient dynamic behavior to track the observed signal and which has enough system
parameters to correct the behavior to make it track appropriately  . A general second order linear
system will thus be used for predicting the observed signals, since it will naturally predict the
dynamic behavior of an unforced mechanical system.
From the above discussion, the following two tasks can be defined. Take for example the linear
system
Ã
Ã
Ã
°Ä ±B²³E´
È °—³–»
then for each time step Ê
³EË Ì
Ã
Ä h° ¶ZÅÇ Æ °
Ä°É
(6.12)
(6.13)
,
Í Jacopo Francesco Ricatti (1676-1754), Italian mathematician, who first introduced his equation in 1723. A general
ÏYÐ—Ñ£Ò Ó Ô ÏhÕTÖ Ò Ó Ô Ï ×ÐªØ£Ò Ó Ô .
form
Ù of the Ricatti equation is Î
If the internal model structure would not be known, but we have observations of the internal states and inputs, then
the system matrices could be directly found at equilibrium from the Jacobeans
Ú ÕÛBÝ Ü Ò Ó£Ü Þ ß Ü Ô
à ÕÛ
Û Óá
Ü
â Ü Ò Ó£Þ ß Ô
Ü Ü
ÛBß Ü
58
ï ñ . If no observation of the output signal is
1. Predict the new system output ä ã å æBçè–éê ë ì ã å íDîð
available, this prediction will be used in the next integration step of the vehicle dynamics. If
initially the system has not yet been defined (before the first correction) and the observation
would not be available, then the zero-order hold function will be applied ( ä ã å æBçè ä ã å ).
2. If a series of ò observations of the output is available, then reflect the recent history of
observations in the prediction model. In other words, solve for the state vector from the
error in prediction and observation of the output ä å£óä å æBç ó-ô ô ô óä å æ£õ öBç .
The prediction model will have to have a structure that will allow the state vector to be solved.
This required property is in this situation usually referred to as observability .
The following two examples are used to illustrate the above concept for predicting and correcting.
The first example will show the application of an observable system. The second example shows
how a general linear second order system is used as a predictor-corrector.
EXAMPLE 10 Second order observable prediction model.
Suppose we assume the following second order linear system for tracking the output signal of
÷
÷
the remote process on SPINE.
ç þ ÷ ø å ç åø æB÷ Yç ùûúªühý ÿ
ú
å
ühý
ù þ ø å
å-
(6.14a)
(6.14b)
which has, what is called the observable canonical form. Realize that a system with this type
ç ý õ and ç õ that define its state
of canonical form always has variables ý
space model.
With recent observations
also the excitations as
å å æ£õ öBç , define the expressions for the observations ù å
å æBç
..
.
ù å
å æBç
..
.
, and
å æ£õ Bö ç
å æ£õ ö
We can show that
ù "! ø å$# ! # % and the observability matrix "% are given by
where the Markov matrix
- ..
)
- ..
.
..
!
,
)+*
)+*
.
# %hù&''
"
% ù0&''
..
..
..
..
''(
''(
.
/
/ .õ ö ,
.! ,
.
)+*
)+* õ öBç
)+*
(6.15)
(6.16)
(6.17)
59
:9
23
-
;>=
7
1
2
1
;<
7
56
+
8
7
4
Figure 6.6: Example of a second order linear system for predicting state values.
Notice that ?"@ has full rank by definition of observability, and will be square for A observations
8 9 . From the relationship in Equation 6.16 we solve for ; B as
=
;+
B C ? EG
D F 8I9 HKJ E : 9 LNM
7
(6.18)
; B O P =QCSR P D = ; BTVU W"RWM M MXR P D < W>Y :N9 M
7 D
7
(6.19)
Using the system dynamics Equation 6.14, we can show that
EXAMPLE 11 A general second order linear observer predictor system.
Assume the strictly proper general second order linear system in Figure 6.6, for tracking the
simulation output data from SPINE. Which is given by the state space system representation
3
H 4 ;+Ta[ 1 : 9
; Z C\[ H ^
(6.20)
1
]`_
]b_
7
7
8cCd
(6.21)
6 e ;
"
7
This system can be discretized and approximated
for numerical simulation using the bilinear
5
transformation. This transformation results in a set of equations as in 6.12 and 6.13 where
with integration step size f we find
3
3 T 4 < Hlk
f <
Hj f
RC0ghi j 3 f T k 4 f Tbk
4 f f < Tbk
T
f
j
3
3
H
j3 f f H T
j T
j f
mn
k4f
<
4 T k
4 f f < T
k o
4 f < Tk
(6.22)
60
|}
pq0rst v w x+yv zu x x{Xy
~
v w x+yz x{Xy u
u
 q€cƒ‚"„
(6.23)
(6.24)
For this discrete time system to allow itself to be corrected with the observed data, we will
have to be able to reconstruct its states from the system output data. Furthermore, we need
a minimum set of variables in the system matrices, to be able to find an explicit and nonambiguous expression for the model correction. As a result, the above discrete time system
needs to be transformed to the observable canonical form.
The canonical observable form has a particular property. The eigenvalues of the original
qŠ ) will be the elements in the first column of
system (that is, the solutions of det … †‡Iˆ‰+…
the transformed transition matrix ‰ ‹ .
The necessary requirement for this transformation to succeed is that the observability matrix
(Eq. 6.17) be non-singular. The transformation will then convert the system to be expressed
q$  Œ . The following system is achieved
in a new coordinate system  Œ Ž with  Œ
 Œ Ž ‘N’ q ‰ ‹  Œ Ž y p”‹ • “ Ž
–Œ q  ‹ Œ Ž
(6.25)
(6.26)
with
 ’™˜
ˆ
\
q
—
‰‹
ˆ  { Šbš
‚’
p
\
q
—
‹
‚{ š
 ‹ q€ ˜ Š „
(6.27)
(6.28)
(6.29)
The transformed system has the observability matrix
›"‹ œqž—Ÿ ‹
 ‹ ‹‰ š
qžI ’ ‰ 
Since with the coordinate transformation, ‰ ‹
›"‹ œq ›"œ  and hence, Kq › ‹ œ ’ ›"œ .
(6.30)
and
 q  
‹
, we can find that
The transformed system can now be corrected as in the previous example. After the correction
procedure, we can find the correction for the original system, using the reverse transformation
61
¡S¢£¡ ¤I¥N¦
§ ¢$¤ § £ ¤ ¥N¦
(6.31)
(6.32)
The process is somewhat elaborate but will allow any linear strictly proper model to be used
for tracking.
Next is the third and final example of implementing a linear tracking system, now in a least-squares
formulation. From Example 10 we conclude that the practical objective of the observer-predictor
scheme is to adjust the system parameters and internal states, based on the recent values for ©>¨ ª
and « ¨ ª , such that the linear system will predict the next state output « ¨ ª ¬ ¦ as accurately as possible.
In the next example, the tracking system in Equations 6.14a and 6.14b is reformulated to realize a
least-squares observer-predictor.
EXAMPLE 12 A second order observer-predictor system with joint state parameter estimation.
With the objective in mind that the state parameters will be adapted to track and represent the
observed dynamics in ® ­ and ¯ ­ , the change of the system can be formulated as
° ¦ ±ª ¬ ¦
° ´ ±ª ¬ ¦
µ ¦ ±ª ¬ ¦
µ ´ ±ª ¬ ¦
¢ ° ¦ ±
ª ²K³ ¦ ± ª
¢ ° ´ ± ª²K³ ´ ± ª
¢Sµ ¦ ± ª²K³”¶ ± ª
¢Sµ ´ ± ª²K³”· ± ª
(6.33a)
(6.33b)
(6.33c)
(6.33d)
³”º ª » ¢
±
0. Also, by
where, with ideal tracking the expected noise or shaping inputs ¸¹
¯
ª
¬
½
¦
substituting 6.14b into 6.14a, the following expression for ¼
can be formulated
¾ ½ ª
¦±
½´ ± ª
¬ ¦
¬ ¦À¿
¢
¾ÁÃÂ
ÁŸÁ
¾ ½ ª
¾
¾ Ä
¦ ± ² µ ¦ ® ª² Ä ° ¦ ¯ ªÅ
µ´ ¿ ­
°´ ¿ ­
¿ ½´ ± ª ¿
(6.34)
The set of states and parameters at a given point in time can be concatenated in a vector and
expressed with the above equations. As a result, the following least-square problem is found
ÆÇÇ ½ ª ¬
ÇÇ ½´¦ ± ª ¬
ÇÇ ±
ÇÇÈ ° ¦ ± ª ¬
° ´ ±ª ¬
µ ¦ ±ª ¬
µ ´ ±ª ¬
É Ê ÆÇ
¦ ÊÊ ÇÇ
¦ ÊÊ ÇÇ
¦ ÊÊÊ ¢ ÇÇÈÇ
¦
¦
¦ Ë
ÁÃÂ
ÁŸÁ
ÁŸÁ
ÁŸÁ
ÁŸÁ
ÁŸÁ
Ä ¯ª
Á
­ÁÌÄ
¯ª
ÂÍÁ ­
ÁÏÂ
ÁÐÁ
ÁÐÁ
®­ ª Á
Á ®ª
Áέ Á
ÁÎÁ
ÂÑÁ
ÁÒÂ
É ÊÊ ÇÆÇ ½ ª
ÊÊ ÇÇ ½´¦ ± ª
ÊÊ ÇÇ ±
ÊÊ ÇÇÈ ° ¦ ± ª
° ´ ±ª
Ë µ ¦ ±ª
µ ´ ±ª
É ÊÊ
ÊÊ
ÊÊ
Á
ÇÇ
ÇÇ
ÆÇÇ
É ÊÊ
ÊÊ
Á
ÊÊ ² ÇÈÇ ³ ¦ ± ª
³ ´ ±ª
³”¶ ± ª
Ë
³”· ± ª
ÊÊ
Ë
ÊÊ Å
(6.35)
62
In vector-matrix expression, and with zero-mean inputs ӔÔ
expressed as
xÖ
¯
×NؔÙ$Ú x¯Ö Û
Ý Ü Ö Ù$Þ xÖ
¯
ÕÖ
, the system in Equation 6.35 is
(6.36)
with ÞSÙß àáIáIáIá+á
âã
(6.37)
The inversion is only possible when the observability matrix has full rank, i.e. when the
system is observable. This will be the case only, when the observations for å ä and Ý ä contain
exciting data. Then the values for æ Ø and æ ç will appear in the above expression and can thus
be solved. If the system is observable, we find the solution for the state values and system
parameters by solving the expression
èé
èé
éé
ê
éé
ì íí
é ÝÖ
Ý Ö ×NØ
íí
..
.
î
Ý Ö ×>ë
é
Ù
ê
Þ
Þ Ú
+
..
.
Þ+Ú ë
ì íí
î
íí
Ü
xÖ
¯
(6.38)
to the solution for xÖ in the inverse observability matrix and recent observations,
¯
Ü
xÖ
¯
Ù ï ñ ð Ø yä ã
(6.39)
¯
6.6 Conclusion
In this chapter we have formulated the requirement for the integration step size for the vehicle
dynamics simulation to perform in real-time. The concept of subsampling has been introduced to
allow some freedom in the selection of the simulation integration step size, so that also the stiff
subsystems will render stable solutions.
Also the interaction of the simulation of the vehicle dynamics model and the simulation of a
submodel has been discussed. Stability and accuracy problems may arise for simulating the
vehicle synamics model when a remote simulation process on SPINE cannot provide simulation
results in the required frame rate. Several obserber-predictor schemes have been presented to
extrapolate simulation output values in this situation.
The effects on stability of the simulation of the vehicle model and accuracy of the observer and
predictor outputs will be further discussed in Chapter 7.
Chapter 7
Stability
Several aspects of stability that play a role in the simulation model are studied in this chapter.
Stability is considered in three ways: stability of the open-loop dynamic vehicle model, stability
of the integration method and stability of the human-in-the-loop vehicle model. Stability criteria
are posed, however a closed form expression cannot be derived. Also the stability and accuracy
aspects of parallel simulation through SPINE are addressed in this chapter.
7.1 Introduction
The study in this chapter relates to the origin of the stability problem itself, which is to test for
convergence of the system solution for frequency and magnitude bounded input signals. The
discussion is broken up in three sections, regarding system related, simulation technique related,
and vehicle dynamics (and control) related aspects of stability.
7.2 Model Stability
There are many methods for testing system stability. Most of the profound methods however,
apply to linear time invariant systems. The non-linear methods tend to be very conservative, as do
the linearized models.
Since the dynamic model of the VVSS contains many non-linear relations, many of the standard
classical methods for testing stability cannot be applied. Many methods for non-linear systems
(like Hyperstability by Popov [37] and Karithonov [46]) only apply for systems that do not have
internal state products. Lyaponov stability theory can be used to analyze non-linear systems.
However, application of these very general methods is often limited by finding suitable Lyaponov
functions. Special cases of Lyaponov functions exist for non-linear processes, but the results are
typically not usable, since the functions only satisfy the sufficient conditions and not the necessary
63
64
conditions.
Necessary and sufficient tests do exist for systems with arbitrary non-linear, arbitrary fast linear
time varying, or arbitrary slow linear time varying system parameters. Tests for these systems can
be calculated in polynomial time [6].
In this section, we will study the stability of the different subsystems in the vehicle dynamics
model. The closed-loop stability problem for driving will be discussed in Section 7.4. In the next
paragraphs, each subsystem that contains a feedback loop will be tested for stability.
Quarter Car Suspension
It was explained in Appendix A that the suspension and tire deflection model depends on the
suspension anchor locations ò+ó . Since the anchor locations depend on their turn on the suspension
model, there is notice of an internal time-varying feedback loop.
The loop can also be observed from Figure A.9. To study the stability of the double springdamper system in the quarter car suspension configuration, consider the model in Figure A.8
with spoke angle ôaõ÷ö for corner ø . If we take for the vehicle anchor elevation above the
terrain ùQúlõüû ò+ó ý þcÿƒû +ó ý þ , and for the elevation above the terrain of the center of the wheel
ùõ û +ó ý þIÿ0û +ó ý þ , then the two simultaneous dynamic equations are given by
ÿù bÿ
ÿ$úùQ ú+ÿ
ù bÿ
ù õ$ú ùQ ú+ÿ (7.1)
ù bÿ Qù ú õ (7.2)
or, in matrix form,
!"#
ÿ$ú ÿ
ÿ
ÿ ÿ
ÿ
ÿ
$%
ùQú õ
&' ù )
(
$ú ' *(
(7.3)
The individual transfer functions for the forces on the masses $ú and to the mass heights ù
and ùQú have the determinant of the above left matrix in the denominator. Hence, the roots of this
determinant are the poles of the suspension system.
ÿ$ú ÿ
ÿ
ÿ ÿ
ÿ
ÿ
+
ÿ
-, õ ö
(7.4)
The parameter sensitivity for the solution to the characteristic equation, relative to parameter
changes for damping and stiffness is simulated in Figure 7.1.
65
Suspension stiffness sensitivity
Suspension damping sensitivity
10
14000
21000
28000
35000
42000
49000
56000
63000
70000
10
5
0
−5
4000
6000
8000
10000
12000
14000
16000
18000
20000
5
0
−5
−10
0
−10
Tire stiffness sensitivity
0
Tire damping sensitivity
10
80000
120000
160000
200000
240000
280000
320000
360000
400000
10
5
0
−5
20000
30000
40000
50000
60000
70000
80000
90000
100000
5
0
−5
−10
0
−10
0
Figure 7.1: The root locations for a quarter car suspension model for various values of the stiffness
and damping parameters. Each graph shows the trend of the pole locations as one of the parameters
in the . / 0 order corner model changes. The title of each graph contains the name of the parameter
for which the value is changed.
66
It can be seen that the system has four poles in the left-half plane, which renders a stable system.
However, if the value for on of the damping coefficients is decreased, the system becomes less
stable. That is, the two complex poles will move towards the imaginary axis. From an engineering
standpoint, it is understood that the system stability degrades for smaller values of the damping 1 .
Wheel Spin Dynamics
A second non-linear feedback can be found in the wheel spin dynamics. The rotation of the wheel
causes it so slip on the terrain. The slip will result in a longitudinal and lateral force on the tire,
which will in return make the tire spin. As shown in Chapter 3, the dynamics are based on wheel
spin velocity. The Dugoff tire model cannot compute meaningfull solutions for the slip force when
velocities are small. The model has been modified to incorporate additional stick friction. This
contribution was discussed in Chapter 3. The tire slip force acts as a damping torque on the wheel
spin. Hence, the force feedback from the tire slip model will always provide a torque to the wheel
which is opposite from the wheel spin.
Euler Angle Transformation method
Another internal loop can be found in the chassis rotational dynamics. Figure A.12 shows two
feedback loops. The first loop will configure the rotation matrix 2 345 . The rotation matrix is
non-linear, but will never exceed the value of 1 for its gain.
The second loop denotes the centrifugal and coriolis forces. The feedback loop causes the system
to have poles that are the roots of the following expression
6 7 898;: 8
<>1 = < [email protected];B
(7.5)
With Equation A.24, the above expression can be worked out as
CDE 7
A
AGA
AF
7 A
A7IKH J
9
: DEC
DEC 8 L
9SRPTRN
1
A8 M
A
N
RAP
9SRL
8 AM
N A
A
A8 PQKH J
A
A
KH J
9S
R NTRL
8 A PQKH J @A
AOA
A
A A
O
CDE 8 L
CDE
or,
7VU W RPY9 U Z RN
UX7
9 U X RP[
U ZU X RP
U W RNO9\U W RL]
U W7
KH J @)A;B
UX
UZ
UZ
(7.6)
(7.7)
The determinant, or characteristic equation of this matrix is computed as
7 R-L^ _ 7 R-N^ _ 7 R-P^ _ 7`
b
@A;a
(7.8)
After discretization, each particular integration approximation method also implies a maximum value for damping.
This is related to the different methods of pole location transformation, as discussed in Chapter 4.
67
c dfeg;hFc
which has the following three solutions:
iSej k lk hmc neoj k lk p
(7.9)
The poles describe a pure harmonic with the frequency of the magnitude of the signal. This
behavior is just what is known as the coriolis forces; the angular inertia torque. From Equation
A.24 we can see that the diagonal of the feedback matrix is zero, which means that the feedback
torque is cross-relational.
A true concern in the system in Figure A.12 is the Euler transformation. Matrix qr translates
instantaneous angles into independant Euler angles. The matrix is given in Equation C.11. in this
matrix we find that
stu
e
vQ
w yx z { | }~  €
(7.10)
d
i‚
which means that gains in the matrix will approach infinity when the roll-angle approaches to .
Mathematically, the solution to the rotation
g problem becomes non-trivial for square angles. This is
a well-known problem for Euler angle transformations. Hence, the simulation will “crash” when
the vehicle encounters a roll-angle of ƒ o.
The problem does not involve the yaw-angle. Therefore in ‘normal’ driving conditions, the
transformation will conduct its task.
No more internal feedback loops can be found in the vehicle dynamics model. Closed loops that
incorporate the human driver are discussed toward the end of this chapter.
7.3 Simulation Specific Stability
In this section we will take a closer look at stability and performance issues that are simulation
related. The first paragraphs are dedicated to the study of simulation stability of systems, that
are internally transformed using different approximation schemes. Figure 7.2 shows the mapping
of poles for different approximation methods. As was discussed in Chapter 2, the model for the
VVSS can be considered as a chain connection of three partitions. The study on stability will
therefore focus on a three-partition dynamic system.
The following paragraphs will discuss issues that are related to the accuracy and timing of SPINE.
Stability of integration scheme
The stability and accuracy aspects of the numerical approximation scheme are of great importance
to the performance of the VVSS. The discussion in Chapter 5 addressed many of the decision
making considerations in this respect.
68
Pole locations in Laplace domain
FDA
Imaginary Im(s)
15
10
BDA
1
1
0
0
5
−1
0
−5
−10
−15
−30
−1
Bilinear TA
−20
−10
0
Zero Order Hold
1
1
0
0
−1
Real Re(s)
−1
−1
0
1
−1
0
1
Figure 7.2: Pole location transformation for various integration schemes.
With the pre-assumption that the continuous time system will be stable, we will look at two
general configurations for approximating a linear system. The configurations are not arbitrary, but
they reflect the switching of integration methods that occurs when a submodel is being simulated
through SPINE. The phenomenon was discussed in Chapter 5.
„Q… † ‡ ˆ
„‰ † ‡ ˆ
„\Š † ‡ ˆ
Bilinear
Euler
Bilinear
Figure 7.3: Example of a second order linear feedback system with three general partitions.
The general linear system is given in Figure 7.3. It has the structure which coincides with
the structure of the VVSS, in that it is subdivided in three partitions. By selecting one of the
transformation methods from Equation 4.1, a discretized approximate expression can be derived
for each of the subsystems. The total transfer function of the system is given by
Œ‘’Œ “
Œ‘Œ —
Œ‘Œ š
„‹† Œ ˆ„Q… † Œ ˆ „‰ † Œ ˆ „\Š † Œ ˆSŽ\
Ž 
f
Ž
† Œ‘I”• –
Œ‘˜”;™ –
Œ‘I”;› –Iœ
(7.11)



„‰ † ‡ ˆ
As a result, it can be found that if the subsystem
‰ is discretized using Euler approximation
„‹† Œ ˆ
and is stable, then, the total system
will be stable .
The problem becomes less obvious, when a feedback loop is introduced. Figure 7.4 shows the
configuration.

Note that the bilinear approximation method is inherent stable.
69
-
žQŸ ¡ ¢
ž£ ¡ ¢
ž\¤ ¡ ¢
Bilinear
Euler
Bilinear
Figure 7.4: Example of a second order linear system with three general partitions.
With the feedback loop, the transfer system is now given by
ž\¥ ¦ § ¢f¨ž‹ § ¢ ©Sªž‹ § ¢ ¢ «
§ ¢
Ÿ
(7.12)
§ ¢
Using the transfer function polynomials ¬
, the poles of the feedback system can be
§ ¢ª
§ and
¢-¨>­ ®
found as the roots of the problem ¬
­
. It is hard to express the effect of individual
ž\¯ § ¢
ž‹ § ¢
poles and zeros in the subsystems
. When representing the system
in state space form,
i.e.
°;±
°;±
±
±
±
the transfer of
² Ÿf¨³
¶ ¨)·
°;±
ª´µ
ª¸Qµ
±
» ¹ º , is given by ±
º
¶ ¨ž‹ § ¢¨)· § ¼½’³¢ « Ÿ Q
´ ª‹¸I¾
µ
Using this formulation, the closed loop system
ž\¥ ¦ § ¢
(7.13)
(7.14)
(7.15)
in Equation 7.12 can be expressed as
Ÿ
Ÿ
Ÿ
ž\¥ ¦ § ¢f¨¿ ·) § ¼½’³¢ « Q
´ ª‹¸À˜¿ ¼ª‹·) § ¼½’³¢ « Q
´ ª‹¸À «
(7.16)
As a result we can observe that a new set of poles is introduced by the second factor, which is
§
an inverse matrix. This inverse does not exist for any which is a solution of the characteristic
equation of this matrix. In other words, the new poles are found from solving
Ÿ
Á; ÃÄ ¼ª‹·) § ¼½’³¢ « Q
´ ª‹¸Å¨®;¾
(7.17)
The solution to this expression can be found numerically and will be a function of Æ , so that the
system can be stabalized by changing tuning the integration step size. However, for the larger
§
§ ¢
§ ¢
systems it will be virtually impossible to find an expression for in the roots of ¬
and ­
.
As an illustration, in the next example we will analyzed the stability of a simple second order
system subject to two different integration schemes.
70
Ï ÊË Ì
Ç
ÈÉ Ê Ë Ì
ÈÍ Ê Ë Ì
Ð ÊË Ì
-
Î É
ÎÍ
Figure 7.5: A general second order feedback system with forward and backward integration
methods.
EXAMPLE 13 Second order integrating feedback system with Forward and Backward
Euler.
Assume the seond order system that is given in Figure 7.5. With forward Euler and backward
ÈÉ Ê Ë Ì and ÈÍ Ê Ë Ì respectively, as
Euler approximation for the systems
ÈÍ Ê Ë ÌÑ Ë Ë Õ
Ò ;Ô Ö
ÈÉ Ê Ë Ì Ó
Ñ Ô ÕÒ Ë
(7.18)
the system is characterized by the transfer function
ËÒ ÍÇ
Ð ÊË Ì Ñ
Í
×
×
×
Ê ÕSØ Î É Ò Î Í Ò Í Ì Ë × Ê ÔÕ Î É Ò Ì Ù
Ï ÊË Ì Ë
(7.19)
The Jury stability criterion tells us that the roots of a second order polynomial
Ú É
will be inside the unit circle if
words,
× Ú É Ë ×IÚ Í
ËÍ I
Ú Í
and
(7.20)
are inside the gray area in Figure 7.6a. In other
ÔSÛ Ú Í Û Õ Ú É ÕÔ
ÔSÛ Ú Í Û Ú É Õ Ô
Ú ÉÜÝ
Ö
Ú ÉÞÝ
when
when
(7.21)
Ù
(7.22)
Applying these conditions to the system transfer function in Equation 7.19, we find that
Ô-Û Ê ÔfÕ Î É Ì ’
Û Õ Ê ÕSØ × Î É × Î Í
Ò
Ò
Ò
×
×
ÔSÛ Ê ÔÕ Î É Ì Û Ê ÕSØ Î É
Ò
Ò ÎÍÒ
Í Ì ÕÔ
Í Ì ÕÔ
Ê ÕSØ × Î É Ò × Î Í Ò
Ê ÕSØ × Î É Ò × Î Í Ò
when
when
Í ÌÜÝ
Ö
Í ÌÞÝ
Ù
(7.23)
(7.24)
By solving the above constraints, a stability criterion can be found for the feedback system in
É
Í
Figure 7.5, as an expression of the coefficients Î and Î ,
Î ÉfßÝ
(7.25)
71
àα
2
a2
1
-1
4
2
h
1
àα
2
h
1
-1
a1
(a) Jury’s general stability area
(b) Stability area for Example 13
Figure 7.6: Stability regions for a second order polynomial and for the second order example
feedback system.
á âSãä
á âSåçæ âé‹ê á ë
è
èì
(7.26)
á ôôõ õ õ á ô
(7.27)
The stability region is graphically illustrated in Figure 7.6b. Jury’s stability theorem can be
ö . A set of secondary
applied to any íî ï order polynomial
coefficients
á ÷ ø ë ðá ñ ò ÷ ó é˜with
ü ÷ á ÷÷ ø
polynomials is recursively defined with coefficients
á ÷ô
á÷
ü ÷ ú á ù ÷÷
ùû
ô
á ôý ä
ú
ä ÿõõõÿ é
ù , where
(7.28)
(7.29)
á ÷ô
, then the roots of ðñ ò ó
á ÷ô theorem says that if
will be inside the unit circle if and
The
only if all , for þ ú
í
are positive. If no is zero, then the number of negative
is equal to the number of roots outside the unit circle.
In the following example, the concept of the preceding one is used with the four variations of
forward Euler and bilinear approximation.
ë
â and
EXAMPLE 14 Stability regions of second order system in four variations
of bilinear
forward Euler approximation.
Take the system in Figure 7.5. Table 7.1 shows the combinations for
the resulting
functions.
ü ë transfer
ü â
ñò ó
and
ñò ó
and
From the characteristic equation (i.e. the denominator of the transfer functions), the coefficients and can be found, and substituted in the second order Jury conditions in Equations
72
FE
FE
FE
BL
BL
FE
BL
BL
Transfer function
Table 7.1: The four transfer functions for four variations of integration methods for the linear
system in Figure 7.5. The roots of the characteristic equation (poles of the denominator) must be
inside the unit circle for the system to be stable. BL means bilinear approximation, FE means
forward Euler approximation.
!
7.21 and 7.22. The resulting stability regions for and
approximation. The regions are given in Figure 7.7.
!
can be found for each variation of
! " ! It can be seen from Figure 7.7(a) that the forward Euler approximation will render a stable
system for a small area in the
-plane. The variation with bilinear approximation in
Figure 7.7(d) results in the largest stability region, hence most combinations for the system to
be stable.
Typically the stability is increased for decreasing step size. This can be verified from Figure
7.7 as well.
%$ Since the the system matrices of the state space model that represent
matrices of the subsystems
, i.e.
&' x * + ./ &' 4353 * + &'
671 8
93 , (
( x¯¯ , - 0 (2
6 ;6 1 8
x
) : : &' ) * + 1 )
¯)
@ -BA 8 8
C8 ( xx¯ , A :%) : :%) ) D x¯
:%) : :
¯)
# , are made up of the
* + '& 6 * + = >
, ( 76 %, < ?
6 :
): :
)
<
D
x
¯
x
¯
x
¯
(7.30)
(7.31)
This solution shows that the closed loop poles of the interconnected system can be traced to the
roots of the subsystems. Hence if
73
E F
a2
2
h
a2
1
h
E
2
h
2
h
2
h
G
a1
2
(a) Region for Combination FE-FE
I
a2
4
h2
E
2
h
G
a1
(b) Region for Combination FE-BL
H
a2
2
h
I
a1
a1
(c) Region for Combination BL-FE
(d) Region for Combination BL-BL
Figure 7.7: Four stability regions for different combinations of integration methods of the system
in Figure 7.5. The combinations are given in Table 7.1.
74
Latency and Synchronization Problems
Stability problems can occur when the remote processor cannot respond adequately fast to maintain
control over the vehicle system. In effect the integration step size is increased when a communication point is missed. With the integration approximation being forward Euler, an increase in
integration step will generally degrade accuracy and may lead to instability.
Typically the remote processor will be assumed to be (and if not so, will have to be) sufficiently
powerfull to evaluate the simulation results in the allowable time (by default 0.028 s). For a
large complex system that cannot be simulated at the required rate, the options for compilation
(Real-Time Workshop) and digital signal processing hardware must be considered.
In particular situations when the simulation does not necessarily need to be computed in real-time,
a solution to the problem of mis-synchronization is available. This solution involves a change in
the communication protocol of SPINE, and requires the use of a command line option . See Section
D.2. The command-line option -b can be used in the startup command line of the VVSS. Selecting
this option will command the VVSS to not continue the simulation if data through SPINE has not
yet arrived.
An alternative method for solving the problem of mis-synchronization is to implement the observer
technique from Chapter 6.4.
Accuracy of communication through SPINE
The accuracy of the simulation output when simulating in a remote process is subject to a number
of approximating algorithms. The first approximation occurs in the exchange of data through
SPINE. The communication is implemented as a string-representation of numerical values. A
quanitzation error is introduced in the amount of 0.1% of the unit value representation .
J
The second approximation scheme is inherent in the numerical integration scheme that is applied.
A study in Simulink of the simulation performance has been conducted to quantisize the effect.
The double integrator in Figure 7.8, without feedback loops is selected as the test system. A sine
wave signal is selected for the acceleration input signal
. The integrator in red represents the
model in Simulink that communicates with the rest of the model through SPINE. Figure 7.9 shows
the comparison of the velocity from the VVSS and the velocity as it is computed in Simulink. The
velocity is the state after the first integrator. The figure shows good approximation for bilinear
integration. The continuous time integration scheme, using Runge-Katta shows satisfactory results
as well.
KL M N
Figure 7.10 shows the comparison of the the position, when the velocity is computed in the VVSS
(i.e. original position), or when the velocity is computed in Simulink (i.e. position through SPINE).
A velocity integration error will integrate over time if forward or backward Euler approximation
methods are used, respectively. This can be seen from the top two graphs in Figure 7.10. Bilinear
O It is the recommendation for future improvements on the SPINE that the exchange of values should take place in
binary float representation.
75
P
Q
Velocity
P
Q
Acceleration
Q
Position through SPINE
P
Original Position
Q
P
P
Q
Figure 7.8: A Double integrator system in the VVSS is used to test the accuracy of simulation
results. The red integrator is modeled in Simulink, and communicates with the VVSS through
SPINE.
3.473
x 10
4
Forward Euler Approximation
3.4725
3.472
3.4715
9.25 4
x 10
3.856
9.3
9.35
Backward Euler Approximation
9.4
9.45
3.855
3.854
3.853
9.7 4
x 10
2.6914
9.72
9.74
9.76
9.62
9.64
9.66
9.78
9.8
9.82
9.84
Bilinear Approximation (Tustin)
9.86
9.88
9.9
9.76
9.78
9.8
9.08
9.1
2.6912
2.691
2.6908
9.6 4
x 10
1.56
9.68
9.7
9.72
Continuous time
9.74
1.5598
Velocity through SPINE
Original Velocity
1.5596
8.9
8.92
8.94
8.96
8.98
9
Time (s)
9.02
9.04
9.06
Figure 7.9: Comparison of simulation output in the VVSS and in a Simulink model through
SPINE. This figure shows the error between the simulated values. Note the different scales in the
vertical axes, which shows that the bilinear approximation method is five times more accurate then
the forward or backward Euler method.
76
approximation is shows in the third graph, to be a better approximation method. (The integration
solution for selection of continuous integration with Simulink is shown in the fourth graph for
reference.)
Stability of State Estimator
The Kalman observer is identified from the history of state observations. The observable canonical
form of the observer system has a convenient property.
SR
S
Since has the poles of as coefficients in the first column, we can immediately test stability.
The requirement is that the solution to the problem in Equation 6.35 must resolve in all
.
As long as this requirement is met, the system in Equation 6.13 will be stable.
T UWVYX
An effect that could however defeat the filter is the loss of observability through sampling. The
effect relates to the nyquist frequency in digital signal processing. If the observer starts to oscillate
in between observations, we will only observe zeros. This effect happens when the frequency of
the oscillations is larger than half the sampling rate.
7.4 Application Dependant Stability
The third study on stability in the context of vehicle dynamics is intensively condected in the
industry. It is the area of driving stability. Driving stability is an application specific system
problem. This means that no generalized theoretical performance criterion has been established
and no particular definition of stability has been adopted throughout.
Driving stability or vehicle stability control schemes are developed in a wide variety. The definition
of the performance specification or the instability criterion will focus the designer on different
objectives, and will thus lead to different control systems. The research in vehicle stability can be
broadly classified in the light of a number of performance objectives. The overview here is not
complete but covers the most important aspects of vehicle stability.
Active Suspension is a control system that is designed to optimize vertical acceleration stability.
This class of systems is devided with respect to two properties.
The applicable bandwidth is determined by the performance objective. The term skyhook
is typically referred to in this case, as is referres to an imaginary large mass in the sky.
The system is designed from an imaginary damper between this mass and the vehicle. The
objective is to stabilize the mass
.
Z[
The energy consumption of the system is characterizing the class of active suspension for its
application platform. The terms semi-active suspension and active suspension are generally
used to refer to low-energy and high-energy consuming solutions.
Traction Control is a control system that optimizes the stability of the vehicle’s traction. The
term stability here is used to refer to a reliable constant amount of torque on the wheels.
77
Forward Euler Approximation
200
100
0
1
2
3
4
5
6
7
Backward Euler Approximation
8
9
10
1
2
3
4
5
6
7
Bilinear Approximation (Tustin)
8
9
10
1
2
3
4
8
9
10
9
10
200
100
0
200
100
0
200
5
6
Continuous time
7
Position through SPINE
Original Position
100
0
1
2
3
4
5
6
7
8
Time (s)
Figure 7.10: Comparison of the values for position, simulated in the VVSS in the case when a
submodel is being simulated in Simulink through SPINE. The integration errors for the forward
and backward Euler approximation methods integrate over time, as can be seen from the first and
second graph respectively. The third graph shows that the comparison using bilinear integration
method is better. (The fourth graph shows the comparison when selecting continuous method in
Simulink.)
78
The performance objective for the system is to minimize slip at the tire-terrain contact
surface and to distribute torque to the wheels which have a high slip coefficient at the contact
area.
The implementation is usually achieved through measuring differential wheel speeds and
individual braking.
Yaw Stability The yaw rate of the vehicle is an idication for the cornering stability. Effects
like spin-out, understeer and oversteer are used in the performance objective of the control
system. Actions like vehicle speed, or more advanced: diagonal braking, are used as control
output actions.
Yaw rate will become unstable when the vehicle is in oversteer. In Equation 8.16 in the next
chapter, oversteer is defined as negative understeer. The following simplistic model can be
assumed.
Steering Command
Lateral Accel.
-
Dynamics
Vehicle
Yaw Rate
Understeer
Dynamics
Tire
]\
]\
The vehicle dynamics model is dependant on the vehicle speed . For some where the
understeer gradient
is negative, the above model will become a positive feedback system
which will then destabilize the yaw-rate. As a result the vehicle will spin-out, turn backwards
and face upcoming traffic.
^%_
Roll Stability is currently an indicator system that monitors the vehicle state and alarms the driver
when the vehicle is on a course of a roll-over situation.
The critical angle is unique to a particular platform. In some situations more generic criteria
are used to indicate roll-over, like wheel lift-off, or the relative lateral load displacement
[47].
The integration of different vehicle stability methods will lead to a systems approach to vehicle
handling control, like is being developed by some of the auto manufacturers for the luxery class
vehicles.
7.5 Conclusion
This chapter highlighted on several aspects of stability. The dynamics equations of the vehicle
model must be examined and understood in detail. The introduction of an integration approximation
method is the most important consideration for the stability of the digital simulation. Especially
79
when a state is simulated through SPINE, then the numerical accuracy and the bandwidth of the
state are limited.
Studies for roll stability and yaw stability are applications of the VVSS that is presented in this
thesis. It is important to understand the limitations of the VVSS with respect to simulation stability
and accuracy, when applying the system to the study of vehicle dynamics response.
Chapter 8
Verification
The vehicle dynamics model is exposed to several standarized automotive test experiments. The
output graphically shown and is analyzed in a numerical way to provide a validity check of the
model response. The closing of the chapter recommends two validation studies to be conducted,
at the time when the VVSS has to correlate with a particular target vehicle platform.
8.1 Introduction
There is no technical merit to simulation and control of experimental systems without the models
being validated carefully and accurately. Validation has been known to be a time intensive and
laborous effort. However, validation and verification is an essencial benchmark for the quality of
the developed model. Future experimental results, based on simulations with the model have no
merit if the model has not been shown to correlate in a series of validation tests.
This chapter details the verification experiments that are conducted to demonstrate that the VVSS
simulation results will be meaningfull to design and test studies. Most of the experiments are
common and well known in the automotive society are recommended as standard test procedures
[59].
Verification is used to demonstrate the validity of the models. It does not prove that the simulation
predicts the behavior of a particular vehicle within a certain margin of error. Validation encompasses the required experimentation with the vehicle and optimization of the dynamic models in
order to correlate the behavior of a particular test vehicle with the simulation model. The chapter
concludes with two recommendations for validation.
80
81
Figure 8.1: Telemetry aquisition and communication system will be used for real-time on-line
validation.
8.2 Vehicle Kinematics and Dynamics
The collection of submodels that make up for the overall vehicle dynamics model were explained
in Appendix A. The kinematic and dynamic character of the model showed good correlation with
simulation results by ADAMS, as was documented in the project report for ITT [9]. In the same
report, also verification studies were conducted and graphically illustrated.
In the following sections a series of verification studies is conducted that show the dynamic
character of the vehicle model. It can be concluded from the simulation results and the numerical
analysis of it, that the physics of the vehicle model are accurate.
8.2.1 Static load at the tires and suspension
Figure 8.2 shows the settling character of the vehicle for symmetric load load distribution. The
vehicle is not in motion. Each corner of the vehicle is loaded with a quarter of the vehicle mass
kg. Hence the force in the suspension will be
`abYc d d
a b c d d cnobBn
ef g h7b ` Y
i j l
i km
k p qr
(8.1)
The tires have the additional unsprung mass
a `sty bwv c d d i d y cn{b i
etsug htbwv ` ;
i x
j
i x
z
k m q | } r
n km d d d r
~ s€bBn } d m d d d r 
 f g htb e f f g h b n n k d p d q d Y
b d m n d |
~
k m
The deflection for suspension and tires can be computed with the stiffness coefficients
and
, to be
(8.2)
~ f#b
(8.3)
82
Steady state deflection lengths for suspension and tires
0.12
Suspension Defletion
Tire Defletion
Deflection (m)
0.1
0.08
M =800 kg, K =19,000 Nm, K =150,000 Nm
v
S
T
0.06
0.04
0.02
0
1.5
2
2.5
3
3.5
Steady state deflection forces for suspension and tires
3000
Forces (N)
2500
2000
1500
1000
500
1.5
2
2.5
3
3.5
Time (s)
Figure 8.2: Validation data for steady state load distribution.
‚ ƒu„ …t†ˆ‡ ‰ ƒuƒ „ … ‹
†  Š Œ  Ž † ‘   ’“
 ‘   
(8.4)
8.2.2 Steady state cornering
Steady state cornering is the experiment where Ackermann steering geometry and lateral slip forces
can be verified. The lateral slip forces compensate for the centrifugal acceleration of the vehicle
as it maintains its velocity in a circular motion.
›  œ 
” • –C— † ‘  ˜ ™š
The experiment is conducted with a steering angle of
. The mass of the vehicle is
, and the wheels weight
each. The centrifugal force that exerts on the vehicle in this
test is given by
Žœ 
˜¤
† Ÿl ¢¡£ †¦¥ ›  o§ Ž©’ ¨ Ž ª › ‘ ’ £ †  Ž Š‘ › Ž¬
‡ •ž ˆ
˜¤
 ‘ Š  «
Œ ¬
(8.5)
where is the radius of the trajectory (See Figure 8.4). This total centrifugal force implies an
average of
per wheel of lateral force, which is a good estimate as can be seen in Figure 8.5.
The verification of Ackermann steering geometry is addressed in Section 8.2.4.
83
Steady state cornering deflection lengths for suspension
Deflection (m)
0.108
0.106
Left Front
Right Front
Left Rear
Right Rear
0.104
0.102
0.1
0.098
0
10
20
30
40
50
60
0.01
5
0.005
Velocity
Roll Angle
0
0
10
20
30
40
Angle (rad)
Velocity (m/s)
Vehicle Velocity and Rolling Agle for Steady State Cornering
10
0
60
50
Time (s)
Figure 8.3: Suspension deflections, vehicle velocity and roll angle for steady state cornering
validation test.
Trajectory of Vehicle during Steady State Cornering test
100
80
60
r =50.6257 m
s
θ =0.05 rad
cmd
40
20
0
−20
−60
−40
−20
0
20
40
60
Figure 8.4: The trajectory during steady state cornering. The vehicle is driving in clockwise
direction.
84
Lateral Slip Forces during Steady State Cornering test
400
350
Lateral Slip Forces (N)
300
250
200
150
100
50
0
0
10
20
30
40
50
60
Time (s)
Figure 8.5: Lateral forces on front tires for steady state cornering.
8.2.3 Constant torque acceleration and braking
The equations of motions can be verified by applying a constant torque on the wheels. Simple
Newtonian physics can be used to compute the velocities and distance for an accelerating body
over a given period of time.
The test is conducted in two stages. The vehicle is accelerated in the first 10 seconds by applying a
constant torque of
on the two front wheels (the vehicle is designed for front wheel drive).
In the time interval of 20 - 25 seconds a constant brake torque of
is applied to each wheel.
This accelerating and brakng profile is shown in Figure 8.6
­ ® ®¯°
­ ® ®¯
The acceleration of the vehicle in the first 10 seconds can be found from Figure 8.6 as
±%²´¶³·µ ²ˆ³ ¸²ˆ¹º » ² ® º ¹ » ° · ¼ µ º
­®
(8.6)
This value for the acceleration compares with the vehicle acceleration that results from the tire
forces
±%²¾Æ½ÇC¿ ÀÈ#Á  ɿ à ÆÄ Å ÄÊ ¿ ² ¶ Ë Ì ÌÍ Í º » È È É ¶ Ë Ë É Î ­ Ï º Ì ² ® º ¹ ¹ Ð ° · ¼ µ
®®
®
(8.7)
Furthermore, from Figure 8.6 it can be found that the final distance should compare with the area
85
Accelerating and braking Longitudinal Slip Forces
Slip Forces (N)
600
Right Front
Left Front
Right Rear
Left Rear
400
200
0
Mv=800 kg
−200
−400
0
5
10
15
20
25
30
200
5
100
Velocity
Position
0
−5
0
5
10
15
20
0
25
Distance (m)
Velocity (m/s)
Vehicle Velocity and pitch angle for accelerating and braking
10
−100
30
Time (s)
Figure 8.6: Torque profile and velocity and position output for constant torque accelerating and
braking.
under the velocity curve. In formula this means,
ÑÒˆÓ Õ Ô ÒˆÖ× Ø{ÙÚ Û ÜÝÜ Þ7ß#Õ Ö× Ø{ÙÚ Õ à Ý Õ Ü Þ #
ß Ö× ØÙÚ Õ ÜÝ#Û Ü Þ Ò Û Û Ø× Õ àá
(8.8)
and computed with the acceleration, we can see that after the first 10 seconds, the vehicle has
traveled
ÑÒ ÕÓ ã â Ò ã Õ Ô â Ò Ú Ü× Ö Ø{Õ ä Û Ü Þ â ÒYå å × àá ×
(8.9)
8.2.4 Ackermann Steering Verification
Ackermann steering geometry is verifying the input steering angle with the computed angle, from
a circular driving test. Figure 8.4 shows this kind of test.
The expression for Ackermann steering angles is given in A.6 and A.7. The steering angle can be
computed from the circular radius in Figure 8.4 as
æ ç èCé{êYë ì í î ë ïð7ñ{ò ßôó ò ê Õ à × ù à Ò Ü× Ü à õ ãú ×
õ öø÷
Ü
(8.10)
86
Steering Wheel Angle (rad)
Ackerman Steering Geometry
1
0.5
0
−0.5
−1
0
1
2
3
4
5
6
7
8
9
10
Wheel Angles (rad)
1
Left
Right
0.5
0
−0.5
−1
0
1
2
3
4
5
6
7
8
9
10
Time (s)
Figure 8.7: Ackermann steering verification test.
Cornering geometry difference for left and right wheels will be shown by turning the steering
wheel left and right with a sine input, on a standing vehicle. The input angle is shown in the top
graph of Figure 8.7. The steered wheel angles
and
are shown in the bottom graph.
û ütý þ
û ütý ÿ
The small difference in wheel angle at neutral steering angle position is called the toe-in angle,
and was discussed in Section A.2.
Given a track width of m and a gear ratio of , with an input steering wheel angle
of rad, the steered wheel angles are computed with Equations A.6, A.7 and A.9, as
û
as can be seen at -
! ÿ þ $ ÿ " # " % ÿ &
ý þ +* þ" # ÿ ÿ $ÿ "% &
û ý þ û
,/. .
8.2.5 Stopping distance
' ( ) (8.11)
' ( , )
(8.12)
87
Stopping Distance Emergancy Brake Test
240
220
200
180
14
15
16
17
18
19
30
6
Velocity (m/s)
25
Velocity
Acceleration
20
4
2
15
0
10
−2
5
−4
0
−6
−5
−8
−10
14
15
16
17
18
−10
19
Time (s)
Figure 8.8: Typical trajectory profile for stopping distance.
Stopping Distance Emergancy Brake Test
500
Longitudinal Slip Forces per Tire (N)
0
Left Front
Right Front
Left Rear
Right Rear
−500
−1000
−1500
−2000
−2500
−3000
14
15
16
17
18
19
Figure 8.9: Typical trajectory profile for stopping distance.
Acceleration (m/s2)
Position (m)
260
88
The distance that is covered between the moment when a hazard is recognized and the time when
a vehicle comes to a complete stop is not rarely of crucial importance. It is the distance travelled
during the retardation time, plus the distance travelled during decelleration,
0 123 4 5 687 ;:3 >< 9 =
(8.13)
The time that it takes to bring the vehicle to a complete stop is called stopping time, and is the sum
of the latency and the decelleration time,
4 12?4 5 687 <3
where 4
56
(8.14)
the time where no braking occurs
D
4 5 [email protected]?4 A7B4 C7 4 E
; =
(8.15)
The the retardation time for pressure build up is given by 4 C , and 4 A is the human reaction time.
The reaction time is not a fixed value, it ranges from 0.3 to 1.7, depending on the driver and on
external factors. The retardation time varies per vehicle. Values between 0.36 and 0.53 seconds
are generally used [5].
Figure 8.8 shows an emergancy brake test. From the position in the top graph, we can see that the
; F FGH; ; I 2 ; J/K at a velocity of ; ;/KML 0 , at the maximum possible
stopping distance is around
IEKML 0 9 . Figure 8.9 shows the associated longitudinal slip forces. The
decelleration of close to N =
forces at the front wheels are greater since the decelleration induces a load transfer to the front of
the vehicle.
8.2.6 Circular Skid Pad
An effective way of measuring steady state directional control is circular skid pad testing. The
objective is to drive the vehicle in a constant radius at a range of speeds, starting from very slow
(to establish Ackermann Steering, as in Section A.4) to near the limit of the vehicle. At each speed
a number of measurements will be made. They include the steering wheel angle, vehicle velocity,
lateral acceleration, roll angle and yaw rate.
The circular skid pad test is particularly usefull to estimate the understeer/oversteer gradient. A
vehicle is said to understeer when, as lateral acceleration increases, the slip angle at the front axle
increases more than it does at the rear axle. (The opposite applies for a vehicle which oversteers.)
The SAE definition for understeer gradient is given as
O8P 2RQ S T UV
Q T X W Y
(8.16)
89
Vehicle Driving Commands
1
Steering Wheel
Throttle
Angle (rad)
0.8
0.6
0.4
0.2
0
0
20
40
0
20
40
60
80
100
60
80
100
Velocity (ms−1)
25
20
15
10
5
0
Time (s)
Figure 8.10: Throttle command and roll angle for circular driving test.
Vehicle Dynamics Response for Circular Skid Pad
Cornering Radius (m)
100
80
60
40
20
Lateral Acceleration (ms−2)
0
0
20
40
0
20
40
60
80
100
60
80
100
15
10
5
0
−5
Time (s)
Figure 8.11: Vehicle velocity and heading in a circular driving test.
90
Trajectory of Vehicle during understeer
100
100
80
80
60
60
40
40
20
20
0
−50
0
50
0
−50
First 80 seconds
0
50
Last 30 seconds
Figure 8.12: Planary trajectory graph for circular driving test. The vehicle is driving in clockwise
direction.
with the lateral acceleration
Z:[
Z ab c d e f
\]^`gH_ h>iBj:gl]k
(8.17)
which states that the gradient is defined as the increase of steering angle per increase of velocity
[47]. A Vehicle is said to be in oversteer if m8n is negative.
From Figure 8.10 it can be seen that the vehicle will go in understeer after 80 seconds. Since the
vehicle is front wheel drive, the rear tires are only exposed to the lateral acceleration forces and
not to the traction forces.Z [ When at approximately 110 seconds also the rear tires start to slip, the
vehicle becomes oversteer spins out, as can be seen in the trajectory in Figure 8.12.
The lateral acceleration \] for the circular skid pad experiment is plotted in Figure 8.11. The
lateral acceleration approaches a value of 9, which is just less than the gravity acceleration o . This
Z ab c on
d e f a dry surface, which is given by
value coincides with the maximum slipforce
prq s/t
] u^?vEw g [email protected]
(8.18)
Commercial test procedures for cornering tests are found in [30] and [59].
8.2.7 Yaw acceleration while braking under split-v condition
The correctness of the behavior of the vehicle, when the tire dynamics are exposed to different
slip coefficients per wheel, can be verified with the split- v braking test. The setup is such that the
left two wheels are in contact with dry terrain (high stiffness) and the right two wheels on slippery
conditions (wet, icy, i.e. low stiffness).
The test results are drawn in Figure 8.13. Figure 8.4 shows how the longitudinal and lateral tire
forces build up during the test.
91
Split−µ Brake test
Trajectory
10
5
0
−5
220
225
230
235
240
245
250
255
260
Yaw Angle (rad)
2.5
2
1.5
1
0.5
0
0
2
4
6
8
10
12
14
16
18
20
Time (s)
Figure 8.13: Trajectory and yaw profile for split- y brake test.
Longitudinal Tire Forces During split−µ Braking
0
−2000
Left Front
Right Front
Left Rear
Right Rear
−4000
−6000
0
2
4
6
8
10
12
14
16
18
20
16
18
20
Lateral Tire Forces During split−µ Braking
4
3
Tire Forces (N)
Tire Forces (N)
2000
x 10
Left Front
Right Front
Left Rear
Right Rear
2
1
0
−1
0
2
4
6
8
10
12
14
Time (s)
Figure 8.14: Tire forces under split- y braking conditions.
92
Braking in a Curve
25
Trajectory
20
15
10
5
0
180
190
200
210
220
230
240
250
260
Yaw Angle (rad)
2
1.5
1
0.5
0
0
2
4
6
8
10
12
14
16
18
20
Time (s)
Figure 8.15: Trajectory and yaw profile for braking in a curve.
8.2.8 Braking in a curve
The combination of braking and cornering is probably one of the most common encountered
manouvers in driving. A vehicle reaction to this manouvermust be characterized by the best
possible compromise between steerability, stability and retardation.
Several methods are available to conduct braking in a curve. Starting with the vehicle traveling
in a straight line, the steering angle is changed to a specified angle. The vehicle response serves
as the basis for evaluation. The most important quantities to be measured are yaw speed, vehicle
speed and lateral acceleration. The trajectory, the yaw angle and the tire forces for this experiment
are shown in Figures 8.15 and 8.16.
Commercial test procedures for barkeing in a curve are found in [28] and [59].
8.2.9 Double Lane Change
The last test in this section of vehicle behavior verification check experiments is the double
lane change. The test is a standardized procedure for characterizing vehicle handling in traffic
manouvers.
The vehicle dynamic lateral response is of particular interest. Figure 8.17 shows the commanded
and the resultant trajectory, with in the bottom graph the associated steering command. The
93
Longitudinal and Lateral Tire forces for braking in curve
2000
Fslip,x (N)
0
−2000
Left Front
Right Front
Left Rear
Right Rear
−4000
−6000
3
0
x 10
2
6
8
6
8
10
12
14
16
18
20
10
12
14
16
18
20
4
Left Front
Right Front
Left Rear
Right Rear
(N)
2
1
F
slip,y
4
0
−1
0
2
4
Time (s)
Figure 8.16: Suspension deflections and heading profile when braking in a curve.
Double Lane Change Manouver
10
Trajectory
Driving Command
Trajectory
5
0
−5
−10
200
205
210
215
220
225
230
235
240
Steering Wheel (rad)
0.3
0.2
0.1
0
−0.1
−0.2
15.5
16
16.5
17
17.5
18
Time (s)
Figure 8.17: Trajectory and asociated steering command for double lane change.
94
Longitudinal and Lateral Tire forces for braking in curve
3000
Left Front
Right Front
Left Rear
Right Rear
2000
F
slip,y
(N)
1000
0
−1000
−2000
Lateral Acceleration (ms−2)
−3000
15.5
16
16.5
16
16.5
17
17.5
18
17
17.5
18
10
5
0
−5
−10
15.5
Time (s)
Figure 8.18: Lateral forces and lateral acceleration on the vehicle during lane change.
distance and time axes are aligned, so that the top graph correlates the distance with the steering
command at the particular time instance. Figure 8.18 shows the lateral acceleration and the lateral
tire forces in the same time frame.
Commercial test procedures for lane change are found in [29].
8.3 Telemetry for Real-Time Verification and Validation
Additional experiments are planned for the future at the Oakland proving ground. This study will
involve a telemetry data-aquisition system installed in a vehicle. It will enable the VVSS to log
numerous vehicle sensory information through a radio-link in connection with the virtual vehicle
in simulation. The driver inputs from the real vehicle will applied to the model as inputs for the
simulation. The concept for telemetry is drawn in Figure 8.1.
Using the telemetry configuration, different tests and experiments can be conducted, to validate
the vehicle performance and driving behavior. It is the objective, that the solution of the simulation
of the virtual vehicle correlates with the real automobile’s driving dynamics.
At second instance, the telemetry configuration can be used to condect carefully designed experiments that will help identify vehicle parameters and therefore validate the simulation model against
the real vehicle dynamics. Validation in this context is defined as the process of optimizing model
95
Mass
High frame-rate video capturing
µ1
Dual µ-surface
sliding table
µ2
α
Figure 8.19: Dual-z dynamic sliding and static stick friction verification test table.
parameters while minimizing the correlation error between simulation and empirical data { .
For example, tire data is typically not well parameterized. Characteristic data can be found by
carefully matching experimental data on the simulation results. Similarly, nonlinear suspension
characteristics can be found and used to optimize the VVSS model.
In order to aquire sufficient data for vehicle model optimization, the following set of sensors are
required.
|
|
Driver input sensors. Steering wheel angle, throttle and brake pressure will have to be
measured. If brake pressure is not available then brake angle will be recorded.
|
Chassis motion sensors. Gyroscopic sensors and accelerometers for angular and translational
motion for the six degrees of freedom are required. Additional (redundant) sensors like GPS
will be beneficial for improving accuracy.
|
Suspension deflection sensors. Typically installed as an LVDT parallel to the struts, between
the suspension mounts.
Vehicle speed. A fifth wheel must be connected to the vehicle to measure unperturbed
vehicle speed. From the vehicle speed, tire slip dynamics can be derived.
The requirement of the availability of a restricted test area, the telemetry equipment and an
experimental vehicle that is furnished with the necessary sensors and DSP equipment, must be met
before experiments can be conducted. Hence, validation tests are time consuming and costly.
} It must be realized that many characteristic data still cannot be found, using this method. For example, the engine
torque constant map will require a dynamo to characterize.
96
8.4 Tire model verification
A fuzzy logic tire model has been introduced in Chapter 3. The dynamic behavior of the model
must be validated with experimental comparable friction measurements. For this study a tilted
table with dual friction surface as is shown in Figure 8.19 is needed.
The study involves the following experiment. A well known mass will slide down the low-friction
surface and gradually accelerate as it does so. Once on the high-friction surface, it will decelerate
until it comes to a complete stop. The friction coefficients must be known. During the experiment,
the high-speed camera will record the motion of the mass. From the speed profile, it can be studied
how the sliding and friction forces act on the mass, and thus validate the friction model. This
validation experiment has not been completed for this dissertation.
8.5 Conclusion
Verification of the vehicle model, as it was presented in Section 8.2 shows that the physics of
the vehicle dynamics model are accurate, and that the response of the model compares with the
expected behavior. The assumptions in the model designs and the level of detail of the submodels
is discussed in the next chapter and in Appendix A.
Verification and validation are two different necessary studies that need to be conducted before the
simulation output can be related to the driving performance of any real vehicle.
When the vehicle simulation will be used for predicting particular vehicle manouvring behavior,
additional correlation studies must be conducted, to validate the vehicle model. A procedure for
doing so was discussed in this chapter.
Chapter 9
Conclusion and Recommendation
The result of the research that is presented in this thesis is the successfull completion of the Virtual
Vehicle System Simulation. The VVSS and SPINE have been implemented and are available for
studying vehicle dynamics. The research efforts builds on various elements of systems engineering,
including mathematics for modeling, computer science for implementation and communication,
state-of-the-art technology for graphics, and engineering principles for dynamics and control.
It is difficult to conclude on a research project that has numerous challenges for growth. This
chapter is the conclusion of the research that has resulted in the virtual vehicle system simulation
with the network for modular parallel simulation in real-time. In addition to the conclusions on
the presented work, the succeeding sections address topics and issues for future work.
9.1 Conclusions
It can be concluded that a system has been developed which allows a person to drive a vehicle
model through a virtual world, and to utilize familiar simulation software like Simulink through a
network to analyze and redesign parts of the vehicle system in real-time.
With the mathematical vehicle model being a purpose-fit representation of a true vehicle, for
analyzing vehicle dynamics, it must be realized that the system will not suit just any research
application. Functional studies of stability and driving-aid systems can now be conducted at a
desktop level. But the vehicle simulation is for example not designed for applications like crash
analysis or safety tests. As the bottom-line question, “can the VVSS be considered a virtual proving
ground ?” For analysis and design studies of vehicle dynamics related systems: yes. However,
test tracks are intensively used for a wide variety of experiments, of which only a particular set
can be conducted with the VVSS.
The main contribution of this research lies in the accomplishment to develop a network structure
for real-time simulation. The application of indirect addressing of the state values, to allow flexible
reconfiguration of the vehicle model is a new approach for simulation, combining computer science
97
98
with systems engineering.
Another contribution is the fuzzy logic tire stick-friction model. The tire dynamics formulation
is still a physical based derivation. The feedback loop for stick friction, supervized by a fuzzy
logic switching algorithm allows the vehicle to halt, backup and speed up, without encountering
numerical singularities.
The verification studies in Chapter 8 show the capabilities of the vehicle model and the dynamic
response to a variety of driving manouvers. Further validation needs to be conducted to ensure
that the numerical output correlate with any particular vehicle platform that is targeted for the
simulation.
9.2 Recommendations
In order to interpret and analyze the predicted vehicle behavior from the simulation, it is of absolute
requirement to understand the fidelity and the limitations of the vehicle model. Conclusions on
certain behavior cannot be drawn without insight in the underlying structure of the model and thus
the origin of the behavior. The fidelity of the vehicle model can be learned from Appendix A
and the verification studies in Chapter 8. Some serious assumptions which may have immediate
impact on simulation results for particular scenarios are the following.
~
~
The tire model is based on a single spoke model  €‚ƒ „ . The spoke is directed in the
vertical plane, in the vehicle reference frame. This means that the tire force will have a
small but non-zero longitudinal component, when the terrain is in an angle with the vehicle
horizontal plane. As a result, the vehicle may slowly start to roll, when there is a pitch angle.
A multiple spoke-model will solve this problem.
~
Currently the wheel spin dynamics do not incorporate gyroscopic, centrifugal and coriolis
forces. Therefore the steering dynamics does not include an aligning force feedback at
higher speeds. This assumption is valid for almost all driving conditions.
~
A strongly reduced engine and transmission model has been implemented in the vehicle
model. Appendix A details about this drive-line. Basically, in the current vehicle dynamics
model, a torque is applied to the front wheels that is proportional to the throttle angle,
dependant on a gear troque conversion factor.
The model for braking is simplified to be a friction, or a damper between the wheel spin
and the chassis. The damping coefficient is dependant on the brake angle. Obviously the
damping coefficient should be dependant on the brake pressure (i.e. the force on the brake
pedal), and the appropriate parameter model should be incorporated as a lookup table. These
improvements are recommended for future work.
The integration methods have been discussed in Chapters 4 and 5. The fact, that integration accross
SPINE can only take place with the forward Euler method, implies a serious constraint on the
99
performance and accuracy of the simulation. The bilinear integration method could be used, if
updated values of the integrated states would be available. For this purpose a Luenberger observer
can be used, to estimate a prediction of new state values. It is recommended that an observer
algorithm of this kind is used for integration of states of the subsystems that are simulated through
SPINE.
Furthermore, the system leaves many parameters to be configured for the right application and many
aspects to be improved upon. The network environment (SPINE) and the vehicle model (VVSS)
have shown to respond appropriately for conducting analysis and design studies for stability and
drivability systems.
With the VVSS facility being modular, it is the objective that it will require minimum knowledge
and effort from any engineer to implement concepts and to conduct simulation research.
Some of the recent commercial collaborations involved research studies on a windhield wiper
system, active suspension, automatic acoustic fueltank level measurement system, automated data
validation, SAE-spike generator modeling [13], traction control for 4x4 trucks [8], and vehicle
speed estimation [34]. In collaboration with the government, Oakland University has worked on a
leader-follower project [10], ACC[14], [11], collision warning and traffic monitoring [48], active
suspension [7] and steward platform kinematics determination [12].
The VVSS can be of considerable added value in a commercial design process. Benefits are in
the process of virtual engineering, where the VVSS is a shining example of the application of
innovative technology, for accelerating the design and development process of new products.
Also in the area of education will the VVSS develop an indispensible intuitive understanding
of vehicle dynamic properties and design. The ease and lack of investment with which design
changes can be implemented and tested instantaneously, allow for students to conduct numerous
educational lab-experiments, that will contribute to the learning process. As a showcase of modern
technology and innovation, the VVSS will serve as a valuable asset in selling vehicle system
performance to customers. Whether they are users, or purchasing for a manufacturing corporation.
Last but not least, the vehicle simulation system is the exclusive tool for developing driving
application systems such as traction controll, anti-roll, active suspension, etc. The rapid and cheap
process of redesigning, testing and analyzing, the simulation provides the valuable capability of
system design optimization. With minor additional changes to the simulator, it can will be usefull
for collision warning, object avoidance, traffic monitoring and aspects of automated highway
systems as well.
9.3 Retrospect and Prospect
The long term vision for the development of the simulation facility requires the consideration
for additional research efforts. The current environment of engineering, stimulates the use of
simulation science and technology for the analysis and design of engineering systems.
Human immersion was mentioned as one of the research aims for the VVSS. The current system
100
utilizes steering, brake and throttle peripherals for aquireing driver inputs, and generates a realtime stereoscopic image of the scenery from the driver’s viepoint. Human immersion however,
includes force and motion feedback and appropriate audio cues, which relate the looks, the feel
and performance to a real driving situation. The real-time interfacing mechanism between the
simulator and the human operator was proposed to be interactive. A driver cab (vehicle interior,
with dashboard, seat, steering wheel and pedals) will be mounted on a Steward platform. The
platform will be actuated from the simulator, in order for the human driver to feel the forces and
motion that are experienced in a real vehicle. Furthermore, the steering wheel and the brakes will
be equipped with actuators, so that forces from the vehicle can be fed back to the driver. Together
with 3D vision and surround sound, the objective of the interface is to immerse the human driver
in the virtual realistic vehicle simulation. The efforts to complete the VVSS with the additional
resources are recommended for future work.
It has been goal of many years to develop a test-track on campus ground. Discussions with
surrounding industry and government agency have ventilated the desire to facilitate an area for
vehicle performance testing as part of the university.
In the goal of the VVSS, to facilitate a wide variety of research applications, it will have to be able
to adopt different vehicle platforms and different scenery. Together with the modularity for the
mathematical submodels, there is a challenge to make the simulator fully modular and transparent
to any particular research application. For future applications, sceneries will be designed for
off-road and (automated) highway testing. Additional research on terrain modeling is conducted
by Alexander Reid [54]. Additional models could be created from the Oakland University campus
or for example the Chelsey proving ground.
In this flexible setup, the VVSS facility will be of great benefit to the courses in Automotive
Mechatronics at Oakland University [31]. Students can start a mechatronics design at a component
level, based on systems originated requirements. They can then implement the concept and test and
validate it against the intended requirements at the systems level. The total procedure procedure
will be exercised in a classroom setting.
Finally, the VVSS will be a usefull testing environment to study multiple vehicle scenarios. The
applications therefore vary from traffic monitoring, road-sign detection, Automated Highways,
Intelligent transportation to battlefield warfare. In the aim of facilitating this kind of applications,
it will be beneficial and innovative to restructure the vehicle dynamics as an object, to be furnished
in a High Level Architecture (HLA). Research for high level simulation architecture has recently
attracted attention in the area of multi vehicle, warfare and traffic simulation. Also this aspect is
mentioned here as a recommendation for further improvement and development toward application.
These notes conclude the contributions of the conducted research, the status of the simulation
system, and a preview of opportunities for future work.
Appendix A
Details on Modeling
The derivations for the system dynamics are presented in the following sections. They are based
on the Newtonian equations of motion and balance of forces.
Additional resources for further reading on modeling vehicle dynamics are found in the fundamentals of vehicle dynamics [21], race car vehicle dynamics [47] and the report on vehicle dynamcis
by ADI, Inc. [27].
A.1 The driver environment
An important model in the loop of the VVSS, which has not been given much attention is the
human operator, or the driver. The human driver is hard to identify and characterize in engineering
terms. The optimal human control model 6.1 has been introduced in Section 6.2. Otherwize,
previous work is referred to, since it is beyond the scope of this dissertation.
The driver environment consists of the interface peripherals for steering, throttle and break and of
the terrain model of the virtual scenery. The interface peripherals are mounted on a shaker table,
so that when it is actuated correctly, the driver can experience the virtual realistic immersion in the
simulation, while controlling the vehicle.
The virtual scenery is displayed in front of the human driver, on a large screen high definition
projection screen. The screen is connected as a monitor for the Silicon Graphics ONYX Reality
Engine. The animation of the simulation output is rendered from the drivers’ viewpoint, in such a
way that the driver has the impression of looking through the windshield of the virtual vehicle.
The ONYX uses hardware graphics boards to generate the scenery, that are designed to generate
3D imaging, using Cristal-eyes goggles. The VVSS is setup to employ this stereoscopic capability.
The motion system that holds the driver seat and console, can be actuated to represent the motions of
the virtual vehicle. Special considerations need to be addressed like washout filters and bandwidth
issues. The table in Figure A.1 is an example of a driver console on top of a motion platform. The
101
102
Figure A.1: The Motion platform with driving environment mounted on top.
implementation aspects of the motion platform will be addressed in future efforts.
A.2 Steering Model
The steering wheel input is defined as the angle of the steering wheel. It is subsequently converted
to the wheel angle … †+‡ ˆ . The wheel angle is an input to the tire model (Appendix 3.2) which
computes the the forces on the tires, caused by the ground contact. The tire forces cause a reaction
force in the steering wheel.
It is important to understand the mechanism of caster and camber angles and steering complience
in order to understand the dynamics of the steering system. The model that is implemented will be
a simplification of these dynamics; accurate enough to provide force feedback to the human driver.
Camber Angle
The Camber angle of the wheel is the inclination of the wheel axis away from the vehicle chassis
in the vertical plane. Figure A.2 shows the camber angle in the right diagram. Camber angle
improves lateral control of the vehicle. Depending on the tires, a camber angle of 0 to 3 degrees
is typically employed. The dynamic equation for the camber angle is given by
‰:Š ‹+… Œ ŽB'… ŽB‘r … >’“'” • – — ˜†@™›š œ'
(A.1)
103
u
Caster Angel
α
Kingpin
Kingpin
Camber Angel
trail
Ÿ
road-tire
contact
patch
(arm moment)
ž
Fy (lateral force)
Figure A.2: The graphical illustration of the definitions for caster and camber angle.
where :¡ ¢ stands for the inertia moment of the wheel about the kingpin axis, £ ¤ holds the camber
angle, ¥ ¦§H¨?© ª'« represents the effective tire radius, ¬¤ is the damping effect and ­r¤ is the
equivalent stiffness coefficient of the connecting system. A simplification without dynamics is
given by
§'¯° ± ² ¢ ³ ´:¥ ¦§@¨H© ª«
£ ¤>®
­r¤
(A.2)
The camber angle will introduce a miss alignment of the tire contact surface area with the terrain.
The derivation is given here for completeness. However, camber angle is not used in the VVSS
vehicle dynamics model, since for the tire model homogeneous pressure distribution is assumed.
Tire deformation forces, other than the deflection are not considered.
Kinpin Angle
The kingpin angle is the angle between the steering axis and the x-axis in the vehicle frame. It has
effect on the steering feel and influences steering force feedback and the steering roll-radius.
Caster Angle
The caster angle µ in Figure A.2 is defined as the angle between the steering axis and the vertical
plane. Together with the kingpin angle it infuences the camber change as a function of the steering
angle, as well as self-centering effect on the steering.
Toe-in Angle
The toe-in angle is the offset angle for the steered wheel or bias on the heading for the non-steered
wheel. It can also be defined as half the distance between the wheel’s front and read rim flange.
The toe-in angle affects straight driving and steering. In the case of front-wheel drive vehicles it
compensates for the elastokinematic changes in track (See [5]).
104
¶AA
θcmd
Tire Angle
¶AP
θw
Steering Wheel
Kst
Stiffness
Coefficient
Gearbox
Kingpin
¸
Mss
·N
Sst
Damping
Coefficient
Moment
about
Kingpin
Figure A.3: The second order steering system model.
Steering Compliance
The model for the steering compliance has been adapted from [18]. The angle ¹ between the
kingpin and the normal unit vector in the º -direction is referred to as the Caster angle. The
distance between the center of the tire contact patch and the point where the axis of the kingpin
intersects with the road surface will be called the »» . This is shown in the left of Figure A.2. The
moment ¼›½ ½ about the kingpin, caused by the lateral force on the wheel can be written as
¼›½ ½¾À¿'Á½ Â Ã Ä Å Æ ÇÈ É Ê Ë ¹'Ì Ä Í
where Ç is the Î
by
(A.3)
Ï Ð:Ñ Ò , shown in Figure A.2. The dynamic equation for the steered wheel, is given
Ó
Õ½
Õ½
Õ½
Ì ÄHÖ8Ô ×@ØBÙ½ ÚlÖ8Û ×@ØBÜ@½ Ú Ö8×ݾ
Ó
Ü@½ Ú Õ Þ ßà ØBÙ½ Ú Õ Û Þ ßàâá ¼›½ ½
(A.4)
Õ is the angle of
where Ì Ä stands for the inertia moment of the wheel about the kingpin axis,
8
Ö
×
¿
the steering wheel,
stands for the gear box ratio of the steering system, Ù½ Ú is the equivalent
Õ
damping coefficient and Ü@½ Ú the equivalent stiffness coefficient of the steering system. ½ is the
steering angle at the steering gear. This model of the steering system is drawn in Figure A.3.
Õ for one of the steered wheels is derived from the Ackermann cornering geometry.
The actual
¿
The concept for Ackermann steering is explained graphically in Figure A.4. The concept shows
that the steering wheel angle commands the vehicle to turn in a curve with radius Ï ½ , such that
Õ½Í
»
:
Â
‚
Ø
Ù
Â
Ë
»
:
Â
‚
Ø
Ù
Â
Í
È
É
Ê
Ë
Ï ½¾ ã ä å Ë Õ ½ Í ¾
(A.5)
Ê æ å Ë Õ ½ Íèç
105
éθ
cmd
2
TF
1
Al+Bl
é θ éθ
s,2
s,1
rs
Figure A.4: Ackermann cornering geometry.
With ê ë , the individual steering angle inputs per wheel can be derived. For the situation as drawn
in Figure A.4, this leads to
õ ì
ù‚ï úø ð ñ òóôñ M
õ ö ó ì
ë
ü ýþMÿ
ÿ ü õ ì ë ë û
õ ì
ù‚ï úø ð ñ òóôñ M
õ ö ó ì
ë õ ì
ü ýþMÿ
ÿ ë
ë ù ü ì í+î ïðñ ò ó ô ñ õMö÷ø
ê ëû
ì í+î ü ðñ ò ó ô ñ õMö÷ø
êëù
(A.6)
(A.7)
A simplified model that contains no dynamics will give the angle of the steering gear from the
steering wheel angle as follows :
ìë ð :ì û þ ë ø # î ! " ë ë
ë $&% For the presence, the steering system is characterized by the steering angle gear ratio
us with the model
from which the steered wheel angle
ì í+î ìë ð :ì can be derived with Equations A.6 and A.7.
(A.8)
, leaving
(A.9)
106
.ΣT
αth
-rpm
)
E
TE
- -
1'
JEs
1'
s
,B
θE
-
+
1'
s
G
JGs
-
θG
,B
DG
+-
E
(N
TG
KG
slip
G
(N
G
TE
TG
αth,3
NG,1
+N
G,2
+N
αth,2
αth,1
*rpm
G,3
TE
Figure A.5: Dynamic model of the powertrain.
A.3 Engine and Transmission Model
The throttle angle /10 2 is read and converted as a torque to the transmission 354 , based on the
7
engine drive shaft rpm 6 4 , using the engine map. The output torque of the engine is loaded with
the transmission through the gearbox, resulting in a transmission torque 318 . This engine and
transmission model is drawn in Figure A.5.
The model incorporates second order gearbox complience in the system with coefficients 9:8 and
;
8 for stiffness and damping respectively. Usually the stiffness of the gearbox is very high, so
that the model can be reduced to the much simpler model, given by
7
7
318=<>85? @ 354BA /10 2 C16 41D
(A.10)
7
where 354BA /10 2 C16 4D is the lookup table, shown in Figure A.5 and 6 4 the rpm of the engine, given
as a function of gearbox ratio and the average wheel spin velocity FE G as
7
6 4H<>85? @ FE G
(A.11)
107
A.4 Brake Model
The brake angle is read and converted to a break pressure. The pressure on its turn is applied to
the wheel and employs a damping effect on the wheel spin motion dynamics. In other words, the
torque is proportional to the brake damping constant IJ , the brake booster constant KLJ , the brake
angle M1N and the wheel spin P O . In Equation, this model is given by
Q
NRTSUIJKLJM1N P
(A.12)
Brake Pedal
K
V br
Brake Piston
X
WD
Nbr
Brake Amplifier
br
Figure A.6: Schematic diagram of the hydraulic brake system.
As a future extension, to model force feedback to the human driver through the brake pedal, the
pressure in the hydraulic actuator will be transferred as the pedal reaction force. A pneumatic
damper on the pedal will model the damping effect of the fluid in the brake piston.
A.5 Wheel Spin Dynamics
Z\[ ]^ _ ` a b c
Q
Q1Y
N
d
ef
d
Ph
g
d
PO
g
P
Figure A.7: Model diagram for wheel angular dynamics.
The wheel dynamics model describes the angular motion, caused by the torques about the wheel
axle. The angular motion dynamics can be expressed as the sum of torques of the inertia,
acceleration and break, and the torques caused by the slip forces. The sum is given in the following
expression.
108
ji
k lnmoqprmrp1st u1v w x1yzp5{1yn|} ~  €  ‚ ƒ\„
(A.13)
From this equation the spin velocity and wheel angle can be found by integration. The state-space
representation of this model (in Figure A.7), is formulated as
†
… j i†
… ‰Š‰ … j
L
… Œ

Œ
Œ
Ž
 Ž ‰
 Ž‰
‰
‰
‹
jˆ‡ m
‡ jˆ‡ y
‡n‘’“
Note that for front wheel drive vehicles p1s5 5m
‰
for —1m™˜
š› œ
p1s
p5{
–
|} ~  €  ‚ ƒ\„L” •
(A.14)
.
A.6 Suspension and Tire Deflection
The wheel mounting and the contact of the tires with the gound are a rather complicated system.
Figure A.8 shows in a diagram how the different components interact. The wheel basically acts
as a free floating mass, connected to a double spring damper system, subject to gravity. In other
words, the location of the wheel žU , is a function of the tire-ground contact point ŸU and the
suspension anchor location on the vehicle frame U .
The submodel for tire deflection and suspension derives the forces for the vehicle frame submodel
and the location of the wheels. It will do this with the input information it has from the terrain map
and the state of the vehicle frame. For example, ¡ U is the location of the suspension anchor in the
vehicle reference frame. This point is a design parameter and is assumed to be constant during the
simulation.
The input from the terrain map is through the interaction point of the tire with the terrain. In the
case of a smooth flat terrain, the contact point will always be perpendicular under the vehicle.
However, when the scenery contains rough terrain (in technical terms: high bandwidth), we may
need to scan the tire at different angles ¢ , so called “spokes”, for the true contact point. A model
which incorporates this capability is called a multi-spoke model.
The terrain map is modeled as a graphical
Πlookup table. It can be accessed by intersectioning an
arbitrary vector with the terrain sections . The terrain map will then return the 3D coordinate of
the intersection point. For example, if £ žU is known, then the ground-contact point £ ŸU is found
by extending the spoke from £ žU , as
À
«
£ ŸU5m¤§©
¥ ¦ ª¨
ª¬ ­=®
k
¡
ƒˆ¯ U
ƒ °z
¡ ±²³ žUy
¡
¥ ¦µ‰ ¢
–1º
¸ ¹ » ª¼
‘’“¶ ´ ·
¢ ” • ½¿¾
r
­
ª
´
Intersectioning is a service that is provided by the Silicon Graphics Performer Development Libraries
(A.15)
109
Ai
 z =L +δ
w
S
S
KS
DS
Ãσ
Å
Á
Bi
LT+δT
MW
KT
FZ
DT
Ä
Ci
Figure A.8: Schematic representation of the mechanical construction of the quarter car suspension
model.
It follows that the tire/suspension submodel needs to translate data from the terrain and the state
of the frame into the anchor location and the tire-ground contact point. In other words, the vertical
wheel motion, tire and suspension deflection have to be expressed as in terms of ÆUÇ and ÈUÇ .
Consider the following assumptions:
É Í
Ê É Ë¿ÌÎÍÍ Ð É
Í Ï Ç5Ñ Ï ÈUÇ ÍÍ
Ê Ë¿ÌÒËÓÔ Ð
Ô
Ï Ç1Ñ Ï ÈUÇ
Ê É ÕÌ ÍÍ Ð É ÍÍ
ÍÏ Ç Í
Ê ÕÌÒÖÕµÓÔ × Ð
× Ô
Ç5Ñ U
Æ Ç
Ø Ù ÌÒÖÕµÓnÊ Õ
(A.16a)
(A.16b)
(A.16c)
(A.16d)
(see Fig.A.8)
(A.16e)
ÒË
where Ú represents the spoke angle, and
is the wheel radius under no-load condition. The
dynamic equation of motion for the quarter car vehicle suspension system in Figure A.9 can then
be expressed asÛ
ÙUØ Ü Ù ÓÝ ÞLËÓàß˵á Ê É Ë1å1Ónæ ç è Ú åUÝ ÞÕµÓàß:Õá Ê É ÕåÌ ÑUé1ê
âãHä
ä
âãHä
(A.17)
110
øùUõ ú5ûýüUõ ú ø
öì:÷ø ùUú5ûüUú ø
öÖîµ÷ø þ ú5ûùUú ø
ø1þ õ ú5ûýùUõ ú ø
íLì
ëì
ð
ë:î
óò ô
ï
ñ
õó ô
ï
ñ
óô
ï
íî
Eq. A.20
Eq. A.20
Figure A.9: Model for quarter car suspension translational dynamics.
From this Newtonian equation, the total suspension length
state space representation of the following form
óô
can be solved and expressed in the
ÿ =
ÿ !
ÿ *
""
*
"# $ % *& ') ( ,,,
# $ % *& ') ( ! ,,
+
""
(A.18)
This model for tire deflection and suspension is generally used to predict and control quarter car
vehicle behavior, like in Louca [41].
One more step is to use Equations A.16 into A.18, in order to express ó
ùUú
üUú
ò
and . The function for ó ô then becomes
òô
in the trajectories of
ï
í ì1 2 3 4 576ûàø5ùUõ ú5ûýüUõ ú ø ÷nëì1 2 3 4 57684 öì=ûàø ùUú5ûüUú ø 6
L
ó ò ô.- ð
÷ íî5ø ùUõ ú ø ÷àë:î4 öÖîLûàø ùUú5û þ ú ø 6
ô / \
0
Now
: ùUú
can be expressed in terms of the rotation matrix,
:
ùUú
- :< ì ;þ
; [email protected]
>
ú÷
;þ
ú
9
þ ú
,
(A.19)
and the suspension defelction as
;8ABCED
D I8LG
JK M
ó ôGF H
(A.20)
Note that the suspension deflection mechanism has only freedom of motion in the vertical ó direction with respect to the vehicle frame. As can be seen in Figure A.8, a spoke angle will
employ a force in the longitudinal direction of the vehicle.
5
111
N
NF
Fbar
FN FS
bar
FS FN
Figure A.10: Front view of the mechanical configuration of the suspension system with lateral
forces decomposition.
This linear model will be valid for all driving conditions, except for a suspension rebounce, or
when the wheels leave the ground. These two exceptional cases are detected with the limitations
of the suspension deflection .
OP
In the first case, the suspension force on the chassis will consist of the force by the compressed
suspension plus the forces in the tire, since it now connects to the chassis. In reality there will be
considerable damping effect from the chassis deformation. This damping is not taken into effect.
Q R STVUWR XT QZY\[]^0_b7` c a
For the second case, as long as
only by the wheel that is hanging on the chassis.
, the force on the vehicle will be caused
In other words, the total deflection force on the vehicle by the quarter vehicle model is given by
q rsstvu w x)y zV{8| }~Z ~€.~ƒ ‚ ~ „
mm
…
mm R [ pq
}†  † ‡ max €.ˆ ‰ u y zV{ | } ~  ~ €Š ~ ‚ ~Z„.‹ ŒŒ
mm
‘ ’““”
m
• – —Z˜ ™ š)› œž Ÿ ƒ ¡ž8Ÿ ¢  £
n
R8e8d f g h i j T8k mm Ž ‘ œƒ¥ Ÿ ¥7 ¡ƒ¥)Ÿ ¢ ¥7 ¦ § • ¤ ˜ ™ š › œ  Ÿ  ¨¡  Ÿ ¢  £©« ªª
mm
‘8¬­®¯
mm
mm
¯
mmo Ž ‘
°±³²µ´· ¶
lmm
Rebound hit
Normal operation
Tire liftoff
(A.21)
112
A.7 Anti roll
An additional force on the suspension called antiroll is introduced by the mechanical design of the
vehicle to produce a counter torque when there is a roll of the vehicle. An additional “stabilizor” is
usually mounted between the left and right wheel axel in the vehicle. This torque will be modeled
here as an additional force at the suspension locations. The force is basically derived as a left
and right suspension differential from (A.18), divided by the track width, which is a geometric
constant, and then multiplied by an equivalent roll stiffness coefficient. This is written in formula
as
¸7¹ º » » ¼ ½¿¾ÁÀÂÃ Ä ¼ ½žÅ ¸ Ã Æ Ä ¼ Æ
¸7¹ º » » ¼ ɾÁÀÂ Ã Ä Ç¼ É¿È Å Ã Æ Ä ¼ Ê
¸
È
ÈË
¸7¹ º » » ¼ ƾÁÀÂÃ Ä ¼ ƞÅ
¸7¹ º » » ¼ ʾÁÀÂ Ã Ä Ç¼ ÊƒÈ Å
ÇÈË
¸7¹ º » »
ø Æ Ä ¼ ½
à ÆÄ ¼ É
(A.22)
ÇÈË
where
and
denote the track width of the vehicle for the front and rear axel respectively.
in space will point in the positive -direction with respect to the vehicle
Note that the vector
frame.
Ì
Í
A.8 The vehicle frame
The frame or chassis of the vehicle has all six degrees of freedom. The frame is characterized by
a mass which has a center of gravity inside the frame. The geometric dimensions as well as the
suspension anchor locations are known properties of the vehicle.
ӞÔ)ÕÖ × Ø Ù Ú Û Ü Ý Ô ÕÖ Þ ß Þ à Û Ü Ý Ô Õá
½
ÎEÏ
º
º
º
ãÌâ
Ò
Ñ
º
ãÌ ä
Ò
Ñ
ãÌ
ÐÌ
Figure A.11: Model for the vehicle frame translational dynamics.
The translational dynamics of the frame can be derived from the forces that act on the vehicle.
These forces (including the wind and the gravity) are then integrated so that velocity and position
are found. Graphically the model for translational dynamics is given in the circuit diagram in
Figure A.11.
For angular dynamics (roll, pitch and yaw), the torques about the rotation axes of the frame have to
113
è7
é
÷žø ù ú û ü ù þ ý ÿ û ù ü ù þ ý û û å æçè
èê é ïVð ò)ó
õ
èZê é
ô
å é
æö
õ
è êG
é ë\ì èZêî
é íïðñ
Figure A.12: Model for the vehicle angular dynamics.
be considered. Instantaneous or gyroscopic angular accelerations can then be found that have to be
translated in the Euler angles. Figure A.12 shows the diagram of the model for angular dynamics.
The feedback loop constitutes the centrifugal and coriolis forces.
The combined dynamics for the vehicle body can be expressed in the following state space model
è
ê å
ï ò)ó
ï ð å ï ð æö
ò)ó ô
!"
! ï ð ò)ó å æçè
è
ê å
&
$#
!"
å %é
å é
(A.23)
#
where the centrifugal and coriolis forces feedback
è êGë(' ï ð¿í è ê*)
è ïð èê
, with
è
,
+.-/0-1 -/23+.-4
+.-15-46 (A.24)
and the Euler angle transformation matrix, given in Equation C.11, in short,
æö
æ7/ æ71 æ74 89 æ7/ æ71:8; 7æ / <>8 =
(A.25)
ï
ïð
Avoid confusion in Equation A.23. is the unity matrix, and denotes the inertia matrix. Besides
the gravity acceleration, the inputs to the vehicle frame dynamics model of Equation A.23 are the
sums of all the forces and torques, projected on the frame center of gravity. The are respectively
?
?
å %é
å é
?A B
?A B
@
ó
@
ó
AE FA
ì å %é C D
FA
å %é G H ö D
FA
å %Jé I å D D ñ
å %Jé K
AL
G
A
AE FA
A
FA
A
FA
ì å M ë0å %é C D
åN 0
ë å %é G H ö D å N E
ë å %Jé I å D D ñ
(A.26)
(A.27)
Appendix B
Details on the Tire Slip Model
In this appendix the tire mechanics model for the case of combined lateral and longitudinal slip
is explained, as it was derived by Howerd Dugoff [16]. The model is derived from the classic
analysis of the freely rolling tire by Fiala [19]. An application of the Dugoff model that shows a
clear overview of the set of equations can be found in [18].
It is based on an idealization of the tire-road contact region geometry as shown in Figure B.1.
The tire in considered to have zero inclination angle. The effects of inclination on the forces
produced are accounted for approximately through the introduction of equivalent slip angle which
is a function of the inclination angle and the tire’s camber stiffness.
ξ
Direction of
wheel heading
Direction of
wheel travel
2
4
ξ
3
1
0
Oη
0
Oη
Figure B.1: Tire-road contact patch geometry.
114
2
115
Q P’
Direction of
wheel heading
s
carcas
atch
ct p
a
t
n
co
ξ tan α
3
P
α
0
Direction of
wheel travel
sξ
ξ’
ξ
Pη
Figure B.2: Strain condition in non-sliding portion of the contact patch.
B.1 Theoretical Derivation
The line 0-1-2 in Figure B.1 is the longitudinal centerline of the tire-road contact patch. The
ground plane coordinate system R - S has it’s origin at the tread touchdown point. From there the
R -axis passes through 2, being the liftoff point. Line 3-4 represents the longitudinal centerline of
the tire carcass. Each point on the carcass centerline is assumed to be elastically connected to
the tread (line 0-1-2) through orthogonal springs that produce independant forces in the R and S
directions. Thus a point on the tread follows the path of the carcass as long as no shear fore acts
on it. In particular, points 3 and 4 lie on the vertical lines passing through the touchdown point 0
and the liftoff point 2, respectively.
Point 1 on the tread centerline represents the “sliding boundary”. Points on the tread forward of
point 1 (segment 0-1) make contact with the ground without sliding. At point 1 the elastic stresses
due tread deformation reach the shear stress limit and the rubber begins to slide, relative to the
ground. The shear deformation along line 1-2 is a function of the local sliding friction potential.
It drops off monotonically, towards zero at the liftoff point 2.
In Figure B.2 a situation is sketched of a typical point T$U RWV SYX in the non-sliding part of the contact
patch, that shows the hypothesized deformation. The longitudinal coordinate of T is equal to the
product of the tire’s longitudinal velocity ZY[ and the time interval \^] , from the instant when T
entered the patch at 0, to the instant as shown in Figure B.2, i.e.
R^_`ZY[J\^]
(B.1)
During the same time interval, point T7a on the carcass centerline (which coincided with point 3 at
the start of the interval) has moved a distance R a , given by
R a _`b*ced \^]
where
b
is the wheel spin velocity and
ced
(B.2)
stands for the effective rolling radius of the tire. The
116
longitudinal deformation of point f , relative to f7g is given by
p*res
hjih gYk`lYmJn^o iqp*res n^otkvuYw i
lYm`x
lYmJn^otk`y h
(B.3)
i}|:~W
where y*k{z w
€ ^‚ is, by definition, the longitudinal slip ratio. So the longitudinal component
of stress at point f is equal to
ƒY„
h
k`…$† y
(B.4)
where …$† is the longitudinal tire stiffness in pounds per unit length, per unit width, per unit
longitudinal deflection.
The lateral deformation of f is given by (see Figure B.2)
where
to
‹
‡ k i.h.ˆ ‰ ŠŒ‹
(B.5)
is the angle between heading and actual travel. The lateral stress component at f is equal
ƒY
k i …$Ž ˆ ‰ ŠJ ‹ h
(B.6)
where …$Ž holds the lateral stiffness in pounds per unit length, per unit width, per unit lateral
deflection.
ƒY‘J’sheer
“
The maximum allowable total
stress at any point in the contact patch is determined by the
tire-road shear
ƒY‘Jstress
’“
limit,
, which varies over the contact patch. One of the main factors
is the normal pressure distribution over the patch. For simplicity a uniform
determining
pressure over the patch is assumed, with a value given by
™š
” –
k ™ • —Jš › ˜ •
›
where is the normal load on the tire, and
—J˜
The shear stress limit accordingly becomes
ƒY‘J’ “
(B.7)
are the length and width of the patch respectively.
œ
k}œ ” k ™ • š —J› ˜ •
(B.8)
where œ is the coefficient of friction at the interface. With this equation for the maximum shear
stress, we
ƒY‘J’ can
“ determine the sliding boundary point 1 in Figure B.1 where the elastic stress just
equals
, as
 ƒJž ƒ
ƒY‘J’ “
„.Ÿ
h ž
k
k
œ
™ • š —J› ˜ •
(B.9)
Let denote the longitudinal coordinate of the sliding boundary point. Then, substituting from
equations B.4 and B.6, we obtain
w
h k œ

ž Ÿ  ˆ ‰ ŠJ ‹  ž
™ • š —J› ˜ • 

… †y
$
… Ž
$
(B.10)
117
Let ¡ £¢ denote the longitudinal coordinate of the point on the tire carcass associated with point ¡ £ ,
then from equation B.3,
¢ ¤¦¥ §Œ¨q© ª ¡ £ ¤¦¥ §Œ¨q© ª «.¯ ¬ ° ­J± ® ¬ ²
¡ £.
§
¥ ³$´ © ª µ¶·¥ ³$¸>¹ º J» ¥ ¼ª ª µ
(B.11)
The actual deformation field of the sliding portion of the patch is approximated by a uniform
deformation, in order to compute the resultant shear forces by a closed-form integration. Although
compatible with the assumption of a uniform normal pressure distribution, this approximation is
obviously considerably in error at points in the rearmost portion of the contact patch. With this
assumption, the values of the longitudinal and lateral tire shear forces and
­J½
­J¾ may be computed
as follows
Ã
¤`¿}À Á
J­ ½
Â
ÀÁ
where from equations B.3 and B.4
µÊ
±
½ ÄÅ ¥ ¡ ¢ ª É ¡ ¢ (
¿ ÆÈ
¶
¿
Ç ½
Ç ½ ¥¡ ¢ª É ¡ ¢Ë É
½ ÄÅ
(B.12)
³$´ © ¡ ¢
Ï
for ¡ ¢JÒ ¡ £¢
§ ¨Ñ©
*
Í
¤
Î
Ì
Î
Ç ½
³$´ © ¡ £¢
for ¡ ¢JÓq¡ £¢
¨ ©
ÎÎÐ §*Ñ
and
Ã
½ ÄÅ ¥ ¡ ¢ ª É ¡ ¢ ¶ ¿ µ Ê ¥ ¡ ¢ ª É ¡ ¢ Ë É ±
Å
¤ ¿}À ¿ ÆÈ
Ç ¾
Ç ¾
­J¾
Â
½ ÄÅ
ÅÀ
where from equations B.3 and B.6
³$¸J¹ º »Œ¼ ¡ ¢
Ï ¨
§*¨Ñ©
¤ ÌÎÎ $
Ç ¾ Í
³ ¸J¹ º »Œ¼ ¡ £¢
¨
§*¨Ñ©
ÎÎÐ
for ¡
¢ Ò ¡ £¢
for ¡
¢>Óq¡ £¢
(B.13)
(B.14)
(B.15)
Note that the stress distribution is assumed to be uniform with respect to the contact patch width.
Thus solving B.12 and B.14 and integrating along the patch width gives
¯ ° µ ± ³$´ ©
¢ Ô ¯°
Ï
for ¡ £Œ
§
*
q
¨
©
¤ ÌÎÎ ¯ ° ± $
Í
³ ´ © ¡ £¢ ± ³$´ ©:¥ ¡ £¢ ª µ
­J½
¨ ¯
¢ Õ ¯°
for ¡ £Œ
*
§
Ñ
¨
©
¥
Œ
§
q
¨
©
ª
ÎÎÐ
¯ ° µ ± ³$¸>¹ º »Œ¼
Ï ¨
§*¨q©
¤ÍÎÌÎ ¯ ° ± ³$
¸W¹ º »*¼ ¡ £¢ ± ³$¸>¹ º »Œ¼Œ¥ ¡ £¢ ª µ
J­ ¾
¨
¶
¯ ¥ §Œ¨q© ª
§*¨Ñ©
ÎÎÐ
(no sliding)
(B.16)
£¢ Ô ¯ °
¯°
for ¡ £¢ Õ
for ¡
(no sliding)
(B.17)
The derived results can be rewritten more consisely in terms of the following auxiliary variables
¼Ö ¤
¯ °µ± $
³ ¸>¹ º »Œ¼
¥ §*¨Ñ© ª
«.¬ ­J® ¬
(B.18a)
118
× ÙÛÚ Ü Ý Þ7ß$à Ø
Ø7
á.â ãJä:â å æŒçÑØ è
Ø × éêÙ`ë Ø ×
í×
Ýì Ý
(B.18b)
(B.18c)
×
Note that the variable Ø é may be considered to constitute a “resultant normalized slip vector”,
×
×
whose components are í and Ø .
Equations B.18 may be used together with Equation B.10 to rewrite B.16 and B.17 in the form
Jã î
á.â ãJä
ãJï
á.â ãJä
where
Ø × ãJé
Ù ×
â Øé .
á â ãJä â
í × Jã é
Ù ×
â Ø é á.â ãJä â
Jã é
ñ ò Ø× é
æ
ÙÍð *
æ ç ø ×
á.â ãJä â
Øé
(B.19)
(B.20)
Ø× Ñ
é óõôYö ÷
×
for Ø éÑùõôYö ÷
for
(B.21)
Note from equations B.18c, B.19 and B.20 that the quantity
ãJéêÙûú ã î
Ý ì
ã ï
Ý
(B.22)
represents the resultant shear force exerted at the tire-road interface.
Equations B.19 and B.20 may be rewritten in terms of the tire coordinate system as follows
Ø × ãJé
Ù ×
â Øé .
á â ãJä â
×í Jã é
Ù
â Ø × é á.â ãJä â
Now let us consider for a moment the special case when íêÙ`ô
ã
àü
á.â ãJä
ãJý
ü
á.â ãJä
(B.23)
(B.24)
. For this case, Equations B.18 and
B.21 may be used together with Equation B.23 to obtain
whence, using Equation B.18b,
But, by definition,
ã
Ùûç Ø ×
àü
á.â ãJä â þþ þþ ÿ
for
Ø × éÑóõôYö ÷
ã
Ù ç
û
àü
ؖ
Ú Ü Ý Þ7ß$à
þþ þþ ÿ
ã
Ù ç Øà ü þ û
þ
þþ ÿ
(B.25)
(B.26)
(B.27)
where is the longitudinal tire stiffness. Equations B.26 and B.27 may be used to rewrite
Equation B.18b in the form
× Ù
Ø7
Ø
á.â ãJä:â å æŒçÑØ è
(B.28)
119
Similarly, by considering the case , we may show that Equation B.18a is equivalent to
! """
#%$ #%&
"
where
(B.29)
(B.30)
The tire-road friction coefficient is known to be a function of sliding speed and normal pressure,
as well as of a host of quantities describing the material and geometric properties of the road
surface and any interface contaminents. The farmost important effect is that of speed, which can
be approximated by a simple linear equation of the form
where the total sliding velocity
)*$
& (' $ )*$ (B.31)
is given by
)*$ + !, -/. -
(B.32)
The influence of tire inclination i.e. camber angle, remains to be taken into account. a simple
linear expression for the equivalent slip angle is given by
1
/0 *2 41 3 2
1 3 is an empirically derived property of the tire.
where the relative camber stiffness
(B.33)
B.2 Applicable formulas
For the vehicle simulation, we will need equations B.28 and B.29. In addition, to calculate these
two, we also need Equations B.31 and B.32.
Assume we know the longitudinal and lateral slip, then also the slip angle can be calculated.
With this and the wheel spin speed also the slip ratio can be derived with Equation B.3.
With this, first the Equations for longitudinal slip ratio, slip velocity and friction will be calculated
as
65 879;!
: <
(B.34)
+
)*$ + ! , -/. & (' $ )*$ (B.35)
(B.36)
With these auxiliary variables, the longitudinal and lateral slip coefficient can be calculated by
using Equations B.28 and B.29. Also the total normalized slip can be derived with Equation B.18c,
recall
$ (B.37)
= 120
Slipangle
200
150
100
Slipangle
150
0
15
30
45
0
15
30
45
100
Lateral Force (µ.Fz)
Longitudinal Force (µ.Fz)
50
50
0
−50
0
−50
−100
−100
−150
−150
−200
−1
−0.8
−0.6
−0.4
−0.2
0
Slipratio
0.2
0.4
0.6
0.8
1
−200
−1
−0.8
−0.6
−0.4
−0.2
0
Slipratio
0.2
0.4
0.6
0.8
1
Figure B.3: Longitudinal and lateral normalized slip forces for different slip angles across slip
ratio.
>
> E F G ?>
?A> @C
B
D
HI JK I L MN(O P
O [email protected]
S O T/U ?/T
(B.38)
(B.39)
The above Equations will be the basis for deriving the effect of slip on the motion of the vehicle.
They are all normalized and depend on road friction, tire stiffnesses, and quantities describing the
material and geometric properties of the road surface and any interface contaminants. To convert
these coefficients to the actual shear> forces, we need one more > step where we multiply with the
normal pressure of the tire on the road surface.
/J V W X Y Z [;@]_ \^
^`
J/V W X Y Z [email protected] _ \^
> >
>
If we substitute for O , ? and O
Q
^`
>
O > HI JK=I
>
M
O
O> Q H(fgMN h O Qi I JK I
>
?/> HI JK I
>
? H(f%MN M I JK I
hOQ i
OQ
for O
> Q(acb%d e
for O >
Q(jcb%d e
for O
> Qlacb%d e
for O
Qljcb%d e
(B.40)
(B.41)
>
then this can be written in a more direct way, as
VO
BM(
>
>
_
J/V W X Y Z [;@ \^^ N O V O
B O P O Q %f MN h O M Q i
L
M
l
N
^`
BDME N(F G O ?>
>
_
J/V W X Y Z [email protected] \^
? f
M
Q i
^^` L BMDNlE F O G P O Q MN h O for O
> Qlacb%d e
for O > Qljcb%d e
for O
(B.42)
> Qlacb%d e
for O Qljcb%d e
(B.43)
121
Wheelspeed
200
50
100
50
z
z
Longitudinal Force (µ.F )
100
0
48
96
144
192
240
150
Lateral Force (µ.F )
150
Wheelspeed
200
0
48
96
144
192
240
0
0
−50
−50
−100
−100
−150
−150
−200
−50
−40
−30
−20
−10
0
10
Slipangle (deg)
20
30
40
50
−200
−50
−40
−30
−20
−10
0
10
Slipangle (deg)
20
30
40
50
Figure B.4: Longitudinal and lateral slip against slip angle.
a Sweep analysis for slip ratio and slip angle can simulate the model and will give an impression
of the behaviour of the resulting shear forces. Figures B.3 and B.4 show that the model output
compares well with the graphs belonging to the Dugoff slip model, which are shown in [16]. The
simulation can be represented in another form, where m%n is plotted against op;q . This is shown
in Figure B.5 where the vertical axis represents the vehicle velocity m%n and the horizontal axis
represents the wheel spin velocity op;q .
Notice that the graphs show the normalized shear forces in the vertical axis. A complete study can
be done for different nominal r -coefficients and tire stiffnesses and other parameters, to tune the
curves accordingly. The paper of H. Dugoff is referred to for more intensive study.
B.3 Considerations
The principal simplifying assumptions involved in the tire mechanics analysis are as follows
1. Dynamic effects are negligible. This means that the dependance of the tire shear force on
the time derivatives of the kinematic variables is not significant.
2. The deformation of the carcass centerline is constant throughout the contact patch. For
the freely rolling tire Fiala assumes that the carcass centerline behaves as an elastically
supported beam.
3. The deformation of the thread centerline is the resultant of two independant orthogonal
components.
4. The vertical load supported by the tire is evenly distributed over the contact patch. This
assumption is fairly realistic, except for the edges of the contact patch.
5. Aft of the point at which sliding between tread and road begins, tread deformation remains
uniform. This greatly reduces the mathematical complexity of the analysis. This assumption
122
Polar representation of the Dugoff friction model
4000
3000
2000
vv
1000
0
−1000
−2000
−3000
−4000
−4000
−3000
−2000
−1000
0
v
1000
2000
3000
4000
w
Figure B.5: Polar representation of the longitudinal and lateral slip.
causes a slight error in the direction of the shear force.
6. The interfacial friction coefficient is independant of normal pressure and is a linear function
of the relative sliding velocity.
Appendix C
Coordinate Systems
In this Appendix presents the coordinate systems and transformations for the geometry of the
chassis and wheels. There are many schemes for coordinate systems depending on the discipline
and applications. We will adopt the coordinate frames shown in Fig. C.1. The coordinate system is
widely used in aeronautical engineering in the analysis of missiles and space vehicle [22] as well as
by the Society of Automotive Engineers in automotive engineering in the analysis of automobiles
[24].
For ease of reference and tractability, we adopt the following notation for a vector
t .
s
Ref. Operation
Fn,Corner
t
s
and a matrix
Operation
To frame
For example, when the i-frame i rotated with respect to the o-frame, then vector u
will be defined in the o-frame as
w
v
in the i-frame
w
vx
y u u v;x
yz u v
and a force vector for v { | | in the vehicle reference frame }
w ‚‚ ƒ„
(C.1)
for corner ~ will be denoted by
 €
(C.2)
C.1 Displacement Coordinate Transformations
The following vectors are related to each other through translation and rotational transformation.
Referring to Figure C.1 we have
123
124
X1
Displacement Variables
x: translation along X 0 (Latitude or side to side)
y: translation along Y1 (Longitude or fore -aft)
z: translation along Z2 (Elevation or heave)
: rotation about Z3 (Heading or yaw)
: rotation along Y4 (Attitude or pitch)
: rotation along X5 (Bank or boll)
O1
x
X0
O0
y
Y1
fx
Z1
fy
Ž
Z2
R-frame
z
fz
Forces and Torques
f x : force along X 0
f y : force along Y1
f z : force along Z2
: torque about Z3
 ‘’ : torque along Y
  : torque along X
“
Velocity Variables
x: linear velocity along X 0
y: linear velocity along Y1
z: linear velocity along Z2
: angular velocity about Z3
X3
O3

Œ
Y2
Y0
Z0
X2
O2
“
Œ “
“
: angular velocity along Y
Ž“
Y3
4
Z3

Œ ,
Œ“ , “
…† ‡
4
5
Note: The origins O3, O4, O5
and O6 are the same point in
space. They are drawn as
separate points here to
illustrate the Euler angles.
“
O4
: angular velocity along X5
Ž
Ž“
and are the Euler angles.
and are the Euler angular velocities.
X6
X4
Y4
Š† ‹
ˆ† ‰
Z4
O6
X5
O5
Y6
R-frame: Reference Frame
B-frame: Body-attached Frame
Y5
Z5
Figure C.1: Coordinate frames from reference to body.
Fi gure A. 1 Coordi nate Fr ames fro m Ref erence to Body
Z6
B-frame
125
”4—˜™š›  ž
” •–
œ
—˜™š›
•– £
œ
£
±
±
¶
•–
•–
¶
—˜™ š›
—˜™ š›
œ
œ
”4—˜™4š  ž
—˜™š›  ž
– ”• ¡
Ÿ –
Ÿ¢¡l£
Ÿ ¤
œ
±
ž
—˜™¦¥ § ¨*©«ª¢¨ ¬ ­©  ž
¨ ¬ ­ ©®¥ § °
¨g© ¯
Ÿ – £
Ÿ/±
±
¶
ž
¨*³ ¯µ
¨ ¬ ­
—˜™ ¥ § ´
³ ž
Ÿ –
ª¢¨ ¬ ­³
¥ § ¨*³ Ÿ¶
¶ ¯· »
ž
ž
—˜™ ¥
§
g
¨
¹
¸
¢
ª
¨
¬
­
¸
Ÿ –
¨ ¬ ­¸º¥ § ¨g¸ Ÿ»
£
•
(C.3)
—˜™š›  ž
œ
Ÿ –
—˜™ š›  ž
œ
Ÿ –
—˜™ š›  ž
œ
Ÿ –
The overall translation of a point ¼ with reference to the ½ -frame in the
given by
” •–À” • %” Á% ¡
¾
where
»
–
» »
£²
•
± ±
£²
± ¶ ¶
²
¶ » »
²
½ ¾¿
•
•
(C.4)
•
(C.5)
(C.6)
coordinate system is
(C.7)
± ± ¶ ¶ »
—˜™¦
³Ãª¢¨ ¬ ­©4¥ § ¨*¸ ¥ § ¨*©¨ ¬ ­³/¨ ¬ ­¸º¨ ¬ ­©¨ ¬ ­¸ ¥ § ¨g©¨ ¬ ­³/¥ § g¨ ¸  ž
£ ² ¥ ¨ §¬ ­¨*©
²©¥ ¥ § § ¨*¨g² ³C
¥ § ¨g©¥ § ¨g¸ ¡ ¨ ¬ ­©¨ ¬ ­³/¨ ¬ ­¸Äª¢¥ § ¨*©4¨ ¬ ­¸ ¡ ¨ ¬ ­©¨ ¬ ­³/¥ § *¨ ¸
–
Ÿ
ª¢¨ ¬ ­³
¥ § ¡ ¨*³/¨ ¬ ­¸
¥ § ¨g¡ ³/¥ § ¨*¸
–ÆÅ
›
£ Ç Èc£ Ç ÉÊ£ Ç Ë Ì
šÍª ª œ
whose columns are unit vectors along the
axes of the Î ¾ ¿ frame, when reference from
the Ï Ð Ñ frame. Since the rotational matrices are orthogonal, we note that
±
±
±
¶ ± – ± ± – ± ¶
» ² £¶ – £¶ ²¦¶ÒgÓ – £¶ ²Ô »
² – ²¦ÒgÓ – ²Ô
²
²¦ÒgÓ
²Ô
£²
and
126
Õ Ö×ØÀÕ Ö¦× ÙgÚ Ø × Ö Û Õ ØÀÜ ÖÛ ÕÝ Ö ÛÜ × Ö Û Ø¤Õ Ö Ü Ü Ö Ý Ö×
(C.8)
Ý
Ý
where the superscript Þ denotes the transpose operation on the matrix. We should note that
ßÖ Õ Ø ×Ö Õ
(C.9)
C.2 Angular Velocity Coordinate Transformation
Two equivalent vectors can be used to describe the angular velocity of a body B. They are:
1.
2.
æ
Õ à/á
is the angular rates of the â
Ø ç ê é ë é ì/é í Û
à/á è
-frame with respect to the ã
äå
frame,
is the Euler angular rates as can be seen from Figure C.1.
There are many ways to transform from instantaneous angular rates to Euler rates [15]. The
angular velocities of the ã ä å frame can be expressed in terms of the Euler angles and angular rates
as follows
Õ4îïð à/ñ
Õ à/á Ø
à/ò ØÀÕ Ö
à/ó¢öô õ
îïð¢ù
÷
÷ÿþ û ê
Ø
÷Ãú¢û ü ý ê
Ø Õ
à/á
æ
æ
Ü ÜÖ Ý
ú¢û ü ý
û üý ê þ
þ û ê þ
Ý Ö×
îïðR÷
÷
öô õ ø
ìé ¢
îïð ê é
ë
û ë
ëé
û ë öô õ ì é öô õ
ÕÖ Ü ÜÖ
Ý
îïð4÷
îïð ê é
ë é öÍø Õ Ö Ü ÷ ö
÷ ôõ
÷ ôõ
where the transformation matrix is
îïðÍù
Õ Ø ÷
÷
æ
÷
þ û ê
ú¢û ü ý ê
ú¢û ü ý ë
û üý ê þ û ë
þ û ê þ û ë öô õ
Conversely, we can show that the Euler angular rates are related to the ã
îïð ê é
îïðÍù û ü ý ê þ û ê
à/á Ø
ëé ö Ø ÷
æ
÷ û üý ê û ì é ôõ
ØÕ gÙ Ú Õ à/á Ø Õ
æ
æ (C.10)
äå
frame rates as
ý ë þ û ê ý ë Õ4îïð /à ñ
ú¢û ü ý ê
/à ò
þ ë þ û ê û þ ë öô õ
/à ó¢ôö õ
Õ à/á
127
where
+,
$ ! " # (C.11)
" %
&' $
( ) * " % ) Note that we can determine the angular velocities of the . / 0 frame with reference to the 1 2 3 frame
as follows
4
4 56 57 + ,
5 7 + ,
5 8 4 : 5 6 4; < 7=< 8>< 9 ? 5 8
59 5 9 -
(C.12)
C.3 Angular Displacement
The Euler angles (roll, pitch and yaw) are simply given by
@ 6 =A 56CB D
(C.13)
where
@ 6 ;
=E
?F
(C.14)
C.4 Linear Velocity Coordinate Transformation
The linear velocity of the 1
23
$ / 0 frame is
KI +,
G H 4 G%J I L I
2
MI
frame with respect to the
while the linear velocity of a point N on a rotating 1
by
PJQ
BD
4: 4JQU B
BD
P IH 4VT 4 : W 4 J Q T 4 :
B
P H Q P JIQ BSR P J 4T
23
frame with respect to the O
B R 4: U 4 Q 4: B 4JQ
PJ4 S
J T
BD T
BD
BD
H Q
(C.15)
/0
frame is given
128
Euler Angles
Only three differential equations are
needed
Direct initialization from , and
X Y
Z
Direct cosines
Differential equations are linear
No singularities
Transformation matrix can be calculated directly
Quaternions
Only four linear coupled differential
equations are needed
No singularities. It avoids the gimbal lock problem associated with
Euler angles
Computationally simple
Differential equations are non-linear
Singularity occurs as the angles apo
proach
which is called Gimbal
Lock
Transformation matrix is not directly
available
Order of rotation is important
Nine linear differential equations (reducible to six)
Euler angles are not directly available,
which is required for initial calculations
Computational burden
[\ ]
Initial calculations using the Euler
angles is required if coordinate systems
do not coincide at
Euler angles are not readily available
^_`]
Transformation matrix not directly
available
Table C.1: Advantages and disadvantages of the three most used transformation methods.
where the useful relationship below for the time derivative of the transformation matrix
}~
has been used.
aSb#c dSe f c dSejVklj
a gih
hmnoqpsrtuvtw 
tuxpyrtz
rtw{tz|p
(C.16)
C.5 Coordinate Systems
Since the direct cosines transformation is computationally intensive, it is disadvantageous for the
real-time application of VVSS. Like the quaternion method, it also has the Euler angles not readily
available. The latter argument is decisive for the engineering aspect of the VVSS.
129
The transformation matrix is not directly available for Euler angle transformations, but is computed
throught the Silicon Graphics hardware facility.
Appendix D
Software Reference
This appendix explains the use and operation procedure of the VVSS. The software is merely
a collection of codes that implements the functionality of simulating vehicle dynamics through
SPINE.
The following sections are structured chronologically. After the layout of the relevant files and
folders, the usage and features of the software are explained. The last section will illustrate the use
of the VVSS and SPINE in conjunction with Simulink, to analyze and design vehicle subsystems.
D.1 File Structure
The simulation platform that is presented in this dissertation is implemented in a software application that resides in a series of folders. The
VVSS is implemented in a Silicon Graphics computer.
The application folder contains the source codes plus a makefile, that is
used for building the executable code. The subfolder /scene contains
the geometry files for the graphical virtual realistic environment. This
directory structure is crucial for the simulator to operate.
The parallel simulation through SPINE is implemented for Simulink. However, the connectivity
and protocol between in SPINE allows for many operating systems and simulation software tools
that support TCP/IP, to communicate with the VVSS. Appendix E details about the handshaking
and protocol that is needed to develop the interface drivers.
The software structure for Simulink is not strictly defined. The minimum requirement is that the
source code and the library for the SPINE driver need to be in the matlab search path, when a
simulation is started. A simulink library called vvsslib (See Figure D.2) is provided which
contains the necessary blockset to develop subsystems for the VVSS. When the force wheel
130
131
peripheral control block is used for user inputs to the vehicle simulation, then also the source code
and library for the peripherals driver need to be in the matlab search path. Table D.1 shows the list
of files that are associated with the VVSS and SPINE.
Filename
towndyn.C
vd.h
plugins.h
cb.h
perf.h
fw.cpp
fw.dll
splugin.cpp
splugin.dll
map.mat
vc.m
console.m
road.m
road.asc
Description
Source code for VVSS. Contains the vehicle dynamics code.
Include file for the VVSS with the initialization of the vector table and
vehicle parapeters.
VVSS header file with SPINE communication functions and the functions and initializationfor the graphical user interface
VVSS header file with driver routines for the Cereal Box €
VVSS header file with graphcs scenery definition routines
Force wheel driver source for Simulink
Force wheel driver dynamic link library
SPINE driver source code for Simulink
SPINE driver dynamic link library
This file is used with the navigation block in the library
Matlab script used with the navigation block in the library
Matlab script used with the dashboard in the library
Matlab script to generate a test-track definition file
Test track definition file for default world scenery
Table D.1: The list of file names with a short description, of the files that are associated with the
VVSS and SPINE.
The VVSS software furthermore uses support from the xforms library and the Performer
graphics developing environment.
D.2 User Interface
Each user on the Silicon Graphics host computer that executes the VVSS, can start the simulator
by typing VV on the command line. The command will change the prompt to the application folder
/usr2/VVSS/. From there it will execute the vehicle simulation.
Command Line Options
Command line options are a series of space-separated specific characters with a trailing dash and
optionally an additional property value. These characters access features and properties that can
 The Cereal Box is a product of BG Systems, Inc.
132
be selected to configure the simulation at startup time. The following paragraphs summarize the
available options and their meaning.
-b Block VVSS communication. If this option is provided, the VVSS will wait for the parallel
processes that are connected to the VVSS through SPINE, each frame, before it continues
to simulate.
-u # Define the subsampling ‚ . Subsampling # is the amount of simulation cycles that are
computed per frame. The graphics update and the data exchange through SPINE takes place
once per frame. Setting ‚'ƒ…„ , together with the option ‘-b’ will guarantee the data exchange
through SPINE at each integration step.
-f Full screen display. By default the VVSS will display the animation in a resizable X-windows
frame.
-3 Display the animation in stereo vision. Make sure that the stereo scopic goggles are in line-ofsight with the synch. emmitters.
-i # Set the interocular distance of the eyes for stereo vision to #. Only effective with option ‘-3’.
-c # Set the convergence ratio of the left and right eye for stereo vision to #. Only effective with
option ‘-3’.
-s Small video (for remote simulation studies)
-g Add Graphical User Interface in Figure D.1. By default the GUI will not show up.
-w # Load virtual world number # at initialization time. The option ‘-w’ for world environment,
will load one of the sceneries in the animation of the simulation output. The geometry data
for the sceneries resides under the folder /scene/ in the application folder.
If the option ‘-w’ is not provided, a flat terrain is loaded, with an optional road surface
trajectory defined in the file road.asc. Section D.2 explains in more detail about the
trajectory file.
-h Short command line help that will diaplsy the command line options.
Key Press Functions
When the simulation is active, certain keys have special functionality for the simulation. Table
D.3 shows a summary of the available functions for keys.
Further development of the VVSS will include key-press functions for re-loading a test-track in
the virtual scenery and for re-configuring the vehicle to another platform in run-time.
133
Index
1
2
3
4
5
6
Scenery
The “Performer town” demonstration model
A stripped down version of the “Performer town” model
Formula 1 racetrack
Large rugged world scene
Simple city of San Francisco with Bridge
20 Miles of Country, city, village and highway
Table D.2: Available command-line options with the functionality.
Key
v
s
g
f
†
‡
ˆ
‰
Š ‹
..
Function
Toggle the graphics viewpoint from the driver’s view to a chase view
Statistics for the simulation and graphics are available with this key
When the command line option ‘-g’ is provided this key toggles the GUI
Toggle Fog in the virtual scenery. Fog is configured in the source code
Move C.G. to the front in the vehicle
Move C.G. to the back in the vehicle
Move C.G. to the left in the vehicle
Move C.G. to the right in the vehicle
Š.Œ
The first four function keys restart the simulation in another location
Esc
Spc
The Escape key exits the VVSS. All SPINE connections will be closed.
Pressing the Space-bar will dump the current position and heading
Table D.3: Available Key-press options with the functionality.
134
Figure D.1: Image of the graphical user interface for the Virtual Vehicle System Simulator.
Graphical User Interface
The command-line option ‘-g’ adds the feature of additional graphical user interface (gui) controls
to the VVSS. The interface controls will initially be hidden behind the scenery, but can be brought
to the front by pressing ‘g’ (toggle).
A screen shot of the gui is shown in Figure D.1. The upper area serves as an indication for the
active parallel processes on the VVSS through SPINE.
Three indicated buttons are available for toggling statistics, fog and driver’s view. These features
are available via key-press functions as well (resp. ‘s’, ‘f’, and ‘v’). The right side of the gui
provides a slider for changing the sprung mas of the vehicle and for changing the  -coeficient
(friction) of the terrain. (The third slider is not yet assigned). In the bottom of the gui is an ‘Exit’
button that terminates the simulations.
Simulation Definition Files
The default virtual environment is a world scenery with a flat terrain, bounded at considerable
distance with a mountain range. A configurable test-track can be added to the terrain.
The track is defined in the text file road.asc, in three columns for road center coordinates
Ž ,  and an altitude. The file must be located in the subfolder /scene/testtrack/ of the
application folder of the VVSS. The road will be 10 m| wide and will be created as polygons that
connect the road points. As a sample,
135
Road : Sine Wave. Mu = 0.9
0.000000 0.000000 0.000000
1.000000 0.000000 0.003365
2.000000 0.000000 0.013308
3.000000 0.000000 0.029384
4.000000 0.000000 0.050870
5.000000 0.000000 0.076804
6.000000 0.000000 0.106022
The file road.m is a Matlab script file that will generate a test-track file and store it in the
appropriate folder for the VVSS. It will be possible to re-configure the test-track in future revisions
of the VVSS.
Other extensions to the VVSS will provide for a configuration file for the vehicle and for the virtual
scenery. The configuration file for the vehicle will have the name of the vehicle with extension
.def and hold the parameter values that characterize a particular platform. The system will be
able to load another vehicle configuration file in run-time.
D.3 Prototyping with Simulink
A Library with a blockset of communication modules for SPINE is provided for designing subsystems in Simulink. Figure D.2 shows the blockset.
Read Scalar Connection input for reading a scalar value from the VVSS. In the property dialog
box is an input for the index value that represents the value that is to be read.
Write Scalar Connection input for sending a scalar value to the VVSS. In the property dialog
box is an input for the index value that represents the value that is to be sent.
Read Vector Connection input for reading a vector from the VVSS. In the property dialog box is
an input for the index value that represents the vector that is to be read.
136
Virtual Vehicle Systems Simulation
VVSS Read
Read Scalar
Shift Up
Shift Down
VVSS Write
Write Scalar
Mini
World
Button Right
Navigation Map
Button Left
VVSS Read
Lever Right
VVSS Write
INFO
Lever Left
Read Vector
DASHBOARD
VVSS Dashboard
Force Wheel Control
Write Vector
Components Information
© 1998 Oakland University. By G. E. Smid & Ka C. Cheok
Department of Electrical and Systems Engineering
General Dynamics Laboratory
Figure D.2: The VVSS library in Simulink with the blockset that provides the necessary functionality for SPINE.
The output of this block is a 3x1 vector. Access the individual values by de-multiplexing
the signal first.
Write Vector Connection input for sending a vector to the VVSS. In the property dialog box is
an input for the index value that represents the vector that is to be sent.
The input of this block must be a 3x1 vector. Combine the individual values by multiplexing
the signals first.
Dashboard A simple dashboard console can be added to the user interface in Simulink. The
dashboard contains a speedometer and a gauge for rpm. When this block is inserted in the
Simulink diagram, the file console.m must be available in the Matlan search path.
Force Wheel Control The Saitek Forcewheel can be used as an input peripheral for the vehicle
simulation. The block can be inserted into the Simulink diagram without any further
configuration. The files fw.cpp and fw.dll must be in the matlab search path.
Navigation Map The Navigation map can be inserted in a Simulink diagram, to study navigation
and inertia systems. It will display a graphical map of the world, with a white trace that
137
represents the location of the vehicle. The files map.mat and vc.m must reside in the
Matlab search path.
Only world 1 or 2 are supported for Naviagtion map at this time.
Components Information This is an online information block, which contains the component
index. It is a reference to the engineer when designing a Simulink model. The possible
index values and their is also listed in Tables E.3 and E.4.
The model in Simulink will receive values for the input parameters and states through SPINE
from the VVSS at each frame interval. The VVSS is currently configured to compute 7 cycles
with an integration step of 0.004 seconds per frame. The Simulink model will thus communicate
at an integration step size of 0.028 seconds. Currently this value is not configurable. Further
development of SPINE will allow the VVSS to configure the SPINE driver module to configure
the Simulink model with the appropriate interval size.
The SPINE driver module will configure an independant fixed clock cycle in Simulink. Therefore
the user will be more free to configure the integration method and timing in Simulink. The user is
limited in the way that a fixed integration interval must be either a multiple or a divider of 0.028
seconds.
Appendix E
Development and Implementation
The simulation structure that is presented in this dissertation involves many aspects of software
implementation. For the purpose of reference and development, the sections in this appendix will
present the construction and functionality of the various software components, implementation of
the software, communication protocols, parameters and vehicle dynamics.
E.1 Geometry models
Section 5.5 explained the global geometry structure, as it is represented in the animation part of
the software. Geometry models are simply loaded in memory and added to the graphics models
tree structure. The following code example illustrates how this procedure takes place.
pfFilePath("./scene");
pfdInitConverter("myworld.flt");
shared->town = (pfGroup *);
pfdLoadFile("myworld.flt"));
shared->root->addChild(shared->town);
The pointer shared-> points to an area of allocated shared memory where the graphics models
reside.
A series of different data file formats can be used for the geometry models. Table E.1 lists the
allowable formats.
Geometry models can be designed with a variety of applications. Among them are products from
MultiGen, ViewPoint, Coruphaeus, Pro-Engineer, AutoCad and Silicon Graphics. The models that
are currently used for the animation of the vehicle dynamics are part of the Performer Development
sample library.
Future additions to the VVSS will provide for a more flexible scene definition file, in which the
available world sceneries can be defined.
138
139
File Formats
Coryphaeus
Imagis
Inventor
Viewpoint
MultiGen
Unigraphics
Autocad
Paradigm
Silicon Graphics
Objects
Virtual Reality Macro Language
dwb
iv
iv
flt
dxf
pfb
iris
obj
vrml
Table E.1: Overview of the file formats that can be loaded into the geometry tree of VVSS.
E.2 Initialization procedures
This section will consist of a walk-through of the initialization procedure of the VVSS. A number
of data structures have to be configured and tasks have to be performed before the VVSS can start
executing the main simulation cycle.


First, the command line options need to be interpreted. Internal variables will be redefined
from their default values to provide the requested options.

If the VVSS code has been compiled with the support for the Cereal Box, then the serial
port will be initialized and communication with the peripheral will be established
To reset the Cereal Box, the VVSS will send a ‘T’ to the serial port. Then a bit-pattern will
be sent to the port which represents the input-output data exchange format, to reflect the
signals that are needed for the vehicle dynamics as inputs.
The VVSS then allocates memory for the values of parameters and states of the vehicle
dynamics. In conjunction with each memory location, a vector will be assigned to it, and
referenced in the Component Library Index ‘ . The functionality of the Library and the
vectors was presented in Chapter 5.
Additionally to allocating the memory, the VVSS will assign default values to the vehicle
parameters.
Future revisions of the VVSS propose to store these default parameter values in a vehicle
definition file that will configure the vehicle dynamics parameters, such that they characterize
a particular platform.
’
140
A special set of commands are available in the Performer Development Library, that help
to setup the graphics scenery and prepare the hardware for animation. The following code
example illustrates a general initialization phase.
pfInit();
pfMultiprocess( PFMP DEFAULT );
arena = pfGetSharedArena();
shared = (SharedData *)
pfMalloc(sizeof(SharedData),arena);
pfConfig();
pfiInit();
shared->scene = new pfScene();
shared->root = new pfGroup();
shared->dcscar = new pfDCS;
/* Configure GL window and setup stereo */
p = pfGetPipe(0);
pfFrameRate(FRAME RATE);
pfPhase(PHASE);
pw = new pfPipeWindow(p);
pw->setWinType(PFPWIN TYPE X);
pw->setName("Virtual Race Track");
if (CLfull) pw->setFullScreen();
else pw->setOriginSize(0, 200, 1100, 600);
pw->setConfigFunc(OpenPipeWin);
pw->config();
When the graphics object tree structure has been defined, the dynamics coordinate systems
can be adjusted in the simulation loop, with the following commands.
141
Body2Wheel.makeEuler(theta w, 0.0, omega w);
Body2Wheel.postTrans(Body2Wheel, x, y, z);
shared->wheelCS[i]->setMat(Body2Wheel);
Vehicle2Earth.preTrans(x, y, z, Vehicle2Earth);
shared->dcscar->setMat(Vehicle2Earth);
“
shared->view.hpr.set(alpha[PF Z], beta[PF Y],
gamma[PF X]);
shared->view.xyz.set(x, y, z);
“
The simulation must be initialized, before the VVSS can render the first graphic state of the
solution to the vehicle dynamics model. This task involves the initialization of the states
and transformation matrices and the scene viewpoint.
If the user has selected the option ‘-g’ for the graphical user interface (See Figure D.1), it
will be initialized at this point. The VVSS makes use of the xforms library to design the
interface in a X-window.
“
Besides rendering the user controls, also the functions will be setup that will provide the
run-time functionality of the GUI. The key ‘g’ can be used to toggle the GUI to be in front
or behind the animation.
“
The command pfFrame() will be issued to render the first scene.
The final task before entering the simulation process is to initialize SPINE. This task involves
the configuration of the network protocol for TCP/IP and setting up a service to a custom
port that is user for SPINE only. The following code example shows briefly the initialization
procedure.
Additional information on controlling the network communication adaptors with TCP/IP
protocol can be found in [60].
The exact sequence of the initialization steps is not strictly defined. However, some tasks need
other tasks to be completed, which makes the presented process not arbitrary.
E.3 Main algorithmic cycle
When the initialization process has been completed successfully, the VVSS will start executing
the main simulation loop. The loop will only break, when the Escape key or the exit button in the
GUI is pressed. The simulation loop is executed at the frame rate for the video rendering. The
task list inside the frame cycle is as follows:
142
”
”
When the Cereal Box is used for communicating user inputs to the simulation, it is accessed
here to receive new input values.
”
Compute the new solution of the vehicle dynamics. Execute this task • times, where • holds
the value for supersampling.
”
Update the coordinate system for all dynamic components in the graphic scenery. Rendering
these updates encompasses the animation of the solution of the simulation.
Process the communication task with parallel simulations on SPINE.
– Communicate with the simulation processes that are running in parallel with the VVSS.
The communication involves sending the current solution for the states that are used
in the remote model, and receiving the current solution of the states from the remote
model.
– Check is there are any new requests for additional processes on SPINE. If so, initialize
communication with these processes.
The flow diagram for initialization and the simulation cycle is shown in Figure E.1.
E.4 Vehicle Dynamics Implementation
The solution of the vehicle dynamics model for each integration cycle is computed by solving a set
of mathematical equations. The equations are implemented in the code of the VVSS and computed
sequentially. The following is the summary of the equations as they appear in the VVSS.
– —(˜™š– ›œ œ —(˜
– (˜%™ Isect ž Ÿ – —(˜ ¢• ¡ ¢¤#£ ¥
¦ § ™…¨ª© – —(˜%¨«– (˜ © ¬®­¯ª¨ ¦ ¯¬®­ §
¦ ° §#± ² ³ ™µ´¶ Ÿ ¦ §#± ² ³ ¨ ¦ §#± ² ¥
ž
ž
¾¿
œ · § ™¸¹º
»
» ½ § ¦°§ À
¼ §¦ § ¬>
¦ Á ¯™ÃÄ Â § œ · §#± Å ± ² ³ ¨ÆÄ Â § œ · ¯ ± Å ± ² ¨ œ Ç
ž
È The intersectioning function Isect returns the 3D coordinate of the point where intersection takes place.
case the location is where a vertical line vector at the wheel location hits the terrain surface.
In this
143
Silicon Graphics ONYX
Interpret command-line
Initialize Cereal-box comm.
Setup component index library
Initialize Virtual Environment
and Graphics Engine.
Create states and viewpoint.
Initialize
Graphical User Interface
PC-Pentium 300
É
Initialize
system module plugin server
SPINE
Initialize Client
Î
Submit
Shared Memory
Request form
Ê
Process Inputs from
Driver Interface peripherals
Ï
Ë
Receive
Shared Memory form
n Compute Vehicle Dynamics
Í
Update Graphics Environment
n
Ð
Compute
Subsystem
Dynamics
ÌProcess clients:
Check for new modules
Receive module State(s)
Send
Module State(s)
Send Shared Memory form
Figure E.1: Software flow model for Multi-CPU Simulation.
144
Ò Ñ Ó Ô Õ Ö#×Ø Ò Ñ Ó Ô ÕÙÛÚÜÞÝ Ò ß Ó Ô Õ Ö#×Ù…Ò ß Ó Ô Õ à
Ò Ó Ô Õ Ö#×Ø=Ò Ó Ô ÕÙÛÚÜÞÝ Ò Ñ Ó Ô Õ Ö#×Ù Ò Ñ Ó Ô Õ à
ëì
ç
á â%ã Øåæä
ç éêÓ Ò Ñ Ó í
¢
Ó
Ò
Ó
>
Ù
è
á âî ï ð ð Ô ñØ èêò Ò Ó Ô ñ%õó`öøÒ Ó ÷ Ô ñ ô%×
ï âù ð ñ úSØ
÷ û üSý
Dugoff
ï
ó Ò ã ý Ù õ Ù õ
ßþ ؅ó âù ð ñ ú Ô ÿ û ã `
þ Ñ Õ Ö#×Ø þ Ñ ÕÙÛÚÜ û ßþ Õ Ö#×Vó ßþ Õ ý
þ Õ Ö#×Ø þ ÕÙ ÚÜ û þ Ñ Õ Ö#×Vó þ Ñ Õ ý
ï
ëì ï
ñØ ü á á ñ%ó äåæ
ç
ÓªçóÞÒ Ó í á âù ð ñ ú Ô ñØ á ü âù ð ñ ú Ô ñ
û ñ õ ó û ý ý
Ñ Ø
Õ Ö#×VØ
ÕÙÛÚÜÞÝ Ñ Õ Ö#×Vó Ñ Õ à
ëì
ÿ ÿ
Ñ Øåæ
ä ÿ ! "$# % ó !ÿ " í
# % ÿ &
ÿ ç
'
#
(
"
#
%
&
' # "
ç
Ñ
Õ Ö#×VØ ÕÙ Ú Ü Ý Õ Ö#×Vó Ñ Õ à
ï Ø ïü
)ß
á *+
ñ ,
6
ëì
û á âù 3 ù úÙ á âî ï ð ð ý 4 ó åæä ç
ï ç5 í
ï Ñ Õ Ö#×VØ ï Ñ ÕÙÛÚÜ û ï Õ Ö#×Vó ï Õ ý
)
)
)ß
)ß
ï Õ Ö#×VØ ï ÕÙ ÚÜ û ï Ñ Õ Ö#×Vó ï Ñ Õ ý
)
)
)
)
.0/ Ù2 1 .
ã á âù ð ñ ú(Ù
.0 /
The tire slip forces are computed in the non-linear function Dugoff. The equations for the tire model can be found
in Chapter 3
145
Pentium PC - Workstations
MATLAB Environment
SGI ONYX - Workstation
IRIX Performer Development
7
Vehicle Dynamics
Graphical Animation
Simulink Model
Control Diagram
7
Vehicle Dynamics
Mathematical Simulation
DDE
Dynamic Linked Library
TCP/IP
Shared Memory Server
TCP/IP
Figure E.2: Hardware setup of the Simulation Platform with Integrated Network.
E.5 SPINE - server (VVSS)
During the initialization phase, the VVSS will setup a server application that allows other simulation
processes to communicate with the vehicle dynamics through SPINE. The server utilizes the TCP/IP
protocol with a custom port number that is not reserved for any of the standard internet applications
([60]).
The following lines of code implement the server initialization task.
serv fd=socket(AF INET,SOCK STREAM,0);
gethostname(server hostname,sizeof(server hostname));
printf("host name = [%s]",server hostname);
server host=gethostbyname(server hostname);
bzero((char *)&server addr,sizeof(server addr));
server addr.sin family = AF INET;
server addr.sin port = htons(PORT NO);
memcpy((char*)&server addr.sin addr,
(char*)server host->h addr,server host->h length);
bind(serv fd,&server addr,sizeof(server addr));
listen(serv fd,5);
Once the VVSS has entered the main simulation loop, it will make a call to the server once per
frame, to identify any new process requests. If it there is one, it will initialize communication with
the new process and store a handle to it in the list of active processes on SPINE. The list of active
146
processes can be monitored through the GUI.
The actions that are taken to initialize a process on SPINE are the following.
1. Create a new instance of the SPINE object and accept the file descriptor in a member of its
class. I.e.
Spine->plugin fd=accept(server fd,&plugin addr,&addr len);
2. Receive the first character string as the title of the process.
3. Receive a string representation of an index value. Store it in the request form and do the
following, depending on its value.
8 If the index is negative, return the value of the requested state or parameter.
8 If the index is positive, then store the vector of the state or parameter in a backup
vector. Allocate a new memory location and create a vector to it, which is stored in
the index library.
4. If the string representation of the latest input data was not terminated with the character ‘*’,
then more requests are expected. Return to step 3.
In the subsequent simulation cycles, the VVSS will communicate with the process through the
server, to exchange values for the requested parameters and states. Once per frame it will therefore
detect if new simulation output data has arrived. If not, it will predict the new values, as was
discussed in Section 6.5. If so, it will perform the following tasks to execute the exchange of data,
for each entry in the index request form.
8 If the request is for receiving data, store the values for the requested states or parameters in
the server output buffer.
8 If the request is for submitting data, then interpret the data in the server input buffer and
store it in the appropriate memory location.
To finalize the exchange of data for the cycle, a terminating ‘*’ will be stored in the server output
buffer.
When communication with a simulation process on SPINE is terminated, the following list of tasks
is executed to properly restore the state of the VVSS.
1. Close the network link, given by the file descriptor.
2. Restore the vectors for the states and parameters that were submitted by the remote process.
These vectors have been backed up in the communication initialization process. Then clear
the memory that was used for the submitted values.
3. Destroy the SPINE object and clean up the allocated work memory.
147
E.6 SPINE - client
On the side of the simulation process, there is a network driver that allows the simulation to communicate with the VVSS through SPINE. The initialization phase for setting up the communication
on the client side covers the following steps.
1. Create a new network communication link. The next lines of code encompass this task.
pSocket = new CAsyncSocket();
pSocket->Create();
pSocket->AsyncSelect(FD READ, FD WRITE, FD CLOSE);
pSocket->Connect(HOST, PORT NO);
2. Send the title of the simulation process to the VVSS
pSocket->Send(title, strlen(title, 0);
3. For each instance of a state or parameter input in the simulation model, submit the index to
the VVSS and receive the initial value for the input.
4. For each instance of a state or parameter output in the simulation model, submit the index
to the VVSS.
5. Terminate the initialization procedure by sending a ‘*’.
In the subsequent data exchange cycles with the VVSS, the simulation will send a vector of output
values with a terminating ‘*’ to the server process through SPINE, and wait for the list of new
values for the inputs.
The client process that is described in this section has been implemented for Simulink. Appendix
D explains how to use Simulink for simulating submodels of the vehicle system through SPINE.
However, any hardware processor that has the facility of communicating on a local area network,
using the TCP/IP protocol can be programmed to be connected to the SPINE.
E.7 Parameter Defaul Values
The VVSS will initialize the vehicle dynamics parameters to a set of default values, for the vehicle
simulation. The list in table E.2 is an overview of the parameters that characterize the vehicle
model for a particular platform.
Typically the values for many of these parameters is difficult to identify. Hence one of the main
concerns and most elaborate efforts for validating vehicle simulation data is to verify the accuracy
of the parameter values.
Future extensions to the VVSS will incorporate the facility for customizing a vehicle definition file
with the parameter values. The file can the be loaded into the simulation to customize the vehicle
or to select another platform.
148
Name
9 :
+
[email protected]:
9BA
?CA
DFE
HI
HJ
JK
L
O0K
O R
0
SA
ST:
UV
W V
XY
X[
U[
Default Value
4,000
15,000
4,000
150,000
300
1.62
1.62
0.3
9.81
40
800
0.3
0.5
1.225
1.225
40,000
10,000
0.03
Unit
;=<>
;=<
;=<>
;=<
G
<
<
<
<> M&N
P Q
P Q
<
<
<
<
Z
Z
1
Table E.2: Default Parameter Values.
149
Scalar elements
Throttle Angle
Brake Angle
Steering Angle
Traction
Sprung mass
Camera Zoom factor
Camera Azimuth value
Vector elements
Position
Velocity
Acceleration
Euler Angle (roll, pitch, yaw)
Euler Angle rate
Gyroscopic Angle rate
Gyroscopic Angle rate
Inertia (about x,y,z)
Center of Gravity
Index
01
02
03
10
50
998
999
Index
00
01
02
03
04
05
06
50
90
Name
\F] ^
\F_
` a bdc
eFf
g0h
Name
ij
i kj
lFj m
in
i nk
io
i ok
ph
a qBr
Table E.3: Reference table for the VVSS indexes.
E.8 State Reference Index Library
Chapter 5 introduced the concept of vectorized state values and parameters. The vector indices
are used as a reference to the actual values in the submodels that arew connected to SPINE. Tables
E.3 and E.4 present the summary of available vectors with their indices.
E.9 Peripherals and User Interfaces
The last section in this appendix gives an overview of the implementation of the tools and facilities
that the VVSS uses to interface with the user.
GUI and XForms
The graphical user interface is an optional X-windows based set of controls that are rendered in
a separate framed window in addition to the animation. The software uses commands from the
xforms library to create the controls and add functionality to the program.
The next code section is a sample of the definition commands for the initialization of the user
150
Scalar elements
Wheel spin acceleration
Wheel spin velocity
Wheel spin angle
Steering Angle
Tire deflection acceleration
Tire deflection rate
Tire deflection
Tire deflection elasticity
Tire deflection damping
Wheel radius (no load)
Suspension deflection acceleration
Suspension deflection rate
Suspension deflection
Suspension deflection elasticity
Suspension deflection damping
Wheel (unsprung) mass
Wheel (spin) inertia
Brake Torque
Drive (traction) Torque
Vector elements
Location A
Location B
Location C
Vehicle Velocity
Anchor Location
CG to Anchor vector
Additional suspension force
Suspension force
Tire deflection force
Slip force
Index
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
50
51
60
61
Index
00
01
02
05
10
11
49
50
51
52
Name
ts
tu
t
vx y w
s
xuy
xy
z y
y
{
|
xs } w
xu }
x}
z }
}
{ y
~
w
€
€ ‚
Name
ƒ„
ƒ…
Ġ
‡ ˆ u
‡„
‡ „Š‰‹‡ †BŒ
‡ Ž  Ž  ‘
‡ Ž  Ž 
‡ ’ “ ” •
‡ Ž • – 
Table E.4: Reference table for the VVSS indexes for the quarter vehicle corners. Add — ˜ ˜™ š to
each index to indicate wich corner is referred to. See Figure š for the corner referencing.
151
controls. The function *create_form_VVSS(void) is called in the initialization phase of
the VVSS.
FD_VVSS *create_form_VVSS(void) {
FL_OBJECT *obj;
FD_VVSS *fdui = (FD_VVSS *) fl_calloc(1, sizeof(*fdui));
fdui->VVSS = fl_bgn_form(FL_NO_BOX, 370, 400);
obj = fl_add_box(FL_UP_BOX,0,0,370,400,"");
fdui->hExit = obj = fl_add_button(FL_NORMAL_BUTTON,10,360,350,30,"Exit");
fl_set_object_lsize(obj,FL_NORMAL_SIZE);
fl_set_object_lstyle(obj,FL_NORMAL_STYLE+FL_EMBOSSED_STYLE);
fl_set_object_callback(obj,guiExit,0);
obj = fl_add_frame(FL_DOWN_FRAME,10,190,350,130,"");
fdui->Controls = fl_bgn_group();
fdui->hFog = obj = fl_add_lightbutton(FL_PUSH_BUTTON,30,240,100,30,"Fog");
fl_set_object_boxtype(obj,FL_EMBOSSED_BOX);
fl_set_object_gravity(obj, FL_NoGravity, FL_NorthWest);
fl_set_object_callback(obj,guiFog,0);
fdui->hu = obj = fl_add_valslider(FL_HOR_NICE_SLIDER,150,240,200,30,"m");
fl_set_object_boxtype(obj,FL_EMBOSSED_BOX);
fl_set_object_lsize(obj,FL_DEFAULT_SIZE);
fl_set_object_lalign(obj,FL_ALIGN_LEFT);
fl_set_object_lstyle(obj,15);
fl_set_object_gravity(obj, FL_NorthWest, FL_NoGravity);
fl_set_object_callback(obj,guiu,0);
fl_set_slider_return(obj, FL_RETURN_CHANGED);
fl_set_slider_bounds(obj, 0, 2*MU0);
fl_set_slider_value(obj, (double) MU0);
fdui->hplugin[0] = obj = fl_add_roundbutton(FL_PUSH_BUTTON,20,20,82,50,"");
fl_set_object_color(obj,FL_MCOL,FL_RED);
fl_set_object_lstyle(obj,FL_BOLD_STYLE);
fl_set_object_callback(obj,guiplugin,0);
fdui->hplugin[1] = obj = fl_add_roundbutton(FL_PUSH_BUTTON,20,120,82,50,"");
fl_set_object_color(obj,FL_MCOL,FL_RED);
fl_set_object_lstyle(obj,FL_BOLD_STYLE);
fl_set_object_callback(obj,guiplugin,0);
fl_end_form();
return fdui;
}
152
The callback functions for the user control are defined in separate functions. For example, the
callback function for the slider for the › -coefficient, that is defined in the above sample, will be
implemented as
void guiu(FL_OBJECT *ob, long data) { (data);
mu = (float) fl_get_slider_value(ob);
}
Forcewheel
The Saitek force wheel peripheral is connected to a PC through the game port. Hence, in order
to use this equipment to control the vehicle in the simulation, the PC that the force wheel is
connected to, must communicate with the VVSS through SPINE. Appendix D explained about
blockset library for the PC.
The steering angle and angles for the pedals are accessed as if the force wheel was a regular
joy-stick. The equipment must therefore be correctly installed in the Windows operating system.
The dynamic run-time library that facilitates Simulink to communicate with the force wheel first has
to initialize the communication with the game-port, before it can retreive values for the particular
angles and buttons. The following command is used to extract data from the force wheel:
joyGetPos((UINT)JOYSTICKID1,(LPJOYINFO)\&Joystick);
Then the retreived values are stored in a
JOYINFO Joystick
where the variables Joystick.wXpos, Joystick.wYpos represent the angles of the interface, and Joystick.wButtons contains the button press information.
In Simulink, a model needs to be designed that replaces the necessary states and variables from
the VVSS to reflect the inputs of the force wheel. This model is available in the Simulink library
blockset.
Cerealbox
If the Cereal box is used as an input device, then its inputs will be directly read by the VVSS. In
this case, the VVSS will initialize communication with the device and poll its input buffer once
per simulation frame.
Stereoscopic Vision
The aniumation of the VVSS supports stereoscopic projection, using special active goggles and
synchronizing emitters. In the software, the following lines of code facilitate this feature.
153
shared->chan = new pfChannel(p);
shared->right = new pfChannel(p);
shared->chan->attach(shared->right);
mask = shared->chan->getShare();
mask |= PFCHAN VIEWPORT;
shared->chan->setShare(mask);
leftArg =
(int*)shared->chan->allocChanData(sizeof(int));
rightArg =
(int*)shared->right->allocChanData(sizeof(int));
leftArg = 1;
rightArg = 0;
/* data never changes, so we only need to pass it once
*/
shared->chan->passChanData();
shared->right->passChanData();
eyeAngle = PF RAD2DEG(atanf(Iod *.5f
/(Converge * (far - near) + near)));
printf("Eye angle :%f",eyeAngle);
view.hpr.set(-eyeAngle, 0.0f, 0.0f);
view.xyz.set(-Iod/2.0f, 0.0f, 0.0f);
shared->chan->setViewOffsets(view.xyz, view.hpr);
view.hpr.set(eyeAngle, 0.0f, 0.0f);
view.xyz.set(Iod/2.0f, 0.0f, 0.0f);
shared->right->setViewOffsets(view.xyz, view.hpr);
Curriculum Vitae
Gert-Edzko Smid was born in Groningen on April 30, 1969. Prior to university, he attended the
“Winkler Prins Scholengemeenschap” in Veendam, from which he graduated in 1988. He started a
study in electrical engineering consecutively, at the Delft University of Technology. He graduated
in 1995 on the design and analysis of a robust controller for the Bosch SCARA Robot.
After graduation he conducted practical training at Oakland University for a period of six month.
In Januari 1996 he enrolled into the graduate program as a graduate research assistant. During
the practical training and the assistantship he worked on numerous collaboration projects between
Oakland University, TACOM (US Army Tank and Automotive Armements Command) and commercial industry. In particular with Dana Corporation on the simulation of noise and vibrations in
hydraulic power steering systems.
In the summer of 1997 he spent three months at the Department of Electrical and Systems
Engineering of the university of Bologna in Italy. As a visiting researcher he assisted in the design
of a control algorithm for the VIDET (Visual Decoder by Touch) system. In 1998 he spent three
months at the Delft University of Technology, modeling the Jumbo Container Crane 2000.
154
Index
Terrain file, 134
Flowchart, 143
Force wheel, 136, 152
Forward Euler approximation, 25
Frame-rate, 51
Friction model, 12
Fuzzy logic tire model, 12
Ackermann geometry, 82, 85, 104
Active suspension, 76
Anti-roll, 112
Applications, 46
Assumptions
Tire model, 121
Backward Euler approximation, 25
Bilinear approximation, 25
Brake in a turn, 92
Gearbox complience, 106
Geometry formats, 139
Gimbal Lock, 128
Graphical user interface, see User interface
Camber angle, 102
Caster angle, 103
Centrifugal forces, 66, 113
CerealBox, 139, 152
Circular skid pad, 88
Command line, 131
Coordinate systems, 123
Coriolis forces, 66, 113
Coulomb friction, 12
Human in the loop, 49
Hyperstability, 63
Identification, 95
Implementation, 138
Vehicle Dynamics, 142
Index library, 40
Indexing
Corner indexes, 150
Vehicle indexes, 149
Indirect addressing, 41
Initialization procedure, 139
Integration
Accuracy, 74
Bilinear, 25
Euler, 25
Explicit, 29, 40
Implicit, 29
Phase Lag, 37
Stepsize, 23
Tustin method, 23
Dashboard, 136
Default Values, 147
Descriptor matrix, 9
Direct cosines, 128
Discrete State-spece model, 26
Dugoff, 114
Elastic stress, 115
Elastokinematic compensation, 103
Engine map, 106
Euler Rotation, 66
Euler rotation, 113, 128
File structure, 130
155
156
Intersectioning, 108
Jumbo Container Crane, 7
Kalman observer, 55
Karithonov, 63
Key-press functions, 132
Kingpin angle, 103
Lagrange model, 7
Lane change, 92
Lateral acceleration, 90
Lateral control, 102
Library index, 40
Limit cycle, 12
Load distribution, 32
Luenberger observer, 55
Stability, 76
Lyaponov, 63
Markov matrix, 58
Mis-synchronization, 74
Modeling, 142
Brake, 9, 107
Chassis, 11, 112
Engine-Transmission, 9
Partitioning, 32
Powertrain, 106
Steering, 9, 102
Suspension, 10, 108, 111
Tire, 10, 114
Wheel spin, 10, 107
Modularity, 31
Motion Platform, 101
Multi-processing, 32
Neural networks, 56
Neuromotor dynamics, 50
Newtonian model, 7
Nomenclature, iv
Nonlinear state-space model, 9
Numerical Integration, 21
Observability, 58
Observability matrix, 58
Observable canonical form, 58
Observer, see Kalman observer
Onyx-2, 50
Optimal control model, 49
Oversteer gradient, 90
Performer, 138
Peripherals, 101, 149
Pointer table, 40
Polynomial time, 64
Popov, 63
Profile, CPU usage, 50
Quaternions, 128
Real-time, 3, 50
Reality engine, 50
Rebounce, 111
Ricatti equation, 57
SAE Coordinates, iv
Scenery, 133
Shaker table, 101
Shared memory, 138
Shear deformation, 115
Simulink blockset, 136
Skip pad, see Circular skid pad
Slip ratio, 116
SPINE, 40
Client, 147
Server, 145
SPINE Synchronization, 49
Split- œ test, 90
Spoke model, 108
Stability, 63
Euler Angle Transformation, 66
Jury test, 70
Latency, Synchronization, 74
of Integration, 67
Quarter-car, 64
157
Roll-over, 78
Wheel Spin, 66
Yaw-rate, 78
State request form, 42
Static load, 81
Steady state cornering, 82
Steering
Ackermann, 104
Complience, 104
Gear ratio, 105
Self centering, 103
Stereo, 152
Stick friction, 12
Stopping distance, 86
Sub-sampling, 51
Telemetry, 94
Thread deformation, 115
Timing, 49
Timing diagram, 53
Tire stiffness, 116
Toe-in angle, 86, 103
Traction Control, 76
Understeer gradient, 78, 88
Usage, 130
User interface, 131, 134, 141, 149
Validation
Requirements, 95
Sensors, 95
Tire model, 96
Verification, 80
Virtual Environment, 45
Viscous friction, 12
Wheel
Deflection model, 108
Lift-off, 111
Running model, 107
References
[1] Vehicle Dynamics and Analysis Software. a comprehensive 6 degree of freedom vehicle
simulation program for the PC.
[2] A. Alleyne. Improved vehicle performance using combined suspension and braking forces.
In Proceedings of the American Control Conference (ACC), Seattle, Washington, June 1995.
[3] K. Araki, H. Sakai, and M. Yanase. Tire model consisting of theoretical and experimental
equations for vehicle dynamics analysis. In Proceedings of ISATA, pages 145–153, Florence,
1996. Osaka Sangyo University and Sumitomo Rubber Industry Ltd.
[4] Michael Athans. IEEE Handbook of Control, chapter 35, pages 589–594. CRC-Press, 1996.
Kalman Filtering.
[5] H. Bauer. Automotvie Handbook. Robert Bosch GmbH, P 30.02.20, D-70442 Stuttgart, 4th
edition, 1996.
[6] R. D. Braatz, M. Morari, and S. Skogestad. Robust reliable decentralized control. In
Proceedings of the American Control Conference, Baltimore, Mariland, June 1994.
[7] Ka C. Cheok, N. J. Huang, T. Horner, and T. Settle. Concurrent real-time simulation and
animation of an active suspension using tms320c30 and graphics hardware. Simulation, pages
405–416, December 1993.
[8] Ka C. Cheok, K. Kobayashi, and F. Hoogterp. Fuzzy logic based traction control of a 4wd
truck. In Proceedings of the 13th IFAC World Congress, San Fransisco, July 1-5 1996.
[9] Ka C. Cheok, K. Kobayashi, and G. E. Smid. Simulation and animation of a 16-degree
of freedom dynamics of a vehicle in matlab. Technical report, ITT Automotive - Oakland
University, 1996. Submitted to R. Romano and S. S. Vaidyaraman.
[10] Ka C. Cheok, K. Kobayashi, G. E. Smid, P. Lescoe, and J. L. Overholt. In-line-of-sight leaderfollower hmmwv’s with fuzzy logic preview control. In Proceedings of AUVSI, Orlando, FL,
July 1996.
[11] Ka C. Cheok, K. Kobayashi, G. E. Smid, P. Lescoe, and J. L. Overholt. A fuzzy logic hierarchical intelligent control system paradigm for an in-line-of-sight leader-follower hmmwv.
Journal of Robotic Systems, 14(6):407–420, 1997.
[12] Ka C. Cheok, J. L. Overholt, and R. R. Beck. Exact methods for determining the forward kinematics of a steward platform using additional sensors. Joural of Robotic Systems,
Vol.10(Num.5):689–707, July 1993. Special Issue on Parallel Closed-Kinematic Chain Manipulators and Devices.
158
159
[13] Ka C. Cheok, G. E. Smid, K. Kobayashi, F. Meisterfeld, and R. Hormel. Internal impedance
characterization for black box signal source. In Proceedings of ECC, Brussels, Belgium, July
1-4 1997.
[14] Ka C. Cheok, G. E. Smid, K. Kobayashi, J. L. Overholt, and P. Lescoe. A fuzzy logic intelligent control system architecture for an autonomous leader-follower vehicle. In Proceedings
of ACC, Albuequerque, New Mexico, June 6-10 1997.
[15] J. J. Craig. Introduction to Robotics. Addison-Wesley Publishing Company, Inc., 2 edition,
1989.
[16] H. Dugoff, P. S. Fancher, and L. Segel. An analysis of tire traction properties and their
influence on vehicle dynamic performance. In International Automobile Safety Conference,
pages 341–365. Society of Automotive Engineers (SAE), 1970. Highway Safety Research
Institute, The University of Michigan.
[17] S. Dussy, L. E. Ghaoui, G. Mastinu, and M. Gobbi. Linear matrix inequalities in automotive applications: A tutorial. Laboratoire de Mathematiques Appliquees, Ecole Nationale
Superieure de Techniques Avancees, Paris, France.
[18] A. Seireg Y. Hossam El-Deen. Mechatronics for cars: Integrating machines and electronics to
prevent skidding on icy roads. Computers in Mechanical Engineering, pages 10–22, January
1987.
[19] E. Fiala. Seitenkrafte am rollenden luft-reifen (lateral forces on rolling pheumatic tires).
Technical Report 29, V.D.I., October 1954.
[20] Bernard Friedland. IEEE Handbook of Control, chapter 37, pages 607–618. CRC-Press,
1996. Observers.
[21] Thomas D. Gillespie. Fundamentals of Vehicle Dynamics. Society of Automtive Engineers,
1992.
[22] D. T. Greenwood. Principles of Dynamics. Prentice-Hall, Englewood Cliffs, NJ, 1965.
[23] F. Gustafsson. Monitoring tire-road friction using wheel slip. IEEE Control Systems,
18(4):42–49, August 1998. Linköping University.
[24] Gyliepse. Automotive Engineering in the Analysis of Automobiles. Society of Automotive
Engineers (SAE), -.
[25] R. A. Hess. Hunam-in-the-Loop Control, volume The Control Handbook, chapter 80, pages
1497–1505. CRC Press and IEEE Press, 1996.
[26] R. A. Hess and R. Kalteis. Technique for predicting longitudinal pilot-induced oscillations.
Journal for Guidance and Control Dynamics, 14(1):198–204, 1991.
[27] Applied Dynamics International. Real-time seventeen-degree-of-freedom motor vehicle simulatin. Technical report, U.S. Department of Transportation, National Highway Traffic Safety
Administration, 1995. (See DOT-HS-805-370, March 1, 1980).
[28] ISO. Road Vehicles - Braking in a Turn. Open-loop Test Procedure. ISO/DIS 7975.
[29] ISO. Road Vehicles - Double Lane Change, 1975. ISO, TR 3888.
[30] ISO. Road Vehicles - Steady State Circular Test Procedure, no. 4138 edition, 1982. ISO
No.4138.
160
[31] N. A. Kheir, Ka C. Cheok, G. E. Smid, S. Cole, and A. Cooprider. A first course in automotive
mechatronics systems. In Proc. Of Advances in Control Education (IFAC), Istanbul, Turkey,
July 14-16 1997.
[32] J. B. Klaassens, G. Honderd, A. El Azzouzi, Ka C. Cheok, and G. E. Smid. 3d modeling
visualization for studying controls of the jumbo container crane. In Proceedings of ACC,
page Submitted, 1999.
[33] D. L. Kleinman, W. H. Levison, and S. Baron. An optimal control model of human response.
part i: Theory and validation. Automatica, 6(3):357–369, 1970.
[34] K. Kobayashi, Ka C. Cheok, and K. Watanabe. Application of a fuzzy logic rule-based
kalman filter for estimating absolute speed of a ground vehicle. International Journal of
Intelligent Automation and Soft Computing, Vol.1(No.2):179–190, 1996.
[35] K. Kobayashi, K. Watanabe, Ka C. Cheok, and G. E. Smid. A simple vehicle dynamics
modeling by the object oriented approach. SICA, 1997.
[36] S. R. Kou, D. L. Elliot, and T. J. Tarn. Exponential observers for nonlinear dynamic systems.
Inf. Control, 29(3):204–216, -.
[37] Y. D. Landau. Adaptive Control. The model reference approach. Marcel Dekker, Inc., 1979.
[38] William S. Levine, editor. The Control Handbook. CRC Press, IEEE Press, 1996.
[39] F. Lewis. Optimal Estimation. Unknown, -.
[40] F. L. Lewis. Optimal control. In Handbook of Control, chapter 48, pages 759–778. Institute
of Electronics and Electrical Engineers (IEEE), 1996.
[41] L. S. Louca, J. L. Stein, G. M. Hulbert, and J. Sprague. Proper model generation: An
energy based methodology. In 3rd International Conference on Bond Graph Modeling and
Simulation, Phoenix, AZ, January 12-15 1997.
[42] D. Luenberger. Observers for multivariable systems. IEEE Transactions on Automatic
Control, 11:190–197, 1966.
[43] F. Mancosu and G. Matrascia. Experimental tests and virtual reality determining the parameters of a two-dimensional tyre model for the study of comfort. In Proceedings of ISATA,
pages 383–390, Florence, 1996. Pirelli Coordinamento Pneumatici SpA.
[44] James N. Martin. Systems Engineering Guidebook. A Process for Developing Systems and
Products. Lucent Technologies, 1997.
[45] D. T. McRuer. Human dynamics in man-machine systems. Automatica, 16(3):237–253,
1980.
[46] T. Meressi, D. Chen, and B. Paden. Application of kharitonov’s theorem to mechanical
systems. IEEE Transactions on Automatic Control, pages 488–491, 1993.
[47] W. F. Milliken and D. L. Milliken. Race Car Vehicle Dynamics. Society of Automotive
Engineers (SAE) Publisher Group, 1995.
[48] S. Nishizawa, Ka C. Cheok, G. E. Smid, L. W. Ten Berge, and P. Lescoe. Heads-up-display
collision warning and traffic monitoring system. In The International Automotive Forum
ISATA, Florence, Italy, June 16-19 1997.
161
[49] H. B. Pacejka. Magic formula tire model transient properties. an overview of developments,
February 1997. IAVSD-Tyre, Berlin.
[50] P. Y. Papalambros and N. F. Michelena. Optimal model-based decomposition of powertrain system design. Technical Report Technical Report UM-MEAM 95-03, Department of
Mechanical Engineering and Applied Mechanics. University of Michigan., 1995.
[51] J. P. Pauwelussen, S. T. Jansen, J. J. M. Van Oosten, and H. B. Pacejka. Testing and
modelling of tyre behaviour in dynamic vehicle simulation. In Proceedings of ISATA, pages
137–144, Florence, 1996. TNO Road Vehicles Research and Delft University of Technology.
No.96VR052.
[52] M. S. Qatu, M. L. Dougherty Sr., and G. E. Smid. Effect of hose, tuner and fluid parameters
on power steering noise and vibration. In Proceedings of SAE Congress, 1999.
[53] M. S. Qatu, M. L. Dougherty Sr., and G. E. Smid. Measurement of fluid bulk modulus using
impedance of hydraulic circuits. In Proceedings of the SAE Congress, 1999.
[54] Alexander A. Reid. Correlated Parametric Terrain Surface Development for use with Computer Image Generators. PhD thesis, Oakland University, Department of Electrical and
Systems Engineering, 1998. Doctoral Research Proposal.
[55] G. E. Smid and Ka C. Cheok. Human integration in simulation. In Proceedings of International Workshop on Advanced Motion Control, pages 554–558, Coimbra, Portugal, June
29-31 1998.
[56] G. E. Smid and Ka C. Cheok. Multi-conputer real-time simulation of vehicle control systems.
In Proceedings of International Conference on Intelligent Systems (ICIS), Paris, France, July
1998.
[57] G. E. Smid, Ka C. Cheok, and K. Kobayashi. Simulation of vehicle dynamics using matrixvector oriented calculation in matlab. In Proceedings of CAINE (ISCA), pages 115–120,
Orlando, FL, December 1996.
[58] G. E. Smid, M. Qatu, and M. L. Dougherty Sr. Optimizing the power steering components
to attenuate noise and vibrations. In Proceedings of Conference on Computational Fluid
Dynamics, pages 103–112, England, July 1998.
[59] Society of Automotive Engineers, Inc, Warrendale, PA. Proposed Passenger Car and Light
Truck Directional Control Response Test Procedures, sae xj266 edition, 1985.
[60] W. R. Stevens. TCP/IP Illustrated, Volume III. Addison-Wesley Publishing Company, Inc.,
1996. TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols.
[61] T. K. Tan, K. C. Cheok, and G. E. Smid. Hypercube neural networks, modeling and training.
In Proceedings of the International Conference on Intelligent Systems, 1998.
[62] F. E. Thau. Observing the state of nonlinear systems. International Journal on Control,
17:471–479, 1973.
[63] P. Tinker, R. Azuma, C. Hein, and M. Daily. Driving simulatin for crash avoidance warning system evaluation. In Proceedings of ISATA, pages 367–374, Florence, 1996. Hughes
Research Laboratories.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement