Driving in a Virtual World
H. S. Kang
Faculty of Mechanical Engineering
Universiti Teknologi Malaysia
M. K. Abdul Jalil*
Faculty of Mechanical Engineering
Universiti Teknologi Malaysia
Musa Mailah
Faculty of Mechanical Engineering
Universiti Teknologi Malaysia
Abstract
This paper discusses the experience of developing a fixed-base
driving simulator. The simulator developed in this research project if
fixed-based and is intended to provide a platform for vehicle-related
research in the future such as vehicle system development, human
factor studies, and vehicle safety research A driving simulator
enables the reproduction of the actual driving environments in a safe
and tightly controlled environment. The driving simulator for this
research is developed using PC-based workstations that are capable
of producing high fidelity graphics at reasonable cost. The VR-based
simulator gives a driver on board the impression that he drives an
actual vehicle by predicting vehicle motion caused by the driver
input and feeding back the corresponding visual, motion, audio and
proprioceptive cues to the driver. This research is intended to
provide a test bed for simulating driving related task using virtual
reality technology.
Keywords: Vehicle Dynamic Model, Virtual Reality, Visual
Database.
1 Introduction
The term ‘Virtual Reality’ or VR has been used to describe a wide
range of applications in computer graphics and human-computer
interaction, some of which have little connection with the term’s
original meaning. A virtual reality, or as we normally refer to as
virtual environment, is a system which allows a user to feel
immersed in a computer-generated environment. VR technology has
been widely used in engineering and scientific visualization due to
its ability to create a life-like simulation.
A virtual driving simulator is a virtual reality device that allows its
user to feel a life-like experience of driving an actual vehicle. The
driving simulator is effectively used for studying the interaction of a
driver and vehicle and for developing new vehicle systems.
During the design of an automobile, detailed mockups of the interior
are built to study the design and evaluate the ergonomic issues.
However, these physical prototypes are expensive, time consuming,
and difficult to modify. It is more effective to use a virtual prototype
replacing the physical mockup for the design and analysis aspects
such as layout and packing efficiency, visibility of instruments,
controls and mirrors, reachability and accessibility.
------------------------------------*e-mail: kasim@fkm.utm.my
A driving simulator is needed to enable the analysis on driving
characteristics, and interaction between visual database and vehicles.
Recent development of powerful desktop computer workstations can
now support the computational requirement of small to mediumscale driving simulators.
Many factors should be carefully considered in developing and
applying full-scale driving simulators effectively, such as
constructions costs, application areas and target performance. A
prototype simulator, down-scaled, yet consisting of all the necessary
subsystems can be used effectively for evaluation of the factors
mentioned above and design of the full-scale simulators.
The driving simulator for this research is developed using PC-based
workstations that are capable of producing high fidelity graphics at
reasonable cost. The VR-based simulator gives a driver on board the
impression that he drives an actual vehicle by predicting vehicle
motion caused by driver input and feeding back the corresponding
visual, audio and proprioceptive cues to the driver. This research
project provides the initial groundwork for future research
development of driving simulator in Malaysia. The long-term
objective of this research is to provide a test bed for simulating
driving related task and for virtual environment technology research
in the country. This paper describes a first research attempt to
develop a static base driving simulator based on virtual environment
technology to create an immersive driving environment for the
simulator user. The knowledge gained from this project will be
further used to develop a full-scale driving simulator for automotive
and transport safety research in Malaysia.
2 Related Work
Research related to the development and application of driving
simulator is not new. Driving simulators, having their roots on flight
simulators in the early 1900s [Repa and Wierwille 1976], have
begun to appear in primitive forms in the 1970s. With the advent of
computer technologies, Daimler-Benz launched a high-fidelity
driving simulator in 1980s [Drosdol and Panik 1985], which created
wide interests throughout the world. Since then, many automotive
makers and research institutions worldwide have developed their
own simulators.
There are various level of complexity of driving simulators ranging
from a simple static base simulator to the most advanced simulator
that are capable of simulating the dynamic motion and scenes of an
actual vehicle. Various institutions and companies have developed
driving simulators for research purposes including National Advance
Driving Simulator (NADS), Leeds Advanced Driving Simulator
(LADS) [Bailey et al. 1999], and the Swedish National Road and
Transport Research Institute. A typical advanced driving simulator,
such as NADS in Iowa, normally consists of a visual system, angular
and translational motion systems with 6 DOF, vehicle cab system,
control feel system, auditory system, and vehicle dynamics. An
advanced simulator is capable of producing a high fidelity
simulation output. However the construction cost of this system is
very high. On the other hand, a static base simulator is inexpensive
and may be sufficient for applications that do not require very highfidelity simulation.
These simulators have several advantages over comparable vehicle
testing: safety, reproducibility of the vehicle model and its simulated
surroundings, ease of data acquisition and the convenience of
changing vehicle models and simulated surrounding in software
rather than test hardware.
The disadvantages are that the
information gained through driving simulation may be misleading if
the simulator does not provide an appropriate analog to the
simulated scenario, and high fidelity driving simulation is sometimes
far more expensive than vehicle testing [Gruening et al. 1998].
There are also companies that are involved in construction and
supply of driving simulators such as AutoSimTM from Norway. The
only setback of a ready-made system is that it may not fulfill a very
specific research requirement that needs high level of equipment
customization. Therefore, for fundamental research purposes,
developing a simulator from scratch is much preferred. The VRbased driving simulator developed in this research will lay the
groundwork for future research in transport safety, vehicle design
and ergonomic evaluation, intelligent vehicle highway systems and
driver education and testing.
or higher would be considered ideal. At 10 frames per second, the
image will be at least 0.1 seconds behind the simulation and usually
much more because most image generators require a frame to cull
the visual database and another frame to draw the database. The
larger delays are tolerable for the sound and instrument commands,
and so the technical requirements for these cues are relatively easily
achieved [Allen et al. 1998].
3.3 Real-time Computation of Vehicle Dynamic
Model (VDM)
The Vehicle Dynamics Model (VDM) is a mathematical model that
provides the vehicle responses during maneuvering at different road
condition in the virtual world. An important constraint on the
vehicle dynamic model is that it needs to run at least as fast as real
time. The ability to run in real time depends on the integration time
step and the complexity of the dynamic model. The integration time
step is an upper limit on the wall-clock time available to numerically
integrate across one time step. If a car model does not include a
bounce degree of freedom for tires, it should run well at about 100
Hz or with a time step of 0.01s [Gruening et al. 1998].
3.4
3
This section discusses the key issues in developing a typical vehicle
driving simulator. These issues are centered around creating a
realistic simulation environment that closely matches the actual
driving scenes.
3.1
Visual Database Rendering Burden
Visual database is one of the major components of any driving
simulator. A realistic driving scene is crucial to provide user with the
sense of realism. However, the quality of visual database is always
limited by the capacity of the rendering engine. Therefore, the
development of the visual database must include the optimization
aspect of the graphics. An important part of the visual database is
the description of the surface the vehicle drives on. This may be
modeled using polygonal road descriptions that are also used in
visual system, grid posts that are fit with splines, and analytical road
segments that are connected together to form the road surface [Artz
1995]. The visual database typically provides position and
orientation of the road texture description. The terrain model
includes a visual database which provides the desired level of
realism. An effective way of producing a detailed image, without
using too much computer power, is by having different pictures of
the same object. When an object is close, it is very detailed and
when it is far away, it has almost no detail [Martin and Jessica 2002].
3.2
Fidelity of Vehicle Driving Simulator
Issues in Developing Vehicle Driving Simulator
Simulation Frame-rate
The frame rate is more important than the graphical acuity. Too
large graphical delays mean a great risk of the driver getting dizzy
even if the screen has good acuity. According to Gruening et al.
[1998], rates of 10 frames per second is often quoted as the
minimum necessary for a sense of immersion, while a rate of 30 Hz
The accuracy of a driving simulator depends on the computational
capability to create graphic scenes with sufficient detail, resolution,
accuracy, luminance, contrast, and frame rate to provide a dynamic
display with enough quality and temporal response with closed and
open loop driving tasks and maneuvers [David and Allen 1995]. It is
important that the graphical scene is rendered from the driver’s
viewpoint. The direct part of the sight is about 60   30 [Gruening
et al. 1998]. A mid-level simulator typically has a large screen
graphical display to portray the out window roadway environment.
The forward field of view should have a lateral subtended angle
from the driver’s eye-point of at least 50-60 degrees, to provide for
adequate cueing and representation of driving scenarios [David and
Allen 1995].
4 Components of Vehicle Driving Simulator
A typical driving simulator normally consists of four main
components: a simulation of the physics of the vehicle model and the
road surface; a simulation of the surrounding environment, including
other vehicles and their surroundings; a system that enables the
operator to interpret the state of the model, such as its video and
audio displays; and its control devices, such as steering wheel, brake
pedal, and throttle [Gruening et al., 1998]. A good mid-level
simulator should have a large roadway scene display typically
comprising of animated computer graphics. It may have a motion
system or fixed base. It should have a dedicated cab with a steering
feel system with interactive controls and displays, a parametrically
configurable vehicle dynamics model, and a data acquisition system,
[David and Allen, 1995]. The driving simulator developed in this
research project is considered a low-cost version. It is a PC-based
system with fixed base. It consists of several major components: the
visual database system, the vehicle dynamics model, the driving cab
system, and the communication or interface module.
4.1 System Architecture
The setup of the driving simulator developed in this research is
shown in Figure 1. The simulator consists of a static base driving
cab with projected visual on a wide screen display to simulate the
driving environment, and the visual and audio database. The
simulator is controlled and operated on two personal computers
connected by Ethernet. The driver on board the simulator controls
the driving tasks using steering wheel, brake pedal and accelerator.
These controllers feed signals to the simulation system using TCP/IP
network protocol. The first PC acts as the graphic rendering engine
and the second PC manages the signal transfers between the
rendering engine and the simulation controllers, such as the steering
wheel, the accelerator and the brake pedals. The distribution of the
tasks into two different PC’s is necessary to ensure that the driving
simulation is done in real-time. The visual scenes are projected on a
wide-angle screen using two LCD projectors that are connected to
the second PC that controls the visual rendering. The visual scenes
can also be run on two flat panel LCD monitors. Stereographic
glasses can also be used to immerse the simulator user in a virtual
environment to produce a sense of realism while driving in the
virtual scenes.
Figure 2 illustrates the hardware architecture of the driving simulator
in our research. A driving simulator is primarily an operator-in-loop
device, so provisions to measure and record driver behavior in
general, and driver response and performance in particular are
essential in a mid-level facility [David and Allen 1995]. The cockpit
or the driving cab consists of a half-cut car to give the simulator user
the actual feel of driving an actual vehicle. The simulation
controller consists of a steering wheel, an acceleration pedal, and a
brake pedal that are connected to sensors (22mm 1W conductive
plastic servo mount potentiometers). The NI-DAQ PCI 6024E I/O
adapter board receives these data and passes them to a MATLAB
program in the server computer where the vehicle dynamic model
(VDM) is computed.
Figure 1 Functional Diagram of the Driving Simulator
4.2
Data Flow in Driving Simulator
Figure 3 illustrates the data flow chart of the driving simulator. The
input data to the I/O data acquisition board are the steering
angle,  sw , throttle displacement,  T and brake pedal displacement,
 B respectively.
The NI-DAQ PCI 6024E I/O adapter board
receives these data and passes them to a MATLAB program in
server computer that computes the vehicle dynamic model (VDM)
output such as the vehicle’s surge ( X ), sway ( Y ), and yaw (  ).
These output data computed from the VDM are then sent to the
client computer using TCP/IP socket. The output data from the
vehicle dynamic model computed by MATLAB are used to simulate
the driving actions in the virtual environment. The visual database
of the virtual driving environment, which is located on the client
computer, was developed using WorldToolKit (WTK) programming
language. WTK consists of functions written in C language that
makes the process of linking the visual database and the network
system easy.
Figure 2 Hardware Architecture in Driving Simulator
Figure 3 Data Flow Chart of Driving Simulator
The visual database developed for this project is based on the
roadmap of Universiti Teknologi Malaysia (UTM) campus. The
road surface amplitude (road input) matrix, Z u will be detected
by WTK internal virtual sensory system and fed back to the server
computer through TCP/IP socket. The Suspension Response
Dynamic model will then compute the reaction and response of
the vehicle body from the static equilibrium position, Z b , pitch
angle,  , and roll angle,  . These data will be returned to the
client computer in one step delay to modify the orientation of
vehicle body with respect to its virtual road profile.
 
4.3
The visual scene rendering includes full texturing, shading, fog,
and lighting effects to create a realistic driving environment. The
visual system is capable of producing high-resolution simulation
environment which spreads across two computers or projected
screens. A set of stereographic glasses can be used to view the
visual scene to give the user a sense of immersiveness while
driving in the virtual environment. Figure 4 shows a sample of
the driving scene developed in this research.
Visual Database
The environment surrounding a driving simulator includes all the
geometric representations which support both interaction between
the vehicle simulation and its surroundings, autonomous and nonautonomous agents. These agents typically include virtual
vehicles which influence the driving task. The mathematical
description of the environment is called the visual database
[Gruening et al. 1998]. In this research, the visual database was
developed using PC based rendering engine. The visual database
system generates high fidelity driving scenes that can be displayed
on multiple display systems that simulate the driver’s view when a
vehicle is in motion. The visual system is composed of a highspeed graphics accelerator running on Intel Pentium 4, 2 GHz
processor. The virtual driving scenes for this project are based on
the roadmap and landscape of Universiti Teknologi Malaysia. The
scenes were generated using WorldToolKit (WTK) software that
consists of functions written in C language that supports virtual
environment development and control. The toolkit includes
facilities for real-time rendering and animation, and extensive
functions for the creation and management of 3D graphic objects
and external sensors.
Figure 4 The UTM Campus Virtual Driving Scenes
The computer-generated environment or visual scenes can be
divided into three parts: static universe, dynamic objects, and the
interior of the driver’s vehicle. The static environment includes
roads, trees, buildings, and other elements that remain stationary
during the simulation. The dynamic objects can be controlled
independently and can react to the motion of the user’s vehicle
such as traffic lights. The virtual driving environment is
controlled by a steering wheel, accelerator and brake pedal that
provide the driver’s input to the simulator.
The models used in developing the visual database were created
using AutoCAD, 3D Studio and neutral file formats (NFF), which
are readable by WTK. These simulation models, as shown in
Figure 4, were then arranged in a hierarchical order in WTK
environment, which is called scene graph. The scene graph is the
structure that holds all of the current elements of the scene, such
as geometries, lights, fog, and positional information. Figure 5
illustrates the structure of the scene graph in the visual database.
The universe refers to the created virtual world in WTK. It
contains all the WTK objects including geometries, sensors,
lights, viewpoints, serial ports, and paths. Under the universe,
there is a scene graph ancestry known as root node. The scene
graph is an ordered collection of nodes, in the form of a directed
acyclic graph, which holds hierarchical scene data.
in the memory. In this research project, most of the static objects
in the visual database are minimally rendered using large polygon
size. For example, a visible facet of a building containing
window frames and wall are created using single polygon with
wall textures image mapped on the polygon.
Another technique that is used to enhance the graphic rendering
speed is the use of level-of-detail (LOD) concept. A group of
objects can be classified under a single node or object called LOD
node. LOD node is a specialized ‘switch’ node that selects its
currently active child automatically based on its distance from the
viewpoint. LOD node can be used to dynamically select between
a set of different representations, each of which is a different level
of detail. For example, suppose the simulator driver passes close
to a building and then recedes into the distance. WTK allows us
to specify the distance at which the LOD node could “swap in” a
new or less expensive representation. As the driver recedes into
the distance, simpler models (which require less and less
computational effort to process) are progressively swapped in,
freeing up memory and system resources.
The maximum number of frame rate supported by WTK is 30 Hz.
However, the frame rate depends on the capabilities of rendering
machine. The current rendering frame rate is around 25 frame
rate per second (fps), which is higher than the minimum necessary
value of 10 fps proposed by Gruening et al. [1998] for a sense of
immersion. We can increase the frame rate setting if the driving
simulation is conducted in a more powerful rendering machine to
minimize the total delay of visual display.
Figure 5 The Structure of Scene Graph
The scene graph of the virtual driving simulator consists of three
elements under the root node: the light nodes, geometry nodes,
and transformation nodes. The light nodes contain the lighting
information to illuminate some or all of the geometries in virtual
scene. The geometry nodes include static geometries files loaded
into WTK using WTK’s file import function and dynamic
geometries created within WTK at the polygon and vertex levels.
The transformation nodes contain positional information
associated with geometries and lights read in from a file, and
dynamic positional information created and managed within
WTK. It describes where particular elements (geometries and
lights) should be placed in the scene, either in relation to another
object, or in relation to the scene as a whole. The scene graph
provides a very powerful scene structure for real-time 3D
simulation. Specifically, scene graph provides the hierarchical
framework for easily grouping objects together spatially using
parent-child relationship. This is essential for maintaining
performance in scenes that contain many individual objects.
Because objects can be grouped together in a positional hierarchy,
the scene graph can be used to easily construct and maintain
efficient simulations that contain individual moving parts.
WTK calculates which parts of the scene (or scene graph) are
visible from the current viewpoint, and quickly rejects non-visible
geometry before drawing begins. The graphic rendering speed
depends on the complexity of the models in front of the user
viewpoint, for instance the number of polygons used to create the
models and the texture mapping applied to these models. We
implement this method to reduce the graphical rendering burden
To improve the fidelity and realism of driving scenario, the real
pictures of UTM buildings were mapped on the virtual objects.
This method can reduce the number of polygon used in the virtual
objects compared to drawing it directly in three dimensional.
Hence, the memory used in the graphical rendering can also be
reduced. Figure 6 shows the virtual buildings modeled by this
method.
4.4 Network Data Transmission
The Transmission Control Protocol/Internet Protocol (TCP/IP)
was employed as the data transmission protocol. This protocol is
reliable because it is a connection-based protocol and requires the
establishment of a session before data is transmitted between two
computers. TCP is designed to ensure that all packets sent by a
computer are received on the other end. TCP packets are
delivered to Socket. A Socket is a connection between two
computers in a TCP/IP network that sends or receives packets of
data across a network. Sockets are highly useful in client-server
models [James and Joe 1994]..
The TCP client socket was created as an additional part in the
WTK programming structure and the TCP server socket was
constructed as a part of MATLAB C-MEX program [The
MathWorks 2002]. By creating the client socket, it connects the
virtual reality programming to the server, and receives the data
computed from MATLAB vehicle dynamic model. In order to
establish a socket connection to transfer these data, the client
creates a socket and connects it to the server. On the server side,
once the server socket is created, it is bound to a specific endpoint
and told to listen indefinitely for an attempt by the client to
connect. The server socket then accepts the requests of the client
for connection. Once the communication channel between these
two machines is established, the server will send the vehicle
dynamic output data. Client socket will receive these data and
process them in WTK to control the virtual environment driving
simulation.
The SIMULINK integration time step is preset to 0.01s in the
Vehicle Dynamic Model blocks. To do this, the MATLAB CMEX S-function file is used rather than the M-file S-function
because the M-file S-function tends to cause the MATLAB
interpreter to be called at each time step and slows down the
overall simulation speed [The MathWorks 2002]. A C MEX-file
that defines an S-function block provides the information of the
model to SIMULINK during the simulation. As the simulation
proceeds, SIMULINK, the ODE solver, and the MEX-file interact
to perform specific tasks including defining the initial conditions
and block characteristics, computing derivatives, discrete states,
and outputs.
steering rack.
In our research, we concentrate on the 6 DOF orientations of the
sprung mass (car body) that affects the driver’s viewpoint directly.
The vehicle dynamic model (VDM) is simulated in MATLABSIMULINK program in the server computer as demonstrated in
Figure 7. The VDM is divided into two vehicle dynamic blocks;
the Handling Dynamic Model and Suspension Response Model;
and a SIMULINK S-function block that contains a network
communication TCP/IP port for data interface with client
computer.
SIMULINK interacts with a C MEX-file S-function by invoking
callback methods that the S-function implements. Each method
performs a predefined task, such as computing block outputs,
required to simulate the block whose functionality the S-function
defines. SIMULINK defines in a general way the task of each
callback. The S-function is free to perform the task according to
the functionality it implements.
Figure 7 Vehicle Dynamic Model Blocks
4.5.1 Handling Dynamic Model
Figure 6 Building with Photo Texture Mapping
4.5 Vehicle Dynamic Model (VDM)
The driving simulator does not have a physical drive line. Instead
the vehicle, its mechanical components and their behaviour are
described in a computer model. This model simulates the vehicle
dynamics in detail and in high update rates [Martin and Jessica
2002]. The complexity of the vehicle dynamic model is usually
related in a straightforward way to the number of degrees of
freedom (DOF) of the vehicle [Gruening et al. 1998]. The model
describes a drive line and a steering system, to enable the driver to
move forward and control his direction in the simulated world.
Good models of wheel suspension and steering servo-unit are
important for a realistic vehicle model. To include all parameters
of interest, the model often needs something like 15 DOF [Martin
and Jessica 2002]. There are typically 6 degree of freedom (DOF)
for the sprung mass, 4 DOF for the wheel velocities, 4 DOF for
the wheel suspension travels and last DOF for the position of the
The vehicle Handling Dynamic Model of the driving simulator is
based on a linearized handling model. On the simulator hardware,
the driver manipulates the cockpit and provides three input values
into the system: the steering wheel angles,  sw , the throttle
displacement,  T , and brake pedal displacement,  B .
These input values acquired by potentiometers (sensors) are sent
to the MATLAB Handling Dynamic block after being converted
into steering input,  , throttle torque, TP , and braking torque,
TB respectively. The handling model will simulate the
behaviours of the actual vehicle handling system. The steering
input,  controls the direction of the vehicle manoeuvring, and
the throttle torque, TP , and braking torque, TB are combined to
achieve the vehicle velocity, V .
By using the inertial reference frame XY shown in Figure 8, the
coordinates X and Y of the centre of mass G of the vehicle and the
yaw angle  between x and X axes are expressed as generalized
coordinates [Genta 1997].
Figure 8 Reference Frame of the Vehicle Motion
From Figure 8, the velocities components u and v from vehicle
velocity, V and its sideslip angle,  can be expressed in terms
of:
u  V cos
v  V sin 
(1)
(2)
The equations of motion with respect to time are arranged in
matrix form as:
    cos 
X 
    sin 
Y  
 sin   u 
 
cos   v 
The forces derived from the quarter-car model on the vehicle front
left side (with subscript fl ) are the suspension spring force, Fs ,
damping force Fd , spring effect force caused by tire, Ft , and tire
damping force Fdt :
(3)
where the  is the vehicle yaw angle. By finding the derivatives
with an integration step, the coordinates X and Y of the vehicle
centre of mass and the yaw angle  can be obtained.
4.5.2
Figure 9 Quarter-Car Model
Suspension Response Dynamic Model
Fsfl  k fl (Z ufl  Z sfl )

Fdfl  C S ( Z ufl  Z sfl )
Ftfl  ktfl (Z rfl  Z ufl )

(5)
(6)

Fdtfl  C St ( Z rfl  Z ufl )
k
(4)

(7)
refers to the spring stiffness, C S is the damper
Vertical dynamic effects play a major part in vehicle handling
which involve tyre normal loads, vertical terrain inputs, and
heaving motion due to the suspension between the sprung and
unsprung masses [Allen and Rosenthal 1994]. Suspension
systems are used to isolate the vehicle’s sprung mass from road
irregularities to achieve acceptable ride quality and to control load
transfer in order to maintain direction stability [Allen and
Rosenthal 1994].
where
In our project, we derived all the forces affecting the vehicle
suspension system from a quarter-car model, and later expanded
these results into a full-car model to determine the vehicle body
displacement from the static equilibrium position, roll angle and
pitch angle. The full car model is shown in Figure 10.
The displacement of sprung mass can be determined by
examining the forces acting on the vehicle body. From the results
of the quarter-car model, the general forces acting on the vehicle
suspension system are front-left force, F fl , front-right force, F fr ,
A two degree of freedom quarter-car model was used to examine
the forces that exist in the suspension system. The tyres are
considered as massless springs while both the unprung and sprung
masses are taken into account. This model holds well for natural
frequency of the unsprung mass of up to 30-50Hz [Genta 1997].
Figure 8 provides a schematic illustration of the quarter-car
model.
the vehicle suspension system are:
damping coefficient, k t is the tyre stiffness, C St is the tyre
damping coefficient, Z u is the displacement of unsprung mass
from the static equilibrium position, Z s is the displacement of
the sprung mass from the static equilibrium position, and Z r is
the height of the road surface on a reference level.
rear-left force Frl , and rear-right force Frr and the displacement
of sprung mass (the car body in this case) on each side,
Z sfl , Z srl , Z sfr ,and Z srr . Finally, the equations of motion of

Zb 
F fl  F fr  Frl  Frr
mB
(8)
a
a
( F fl  Frl )( )  ( F fr  Frr )( )
2
2

I XX
b
b
( Frl  Frr )( )  ( F fl  F fr )( )

2
2

I YY
References

(9)
(10)
ALLEN, R.W. AND ROSENTHAL, T.J. 1994. Requirements for
Vehicle Dynamic Simulation Models. SAE Paper 940175.
ALLEN, R.W., THEODORE, J.R., BIMAL, L.A., DAVID, H.K.,
FRITZ, G.A., JEFFREY, R.H. AND JEFFREY, P.C. 1998. A
Low Cost PC Based Driving Simulator for Prototyping and
Hardware-In-The-Loop Applications. SAE Paper 980222.
ARTZ, B.E. 1995. An Analytical Road Segment Terrain Database
for Driving Simulation. Conference Proceedings DSG 95.
BAILEY, A.C., JAMSON, A.H., PARKES, A.M. AND
WRIGHT, S. 1999. Recent and Future Development of the
Leeds Driving Simulator. Presented at DSC99, Paris.
DAVID, H.W. AND ALLEN J.C. 1995. A Survey of Mid-Level
Driving Simulators. SAE Paper 950172.
DROSDOL, J. AND PANIK, F. 1985. The Daimler-Benz Driving
Simulator, SAE Paper 850334.
ENGIEERING ANIMATION
Reference Manual, Release 9.
INC.
1999.
WorldToolKit
GENTA, G. 1997. Motor Vehicle Dynamic. World Scientific Co.
Pte. Ltd.
JAMSON, A.H., PARKES A.M. AND WRIGHT, S. 1999. Recent
and Future Development of the Leeds Driving Simulator.
Presented at DSC99, Paris.
Figure 10 Full-Car Model
where Z b is the displacement of the vehicle body from the static
equilibrium position,  is the pitch angle,  is the roll angle,
a is the track length, b is the distance from front axle to rear axle,
m B is the mass of vehicle, I XX is the moment of inertia in xdirection, and I YY is the moment of inertia in y-direction.
5 Conclusion
A low-cost yet effective static base simulator has been developed
using virtual-reality technology. This project has laid the
groundwork for the development of a full-scale driving simulator
to be used for road safety and vehicle related research. The
ongoing research work involves the development of a more
realistic visual database system, an advanced vehicle dynamic
model and integration of audiovisual effect. Future development
will also include a motion base integration into the existing
system to simulate the dynamic response of a vehicle in motion.
6 Acknowledgement
This research project has been supported and funded by the
Ministry of Science, Technology and Environment (MOSTE)
under the IRPA grant 03-02-06-0087EA001 (vot 74123).
MARTIN, J AND JESSICA, N. 2002. A Survey of Driving
Simulators and their Suitability for Testing Volvo Cars.
Chalmers University of Technology.
NATIONAL
HIGHWAY
TRAFFIC
SAFETY
ADMINISTRATION AND THE UNIVERSITY OF IOWA.
2002. NADS: National Advanced Driving Simulator, The Most
Sophisticated Driving Simulator in the World.
REPA, B. AND WIERWILLE, W. 1976. Driver Performance in
Controlling a Driving Simulator with Varying Vehicle
Response characteristics, SAE Paper 760779.
THE MATHWORKS, INC. 2002. Writing S-Functions, Version 5.
JAMES, M., AND JOE, L. 1994. TCP/IP Networking:
Architecture, Administration and Programming. New Jersey:
PTR Prentice Hall.