SAE Paper 950174
THE IOWA DRIVING SIMULATOR:
AN IMPLEMENTATION AND APPLICATION
OVERVIEW
Freeman, J.S., Watson, G., Papelis, Y.E., Lin, T.C.,
Tayyab, A., Romano, R.A. and Kuhl, J.G.
Center for Computer–Aided Design
208 Engineering Research Facility
The University of Iowa
Iowa City, Iowa 52242–1000
ABSTRACT
This paper presents an overview of the Iowa Driving
Simulator (IDS), including its implementation and
experimental applications. The Center for Computer–Aided
Design (CCAD) at The University of Iowa began developing
the IDS in 1990 with primary funding from the state of Iowa
and the Advanced Research Projects Agency (ARPA). The
simulator utilizes a recently developed real–time multibody
dynamics formulation to create high fidelity,
operator–in–the–loop vehicle simulations, a large
six–degree–of–freedom hexapod motion base, wide
field–of–view textured graphics with directional audio
sources, and several interchangeable, instrumented cabs to
provide realistic cueing feedback to the driver.
Human factors issues currently being investigated by IDS
researchers include experimental studies for the design and use
of automated highway systems, usage of raised pavement
markers for lane edge–line delineation, IVHS collision
warning and roadway departure warning systems, advanced
traveler information systems, performance assessment of
challenged drivers, verification of driver performance in
virtual environments, and more general issues of simulator
fidelity and perceived realism. Two applications of the IDS
are detailed: a study of Automated Highway Systems (AHS)
and vehicle virtual prototyping on a virtual proving ground.
Figure 1: The Iowa Driving Simulator
Payload:
18,000 lb.
Motion Envelope: +/– 40” Horizontal
+/– 36” Vertical
Acceleration: +/– 1.1 g to 3.5 Hz
Table 1: IDS motion base specifications
IDS IMPLEMENTATION
Mounted on top of the motion base, the visual display dome is
a portion of the outer surface of a torus having identical major
and minor radii of nine feet. An Evans and Sutherland
ESIG–2000 image generator, connected to a SEOS Prodos
projection system utilizing four projectors, is used to create the
visual display on the dome’s inner surface. Each of the four
channels of the ESIG is configured to display 786,000 pixels,
with a 30 Hz. refresh rate. This configuration presents the IDS
test subject with a forward visual field of view of 190 by 40
degrees, and 60 by 40 degrees in the rear direction.
The IDS consists of the large, six degree–of–freedom,
hexapod motion base and visual display dome shown in
Figure 1, along with an array of computer hardware and
software subsystems. It is located in a large bay area in the
Engineering Research Facility on the university’s campus.
The implementation of each of the hardware and software
subsystems will be detailed in the succeeding sections.
HARDWARE – The motion base of the IDS is a
Computer–Aided Engineering (CAE)–Link Heavy Payload
System which was previously used for U.S. Air Force flight
simulation applications. Specifications for the motion system,
which meets MIL–STD–1558, are listed in Table 1.
Three real–time computer systems currently compose the IDS
computational hardware base. These are an Alliant FX2800
1
CAD 002–0001–001
12/29–94
SAE Paper 950174
A set of software tools developed at the Center [1], links the
hardware and software subsystems. This set of tools, termed
the Iowa Control program, (ICON), operates like a simulator
operating system, providing a set of high–level services
directly related to real–time simulators. The ICON utilizes the
concept of programming–in–the–large to allow IDS software
subsystems to be used as building blocks that can be
combined, or integrated into functioning simulations with
greatly different capabilities. It forms an abstraction layer
between the native operating systems and real–time executives
distributed on the different computer systems, and the software
subsystems which compose the simulator. In terms of its
overall capabilities, ICON provides real–time distributed
scheduling facilities, performance monitoring, real–time and
non real–time data communications, and greatly enhances the
modularity and portability of the overall system.
parallel computer, which features 26 high–speed i860 RISC
processors, a Harris Nighthawk 4404, and a Harris Nighthawk
5806, which feature four 88000 and six 88110 processors,
respectively. The Alliant is used to perform the vehicle
dynamics simulation, and complex scenario control functions,
while other subsystems are operated on the Harris machines.
Three vehicle cabs are currently supported: a Ford Taurus, a
GM Saturn, and a HMMWV. A common interface has been
developed to support the interchangeability of the vehicle
cabs. All normal dash instrumentation is fully functional, and
driver interaction devices (steering wheel, accelerator and
brake pedals, transmission gear selection lever, and emergency
brake) are instrumented and continuously sampled. A direct
current (DC) servo motor connected to the original steering
column provides tactile feedback for the subject driver.
The IDS supports a complete range of instrumentation for both
driver information and for data collection. In addition to cab
mounted instrumentation, the IDS has an accelerometer and
rate gyro package mounted below the center of the motion
base. These sensors provide a direct measurement of motion
base response.
The use of ICON modularizes and decouples simulator
subsystem designs, and enables parallel, independent
subsystem development. Direct data communications between
subsystems is prohibited, with the exception of the vehicle
dynamics subsystem’s query of the terrain database, and each
subsystem communicates only with ICON. ICON provides
each subsystem with its input/output interface, and controls
when each subsystem operates. Thus, subsystems are no
longer required to have explicit knowledge of point–to–point
or temporal scheduling relationships. This encapsulation
greatly eases subsystem design and debugging. Non–CCAD
developed software can also be used, by encapsulating its
functionality within well–defined ICON interface calls.
SOFTWARE – The simulator hardware provides a full range
of sensory cues and simulii to the subject driver who, in turn,
controls the simulation model which is represented in
software. Modular software subsystems have been developed
to provide various aspects of IDS functionality. These
subsystems include:
•
•
•
•
•
•
•
•
•
Vehicle Dynamics
Terrain Modeling
Motion Feedback
Visual System
Control Loading Feedback
Auditory Cue Generation
Data Collection
Scenario Generation and Control
Distributed Interactive Simulation Communication
A functional relationship of the various subsystems is shown
in Figure 2. Actions of each of the subsystems, and the
inter–communication frequencies, are shown in this figure. At
the start of a cycle, the subject driver’s actions are measured
from the operator’s controls by the control loading subsystem.
Measurements of accelerator and brake pedals, steering wheel
position and velocity, and transmission gear selector positions
are communicated to ICON, where they are retrieved by the
Figure 2: IDS Inter–Subsystem Dataflow
2
CAD 002–0001–001
12/29–94
SAE Paper 950174
vehicle dynamics subsystem. This subsystem computes the
vehicle response to the operator’s inputs in real–time using a
multibody dynamic representation of the vehicle’s chassis and
suspension systems. Control loading feedback forces are
calculated within the vehicle dynamics subsystem and used to
provide operator tactile feedback at the steering handwheel.
The vehicle state information (position, velocity, acceleration
and orientation) is used by the other simulator subsystems to
provide feedback stimulii. Subsystems having short transport
delays, such as scenario control and audio, use the vehicle
state information directly, while subsystems having longer
transport delays, such as the visuals subsystem, use a delay
compensated vehicle state. This delay compensation predicts
the future position of the vehicle, so that the visual system will
display the proper image, despite computational delays in the
image generator hardware pipeline.
VEHICLE DYNAMICS – The IDS real–time vehicle
dynamics software is capable of representing the nonlinear
dynamic characteristics of nearly every ground vehicle. A
goal in the development of this software is to have the ability
to create a vehicle simulation model directly from engineering
CAD data. Because the dynamics formulation models the
vehicles kinematic and dynamic properties directly from first
principles, without resorting to linearizations or lumped
parameter approximations, accurate vehicle performance
characteristics can be computed over a wide performance
envelope; including limit–handling conditions. This high
fidelity modeling approach allows the IDS to provide realistic
vehicle response in near–accident situations for safety–related
research. Additionally, the models can be made sufficiently
detailed for engineering test and evaluation of new or evolving
vehicle designs.
Figure 3: Translational and Rotational Spring–Damper–
tuator Curvefit Representations
Models of front–, rear–, and four–wheel powertrain
arrangements have been developed and tested, with an
additional dual–axle drive powertrain being developed for
heavy truck simulations. These powertrain models are fully
encapsulated from the RTRD kernel, and it is possible to freely
substitute different powertrains with the same vehicle
kinematic model. All of these models employ automatic
transmissions since none of the IDS vehicle cabs supports a
manual transmission setup. Currently, the models are based on
a one–dimensional angular velocity–torque transmission
analysis [8], however it is planned to transition to a more
advanced powertrain representation which follows the same
formulation as the RTRD kernel [9]. Using a spatial
representation of the powertrain, it is possible to calculate the
force and torque interactions of the powertrain components
with the vehicle chassis, suspension and steering linkages. An
example interaction is front–wheel–drive torque steer, where
the placement of the front differential, and the relative
orientations of the axle shafts and kingpin inclination angle
generate a force on the steering linkage.
The latest version of this software, NADSdyna, has been
developed for intended use in the U.S. Department of
Transportation (DOT)–sponsored National Advanced Driving
Simulator (NADS). This software is based on the Real–Time
Recursive Dynamics (RTRD) kernel [2]–[7] developed at
CCAD, in combination with a variety of other subsystem and
component–level models.
The RTRD kernel is a general purpose multibody dynamics
package based on a minimal, joint–coordinate formulation of
the equations of motion for rigid multibody systems. It is used
to represent the vehicle chassis, suspension, and steering
linkage systems of the simulated vehicle. Special purpose
force elements for translational and rotational motions,
including linear, nonlinear, and multivariate curvefit
representations as shown in Figure 3, are used to represent
springs, shock absorbers, and leaf spring elements. Other
force elements, based on more complex table representations,
can be applied to specialized simulations.
Four tire models are supported by the current software. These
are table–lookup model, Calspan model, Systems Technology
Inc. (STI) model, and the Gim/Nikravesh model. The
orientation of the wheel, including its steered, camber and slip
angles is computed by the RTRD kernel from the known
orientation of the wheel spindle body. Forces generated by the
tire models act on both the rotational inertia of the wheels and
the wheel spindle body. Since the spindle is part of the vehicle
kinematic description, these forces are appropriately
transmitted to the vehicle chassis and steering systems.
Three types of steering subsystem models are supported;
kinematic, manual and power–assisted. These models can be
applied to both rack and pinion and gearbox–type steering
systems. These models are applicable only for the portion of
the steering system between the driver’s handwheel and the
steering linkage. The linkage itself is modeled within the
RTRD kernel. The kinematic steering model works well for
off–line simulations, while the others provide a more realistic
model of the steering subsystem. The kinematic model
formulates the steering column as a rigid body, and directly
In addition to the kinematic representation of the vehicle
chassis, suspension and steering linkages, subsystems which
must be modeled as part of an operator–in–the–loop
simulation include:
•
•
•
•
•
Powertrain
Tires
Steering
Braking
Aerodynamics
3
CAD 002–0001–001
12/29–94
SAE Paper 950174
actuates the linkage which is attached to the wheel spindle
assemblies with distance constraints. The manual and
power–assisted formulations add compliance and damping to
the steering column, with the power–assisted system also
providing a boost force which is a function of relative
displacements of the steering handwheel and linkage.
Upper
Control Arm
R
Locator Link
or Tie Rod
S
S
S
Like the other subsystems which form the connection between
the RTRD–based, kinematic vehicle model and the virtual
environment, the braking subsystem supports multiple model
types. Manual and power–assisted hydraulic, and simplified
pneumatic braking system are all supported. An anti–lock
braking system (ABS) controller has also been implemented
though is not yet functional with the IDS hardware. This ABS
controller uses wheel–lockup prediction and reselection logic
which is similar to many commercial systems.
Spindle
Assembly
R
S
Lower
Control Arm
S: Spherical Joint
R: Revolute Joint
Lastly, the aerodynamic models supported by the IDS include
SAE J670e and SAE J1594. These models are both
steady–state force models which do not support buffeting or
other transient interactions with objects or vehicles in the
virtual environment.
Figure 6 Short–Long Arm Suspension
modelled several different ways using a multibody
representation. The way we have selected to model this is to
have the lower control arm and wheel spindle be represented
by spatial bodies, while the upper control arm and the tie rod
are represented by massless bodies. To accomplish these
modeling objectives, a revolute joint connects the lower
control arm to the chassis and a spherical joint connects it to
the wheel–spindle assembly. The upper control arm and
spindle assembly are together represented by a
specially–formulated revolute–spherical cut–joint, and the tie
rod is represented by a cut distance constraint. The complete
HMMWV vehicle kinematic model, shown in Figure 7, is
composed of 10 bodies, which represent the chassis,
suspension, and steering linkage.
As an example of how a vehicle is modeled using the RTRD
software, a High–Mobility Multipurpose Wheeled Vehicle
(HMMWV) shown in Figure 4 is presented. The HMMWV is
ÎÎ
ÎÎ
ÎÎ
ÎÎ
ÎÎÎ
ÎÎ
ÎÎ
ÎÎ
Î
ÎÎ
ÎÎ ÎÎÎÎ
ÎÎ
ÎÎ
ÎÎ
ÎÎ
ÎÎÎ
ÎÎ
ÎÎ
ÎÎ
ÎÎ
ÎÎ
9
R–S
Figure 4: M1025 version of U.S. Army HMMWV
a full–time four–wheel–drive vehicle with fully–independent
suspensions for both the front and rear axles. It is powered by
a 116 kW (155 hp) diesel engine, three–speed automatic
transmission, lockable differential transfer case, and Torsen
axle differentials. A close–up of the left–rear suspension of
the HMMWV is shown in Figure 5, with the equivalent
kinematic model in Figure 6. This suspension can be
R
R–S
S
8
D
6
7
R
5
S
R–S
1
D
y
R4
D
R
T
2
3
S
x
z
R–S
S
10
D
Figure 7: IDS 10–body HMMWV kinematic model
The layout of the HMMWV powertrain is shown in Figure 8.
The current HMMWV powertrain model incorporates the
rotational characteristics of all the powertrain components,
using experimentally verified data where ever possible. An
example of this is the steady–state engine torque map shown
in Figure 9. Performance maps of the torque converter and the
automatic transmission shift logic are also employed in the
Figure 5: HMMWV rear left suspension (rear view)
4
CAD 002–0001–001
12/29–94
SAE Paper 950174
overlap, allowing the modeling of vertically stacked terrain
such as bridges and overpasses. A dataset is a datum piece
that includes information such as elevation and surface type at
a specific location. Datasets are spaced at regularly distanced
intervals within a datazone. The distance between adjacent
datasets is defined as the resolution of a datazone. To resolve
a database query, linear interpolation among the four datasets
that surround the query point is used. A variable density
terrain mesh is achieved by using multiple datazones for
modeling a specific terrain database. Even though the
resolution within a datazone remains constant, different
datazones can have different resolutions. Use of an arbitrary
number of datazones allows modeling terrain in different
resolutions, based on the frequency content of different areas.
Figure 8: HMMWV Powertrain Layout
Due to the potentially large size of a terrain database, the
terrain interrogation software must occasionally consult the
disk for terrain data that is not available in memory. Due to
the operating disk overhead and other secondary factors,
read–disk operations have non–deterministic execution time
thus eliminating a read–on–demand approach to fetching the
terrain data from disk. The IDS terrain subsystem uses a
paging algorithm that predicts the location of the vehicle and
reads data from disk before they are needed for actual queries.
MOTION CONTROL SOFTWARE – Ground–vehicle motion
can generate a wide range of acceleration magnitudes and
frequency spectra. A simulator with the ability to exactly
replicate all motion cues would require an excessively large
range of motion [11]. A motion washout algorithm is
employed to enforce the limited constraint envelope of the
motion base [12]. The IDS can employ either a classical or an
adaptive washout algorithm. The motion cue generated by the
IDS is appropriate if the cue is scaled in magnitude and
temporally in phase with the commanded response generated
by the vehicle dynamics subsystem. Missing motion cues and
generating false motion cues are also possible due to the
physical constraints on motion. A missing cue in the simulator
response is a transient vehicle dynamic response which is
completely filtered by the washout algorithm. A false motion
cue can either be an expected motion in the wrong direction or
a detectable motion where one should not exist.
Figure 9: HMMWV 6.2L Steady–state Engine
Performance
development of the powertrain model, so that the simulated
vehicle responds very similarly to the actual one.
TERRAIN – All ground–based simulation models must have
some knowledge of the terrain in which they operate. Here,
the term terrain refers to the physical geometry of the virtual
environment and does not include logical attributes such as
roadways and roadside objects, or individual features, such as
traffic control devices. The degree to which the terrain needs
to be modeled depends on the final purpose of the simulator.
In high–fidelity simulators such as the IDS, recovery of highly
detailed visual cues, vibration, sound, and tactile feedbacks
and large–scale motion cues are very important. For ground
vehicles, the cause of these feedback cues are largely due to
the interaction between the terrain and the vehicle, terrain
modeling, representation and interrogation is a central issue in
IDS virtual environment design.
The objective of the washout algorithm is to maximize the
scaling factor and appropriate motion cues, while
simultaneously minimizing false or missing cues. A block
diagram of the classical washout motion–base drive algorithm
is shown in Figure 10. Inputs to the washout subsystem are
the translational accelerations, the angular velocities, and the
Euler angles of the vehicle chassis body. Outputs from the
washout algorithm are the position and orientation commands
to the motion base controller. In the classical motion washout
algorithm, the translational and rotational motion inputs are
treated as independent channels, except for long duration
translational accelerations, which are cross fed from the
translational channel input to the orientation channel output.
By realigning the gravity vector the correct scaled direction of
the specific force generated by the long duration acceleration
can be represented by a tilt of the motion base. This is
referred to as tilt–coordination.
The IDS terrain database [10] model supports a variable
density surface mesh, and provides an efficient and
deterministic terrain query that is independent of the size of
the database. It also supports overlapping terrain, a feature
necessary for modeling bridges and overpasses. The variable
resolution mesh reduces database storage requirements and
does not affect the terrain interrogation efficiency. This model
is implemented by partitioning the ground (x–y) plane into
datazones that contains datasets. A datazone is an arbitrary
rectangle aligned along the (x–y) axes. Datazones can
In the classical washout algorithm, the acceleration and
angular velocity inputs are first scaled and limited. Typical
scaling factors employed with the IDS range from 0.3 to 0.5.
The scaled angular velocities and specific forces are then
5
CAD 002–0001–001
12/29–94
SAE Paper 950174
Figure 10: Classical Washout Algorithm
transformed into the inertial coordinate system of the motion
base, and are high pass filtered to eliminate the low–frequency,
high–amplitude motions of the vehicle. The parameters of the
filters used in the washout algorithm are selected to maximize
cue recovery while eliminating commanded motions that are
outside the envelope of the motion base.
typical rule of thumb used in flight simulation is 3.0 deg/sec.
However, there is not a universally accepted threshold for
driving simulation.
VISUAL SYSTEM – Visual databases are prepared utilizing
Software Systems’ Multigen software. The Multigen package
includes roadway generation tools jointly developed by
Software Systems and The University of Iowa. Using these
tools, complex roadway geometries can be modeled including
horizontal and vertical curves and super–elevation. These
roadway concepts have been integrated to form trumpet
interchanges, three–leg directional interchanges, two lane rural
highways and six–lane interstate freeway. A small town with
stop lights at two intersections has also been developed.
Figure 11 is a typical out the window view of the one of the
rural highways. In addition to the roadway, up to 40 moving
vehicle models can be simultaneously displayed by the
ESIG–2000 image generator. These are typically other
vehicles in the scene which have correct brake lights and turn
signals.
The tilt coordination portion of the washout algorithm low
pass filters the scaled specific forces and cross feeds this signal
into the rotation channels. Tilt coordination generates the
sustained inertial acceleration that cannot be generated by
translation of the motion base due to physical motion envelope
limitations. If the change in tilt angle is introduced slowly
enough, the corresponding rotation cue is not perceived by the
simulator operator. The tilt angles required take the form [12].
tan 1(f yf z)
tan 1(f yf z)cos
0
There has been extensive research performed in flight
simulation on the tilt rate detection threshold level. The
Figure 11: Out the Window View
6
CAD 002–0001–001
12/29–94
SAE Paper 950174
such as passing or following. This decision would be
represented by control inputs to a kinematic (or dynamic)
model of a vehicle which then generates the position,
orientation and associated state of the vehicle. A road
database maintains information about topology and geometry
of the road network including traffic signs, and the state of all
entities in the virtual world. Existing vehicle behaviors
include driving on rural and interstate roadways, vehicle
following and leading, passing, lane changing, awareness of
traffic signs and traffic rules. In addition, specialized state
machines have been built that create behaviors specialized to
Automated Highway System (AHS) experimentation
discussed later in the paper.
The Churchville Test course at the U.S. Army’s Aberdeen
Proving Grounds has also been reproduced, based on
engineering drawings, aerial and on–course photographs, and
photo–derived elevation field data. This test course is an
approximately 6.5 kilometer closed–track of rough, compacted
dirt roadway featuring steep uphill and downhill grades and
large berms across the roadway. Correlated visual and terrain
surface topology databases [13] are generated for both the
simulator operator and the vehicle simulation software. The
IDS visual representation of Churchville is highly realistic,
and the course topology is as accurately re–created as possible.
AUDIO – The IDS audio subsystem produces auditory cues in
response to the driving environment, including wind, engine
and tire noise, and passing traffic sounds. The audio system is
based on off–the–shelf MIDI digital sampling hardware and
consists of a 16 voice digital sampling workstation and a
MIDI–controlled mixer. Speakers are strategically placed
throughout the dome to generate multi–channel auditory cues.
Typically there are four speakers for the non–specific
environmental noise, and additional speakers in the wheel
wells for providing other specific auditory cues. The system
supports cross–channel fading and phasing of sounds to
provide directionality cues.
The current generation of the scenario control subsystem can
simulate in excess of 40 vehicles at an execution frequency of
60 Hz, on a 40 MHz i860 processor. The second generation
scenario control subsystem is currently under development
[14]. The purpose of the second generation system is to meet
the demands for more complex behaviors, ease of
programming behaviors by non–experts, and increase the
number of vehicles. To achieve this, the second generation
system uses hierarchical concurrent state machines for
behavior modeling, decouples the software that control
behavior from the software that controls the physical motion
of each vehicle and includes interactive graphical tools that
will allow non experts to program behaviors and orchestrate
complex scenarios.
The MIDI approach permits the use of sampled source audio
data recorded from a representative vehicle environment.
Microphones are placed in the vehicle to record each sound
source individually. From a series of digital recordings,
samples of each sound type are assembled for a series of
discrete operating points. While using the IDS, the vehicle
and environmental states are evaluated to produce dithered
sounds from each of the sound samples, which are then
blended to produce representative auditory cues.
DISTRIBUTED SIMULATION – Future simulator
applications may require the combined interaction of operators
in multiple simulators which can be geographically dispersed.
For this reason, the IDS has been networked using a
communications subsystem which is compliant with the
Department of Defense’s Distributed Interactive Simulation
(DIS) protocol. Applying DIS methodologies allows
real–time interactions with other DIS–compliant simulators.
A correlated visual and terrain database of Fort
Hunter–Liggett has been provided to CCAD as a common
virtual environment.
DATA COLLECTION AND REDUCTION – The ICON
software can be programmed to collect any variable passed
through its interface. Typically, all driver input commands,
vehicle response, scenario response, control loading feedback,
and measured motion base response are collected at a speed of
60 Hz. for later data reduction. To minimize the amount of
data collected in real time, a rich set of data collection options
can be selected at run time. Through these options, data can
be collected at different frequencies, and stored in
high–performance binary files for reduction.
To accomplish the goal of geographically dispersed,
distributed simulations, the IDS has been linked to the
ARPA–sponsored Defense Simulation Internet (DSInet)
incorporating Battlefield Distributed
Simulations–Development (BDS–D) testbed facilities. In
support of this activity, the Modular Semi–Automated Forces
suite (ModSAF) and a GT101–based stealth node from Loral
have been installed at CCAD facilities. The GT101, and the
associated SIMNET databases, such as the Hunter–Liggett
database, provide the linkage necessary to support interactive
simulation in a geographically distributed environment.
A set of custom developed software tools can be used to
reduce the online data into meaningful measures. The data
reduction tools are fully integrated with the various IDS
databases and produce measures such as lane deviation,
control input reversals, vehicle following distances, and
response time to external events. The format of the output file
is compatible with major statistical packages, such as
Statistical Analysis Software (SAS).
APPLICATIONS
SCENARIO CONTROL – The scenario control subsystem
generates all necessary behaviors to model semi–autonomous
vehicles, regulate traffic control devices, control lighting and
weather conditions and model any other non–static entity in
the virtual environment. Each entity is associated with a state
machine. State machines react to each other as well as the
operator’s vehicle by interrogating the environment and
making decisions regarding the motion of its entity. For
example, the state machine of a computer–generated vehicle
may scan the positions of the other vehicles and of the road
network, and make a decision regarding its driving behavior,
The IDS is a flexible research tool which has been used for a
wide variety of applications. By the end of 1994, 16 studies
involving more than 500 subjects will have been conducted
using the IDS. Studies range from the design and evaluation
of vehicles, automated highway systems, and in–vehicle
information and warning system to issues of fitness–to–drive
and driver licensure. These applications highlight the ability
to define and control a high–fidelity immersive environment in
which to carry out human–centered experimentation. Two
studies in particular are highlighted here: the design of
7
CAD 002–0001–001
12/29–94
SAE Paper 950174
Because the IDS models both vehicle performance and
roadway or terrain characteristics at an engineering level of
detail, the facility is used to develop and demonstrate the
simulation–based vehicle design capabilities, while utilizing
human–in–the–loop virtual prototyping [17]–[18]. This
represents a new technology for ground vehicle systems, in
which a full vehicle design can be virtually driven and
evaluated on a test track or proving ground well in advance of
initial physical prototyping. In addition to evaluating
subjective human–centered performance issues,
operator–in–the–loop virtual prototyping provides on–line
performance data used to enhance the effectiveness of other,
off–line engineering analyses. For instance, component load
histories derived from runs on a virtual proving ground can be
used as inputs for reliability and durability prediction analyses.
automated highways, and the validation of
operator–in–the–loop simulation for vehicle virtual
prototyping.
DESIGN OF AUTOMATED HIGHWAY SYSTEMS – The
design of AHS requires a thorough understanding of how
safety and efficiency are best coupled through the physical
characteristics of the roadway and in–vehicle systems, how
driver performance in the system varies by age and experience
level, and how training and licensure may be affected by these
deviations from normal driving. The Federal Highway
Administration (FHWA) is currently sponsoring a series of
IDS experimental studies to investigate AHS human factors
issues.
Researchers from Honeywell, Inc. and The University of Iowa
ran an initial set of experiments, which used a six–lane divided
freeway, focused on entering and exiting a high–speed
automated lane, and issues of driver control during loss of
AHS capability [15]–[16]. Experimental conditions called for
the IDS to provide traffic densities of 10 and 25
vehicles–per–mile, per–lane in the non–automated lanes;
automated lane speeds of 65 to 95 mph; headway distances
from 0.125 to 0.25 seconds between automated vehicles; and
interstring distances from 2 to 5.5 seconds between strings of
vehicles in the automated lane. The experiments also studied
various protocols for entry and travel in the system and
included manual, partially–automatic, and automatic. Manual
lane entry required the driver to relinquish and accept vehicle
control by pressing buttons and steering manually upon cue
into the automated lane. Partially–automatic entry required
fewer driver inputs, but still required the driver to maneuver
the vehicle into the automated lane when instructed, while
automatic entry completely controlled the vehicle, and entered
into the AHS lane upon the driver’s request. Other protocol
variations were also required. In addition, the experiments
forced drivers to deal with various AHS capability losses.
Driver were asked to deal with a loss of steering, speed
control, or both. Over twenty audio messages were correlated
to provide feedback and instructions to drivers in a
combination of the conditions mentioned above.
With support from the ARPA, and assistance from the Army
Combat Systems Test Activity (CSTA), the CCAD has
developed an IDS virtual proving ground environment that
closely duplicates two test courses at the Army’s Aberdeen
Proving Ground (APG) [19]. The virtual test courses exactly
match the real courses in both geometry and cultural detail.
The larger of the two model courses (shown in Figure 12)
consists of a 6.5 kilometer compacted dirt and gravel course
with grades up to 29%, many hairpin turns, and a number of
large berms traversing the roadway. In July of 1994, a study
was performed to determine the extent to which engineering
and driving performance data collected on the actual APG
courses correlates with data derived from the simulator. For
this study, experienced test drivers performed a series of runs
on an APG while driving in a HMMWV that has been
instrumented to provide approximately 40 channels of vehicle
and human performance data. The drivers then carried out the
identical runs on the virtual test course in the IDS.
The data obtained shows a high correlation between driver
performance in the simulator versus on–course. Similar
correlation in measured performance were observed for
accelerator pedal usage and brake pedal position and pressure.
Measured vehicle acceleration data indicated a tendency for
drivers to drive somewhat less smoothly in the simulator and
to induce large accelerations, particularly during braking
maneuvers. Coupled with subjective comments by drivers
indicating a reduction in braking effectiveness in the simulator,
the data suggests that drivers are perceiving reduced vehicle
accelerations in the simulator, due to the less–than–full motion
cues provided by the motion platform, This observation is
further supported by data that show a strong correlation
between on–course vehicle accelerations and corresponding
accelerations measured by accelerometers on the motion
platform. These results provide guidance on improvements
needed in motion cueing to further enhance the fidelity of the
virtual proving ground (VPG).
These experiments mixed subject assignments with a variety
of conditions. Data was sampled at 60 Hz to provide
high–fidelity data collection and reduction to describe global,
as well as maneuver–oriented driver performance.
Performance and psychological inputs were also correlated
for enhanced data analysis. The drivers’ level of
psychological comfort was immediately measured after
relinquishing control to the automated system. This rating was
particularly important for comparing driver reactions to staged
merge maneuvers as lead cars entered the automated lane with
rates of closure that did or did not cause the subject vehicle to
brake.
The results of this ARPA VPG demonstration show that it is
feasible to utilize a VPG environment to assess vehicle
performance in the hands of an operator. The strong
correlation in measured performance for the simulator,
compared to a real–world environment, demonstrates the
ability to obtain valid quantitative data for the VPG to support
engineering test and evaluation.
GROUND VEHICLE VIRTUAL PROTOTYPING – The
traditional acquisition process for new ground vehicles, both
civilian and military, consists of multiple design iterations,
involving the building and testing of physical prototypes. This
process is costly and time–consuming, and limits the number
of design iterations that can be completed to optimize
performance objectives. Typically, physical prototypes can
only be built during mature stages of the design process, after
design and manufacturing decisions have effectively been
locked in.
8
CAD 002–0001–001
12/29–94
SAE Paper 950174
operational on The University of Iowa Oakdale Research
Campus in 1998.
CONCLUSIONS AND FUTURE DIRECTIONS
The large and varied experimental research program that has
developed on the IDS during its relatively short existence, is
testimony to the value of high–fidelity driving simulation for
human–centered research and development. The largest
inhibiting factor to more widespread use of driving simulation
for vehicle design or the study of human performance is the
cost and complexity required to achieve suitable levels of
fidelity and perceived realism. Even a high–end device like
the IDS cannot currently achieve cueing fidelity levels
adequate for all applications. For instance, the cost of
achieving perfect 20/20 visual resolution in a wide
field–of–view visual display system is prohibitively high.
Continuing technical advances in computer and graphics
technology will gradually address this problem.
ACKNOWLEDGMENTS
It should be acknowledged, that much of the support for this
research was provided under the ARPA and National Science
Foundation (NSF) contract #CDR–87–15397. Additional
support for software development for the National Advanced
Driving Simulator was provided by US DOT, NHTSA under
contract #DTNH22–93–Y–07237.
REFERENCES
The University of Iowa has been competitively selected as the
host site for the NADS, to be developed by the National
Highway Traffic Safety Administration (NHTSA) of the U.S.
Department of Transportation (DOT). The NADS facility will
significantly extend the fidelity of sensory cueing systems,
relative to the IDS. In particular, it will be capable of a much
larger range of motion to accurately convey vestibular cues
associated with sustained accelerations and extreme driving
maneuvers. The NADS will serve as a national, share–use
facility that will be utilized for a variety of driving–,
highway–, and health–related research objectives. The facility
is currently being designed. It is expected to become
[1]
Kuhl, J.G., Papelis, Y.E., and Romano, R.A. “An Open
Software Architecture for Operator–in–the–Loop
Simulator Design and Integration,” In Haug (Ed.),
Concurrent Engineering: Tools and Technologies for
Mechanical System Design, Springer–Verlag,
Heidelberg, Series F: Computer and System Sciences,
1992
[2]
Bae, D.S., and Haug, E.J. “A Recursive Formulation
for Constrained Mechanical Systems, Part I – Open
Loop,” Mechanics of Structures and Machines, Vol. 15,
No. 3, pp. 359–382, 1987.
[3]
Bae, D.S., and Haug, E.J. “A Recursive Formulation
for Constrained Mechanical Systems, Part II – Closed
Loop,” Mechanics of Structures and Machines, Vol. 15,
No. 4, 1987.
Figure 12: Aerial view of APG Churchville test course
9
CAD 002–0001–001
12/29–94
SAE Paper 950174
Evans, D.F. “Correlated Database Generation for
Driving Simulators,” 1992 Image VI Conference
Proceedings, The Image Society, Inc., Tempe, AZ, pp.
353–361, 1992.
[4]
Bae, D.S., Hwang, R.S., and Haug, E.J. “A Recursive
Formulation for Real–Time Dynamic Simulation,”
Proceedings ASME Design Automation Conference, pp.
499–508, 1988.
[13]
[5]
Hwang, R.S., Bae, D.S., Kuhl, J.G., and Haug, E.J.
“Parallel Processing for Real–Time Dynamic System
Simulation,” J. of Mechanical Design, Trans. of the
ASME, 112(4), pp. 520–528, 1990.
[14]
[6]
Tsai, F.F., and Haug, E.J. “Real–Time Multibody
System Dynamic Simulation, Part I – A Modified
Recursive Formulation and Topological Analysis,”
Mechanics of Stuctures and Machines, Vol. 19, No. 1,
pp. 99–127, 1991.
Cremer, J. Kearney, J., Papelis, Y., and Romano R.
“The Software Architecture ofr Scenario Control in the
Iowa Driving Simulator,” Proceedings of the Fourth
Conference on Computer–Generated Forces and
Behavioral Representation, May 4–6, Orlando,
Floriday, pp. 373–381, 1994.
[15]
Bloomfield, J.R., Buck, J.R., Carroll, S.A., Booth,
M.W., Romano, R.A., McGehee, D.V., and North, R.A.
“Human Factors Aspects of the Transfer of Control
from the Automated Hightway System to the Driver,”
Technical Report submitted to the Federal Highway
Administration, under FHWA Contract Number:
DTFH61–92–C–00100, 1994.
[16]
Bloomfield, J.R., Buck, J.R., Christensen, J.M., and
Yenamandra, A. “Human Factors Aspects of the
Transfer of Contrl from the Driver to the Automated
Highway System,” Technical Report submitted to the
Federal Highway Administration, under FHWA
Contract Number: DTFH61–92–C–00100, 1994.
[17]
Haug, E., Kuhl, J., and Stoner, J. “Virtual Prototyping
for Military Vehicle Acuisition,” SAE Techical Paper
No. 930848.
[18]
Freeman, J.S., Haug, E.J., Kuhl, J.G., and Tsai, F.F.
“Dynamic Simulation for Vehicle Virtual Prototyping,”
Computer–Aided Analysis of Rigid and Flexible
Mechanical Systems, NATO ASI Series E: Applied
Sciences, Pereira and Ambrosio (eds.), Kluwer
Academic Publishers, pp. 533–554, 1993.
[19]
“Vehicle Test Facilities at Aberdeen Proving Ground,”
US Army Test and Evaluation Command, Test
Operations Procedure, Report #TOP 1–1–011, 57
pages.
[7]
Tsai, F.F., and Haug, E.J. “Real–Time Multibody
System Dynamic Simulation, Part II – A Parallel
Algorithm and Numerical Results,” Mechanics of
Structures and Machines, Vol. 19, No. 2, pp. 129–162,
1991.
[8]
Freeman, J.S. and Velinsky, S.A. “Four–Wheel–Drive
Powertrain Models for Real–Time Simulation,”
Advanced Automotive Technologies, ASME Special
Publication DE–Vol.40, pp. 175–182, 1991.
[9]
Chen, J.S. “Vehicle Powertrain Models Using
Multibody Dynamics,” Ph.D. Thesis, The University of
Iowa, 1995.
[10]
Papelis, Y. “Terrain Modeling on High–Fidelity Ground
Vehicle Simulators,” Fifth Annual Conference on AI
Simulation and Planning in High–Autonomy System,
Gainesville, Florida, pp. 48–54, 1994.
[11]
Garrott, R. “Sizing the Motion Base of the National
Advanced Driving Simulator,” DOT HS 807 979,
March 1993.
[12]
Reid, L.D. and Grant, P.R. “SAMS2UI Motion
Algorithm,” report to CCAD from Aerospace
Engineering and Research Consultants Limited, 4925
Dufferin Street, Downsview, Ontario, Canada, M3H
5T6, 1992.
10
CAD 002–0001–001
12/29–94