Measuring Event Based Driver Performance: implications for driving simulator scenarios

TRB workshop: Standardized Descriptions of Driving Simulator Scenarios

Wim van Winsum

www.stsoftware.nl

Tel: +31 50 5778768Fax: +31 50 5775835info@stsoftware.nl

Washington D.C., January 9, 2005

PART 1: Statement of the problem

1 What are Event Based Driver Performance measures

2 Why are they among the most important measures of driver performance

3 Time-to-line crossing (TLC) is discussed as an example, but the same arguments also applies to other Event Based Driver Performance measures

4 It is concluded that a detailed geometrical road-network representation is a prerequisite for measuring Event Based Driver Performance measures

PART 2: Dutch research simulator platform as an illustration

5) Creation of logical and graphical databases by a common source

6) Illustration of TLC measurements with the platform software

Overview of the presentation

PART 1: Measures of Event Based Driver Performance

1 Event Based Driver Performance measures are usually measures that reflect the time relation between the vehicle and an object in the surroundings of the vehicle

2 The time relation usually exists of a prediction of the time it takes before the object is crossed, reached or collided with

3 The reference object may be an edge line of the current driving lane, the start of an intersection plane or the rear bumper of another

vehicle

4 Examples are then TLC (time-to-line crossing), TTI (time-to-intersection) and TTC (time-to-collision)

3 Time relations between the vehicle and other objects are used as safety margins by the driver

1 Drivers are assumed to perceive these time relations and use these to control their behaviour. Examples of these behavioural responses are: steering corrections, braking, changing vehicle speed.

Driver actions to perceived time relations

TTO(time-to-object)

Behavioural response

2 These responses result in altered time relations: Drivers try to control these time relations. The time relations are then both input to, and output of driver actions. In that sense time relations are measures of driver performance.

1 Event based driver performance variables measure how drivers control safety margins.

2 Another example of an important driver performance variable that reflects a safety margin is Time Headway (THW), although it is not event based.

3 Measures of how drivers control their safety margins are then important performance variables that must be measured in driving simulators.

4 In practice, however, driving simulators are often unable to provide adequate measurements of these important variables

Driver are controlling and maintaining safety margins

1) TLC = DLC/velocity

2) DLC = α * Rv

Rv = radius of the vehicle path (u/yawrate)

In order to compute α, you need to know the coördinate points [Xv, Yv] and [Xr, Yr] as well as

Rr = radius of the road (distance between centerpoint [Xr, Yr] of road curve and inner lane boundary)

This requires an accurate and highly detailed logical (mathematical) representation of the roadnet together with an accurate vehicle dynamics model

Example: what is required to measure TLC in a curve ?

1 Because a logical representation of the road database is unavailable in most simulators, an approximation of TLC is often used that wrongly assumes that the vehicle will maintain the same lateral velocity: TLC_1 = (lateral distance)/(lateral velocity).

2 This approximation gives very different results compared to the real TLC

3 In addition, lateral distance often is computed with respect to the polygon edges of the graphical database. In the graphical database, road curves are often simulated as a sequence of straight edges that connect with a small angle. This results in sharp spikes in the TLC_1 signal that can only be removed after filtering

4 Because of these factors, TLC measurements in driving simulators are often unreliable

How is TLC in a curve often measured in practice?

To compute the time-relations between the vehicle and other objects a few things are required of driving simulator scenarios:

1 accurate path prediction of the vehicle (knowledge of the dynamics of the vehicle)

2 accurate representation of the surroundings of the vehicle (knowledge of the immediate environment) : distance to the object along the vehicle path, dimensions and angles of the object, relevant properties of the object, like radius, position or velocity

Not all simulators meet these requirements.

But if these requirements are met, then variables can be measured in a simulator that are hard or even impossible to measure on the road

Implications for driving simulator scenarios

We have established a research driving simulator platform with Dutch universities (RU Groningen, TU Delft and TU Twente), traffic research institutes (TNO Soesterberg, SWOV) and a neuropsychological clinic (University hospital Groningen) with the following goals:

1 Common use of the same driving simulator software: the same experimental scenarios can be ‘played’ on different simulators, ranging from low-end to high-end

2 Standardization of scenario- and database formats

3 Exchange of graphical databases and scenarios

4 Development of tools that allow researchers to build databases and experimental scenarios by themselves

PART2: Research simulator platform in the Netherlands

1) Logical- and graphical databases must originate from a common source: StRoadDesign database designer. This ensures that both types of databases match geometrically

2) Standardization in database formats and rendering: OpenFlighttm and OpenSceneGraph (OSG)

3) All internal variables in the simulator software are accessible to the researcher via a scripting language

4) Everything in the simulations is controlled by scripts: from traffic generation to datastorage and feedback generation

5) Complexity is reduced by using autonomous agents and by letting each scenario script control itself (switch on or off as a result of a dynamic condition)

6) Re-use of scripts

A few design considerations

Graphical and logical databases generated by one program

StRoadDesign road designer OpenFlighttm database

Logical database

1 Autonomous agents (vehicles, bicyclists, pedestrians) ‘scan’ the immediate environment in the logical database

2 Based on what they perceive, they apply a number of behavioural rules

3 And perform an action that changes speed and lateral position

4 And update their position in the logical database

Autonomous agents drive in a logical database

Example:TLC measured by the platform software

1) Time histories of the following data are shown: steering-wheel angle, yawrate, real TLC, lateral position, lateral velocity and approximated TLC1. To left=positive. To right=negative.

2) The real TLC (3th row) covaries with steering-wheel angle (1st row) and yawrate (3rd row): a steering correction is made when TLC reaches a minimum to left (positive) or right (negative)

3) The approximated TLC_1 covaries with lateral velocity and has very different properties compared to the real TLC

1) Event Based Driver Performance measures (or safety margins) are among the most important dependent variables in driver behaviour research

2) Measuring these variables requires an accurate and detailed geometrical description of the road geometry (logical database) and a vehicle dynamics model of sufficient quality. Distances to other (road) objects are then computed along the projected road path.

3) An added advantage of a logical database is that autonomous agents (vehicles, bicyclists, pedestrians) can travers the road network by references to this database

4) The logical- and the graphical database must originate from the same source, in order to ensure that logical and graphical positions of objects match, which is a core property of our design tool

5) The collective use of the same road networks and driver performance measures by research institutes will enable comparability of results and exchange of scenarios

Conclusions