Measuring Event Based Driver Performance: implications for driving simulator scenarios TRB workshop: Standardized Descriptions of Driving Simulator Scenarios Wim van Winsum Tel: Fax: Washington D.C., January 9, 2005

PART 1: Statement of the problem 1What are Event Based Driver Performance measures 2Why are they among the most important measures of driver performance 3Time-to-line crossing (TLC) is discussed as an example, but the same arguments also applies to other Event Based Driver Performance measures 4It 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 1Event Based Driver Performance measures are usually measures that reflect the time relation between the vehicle and an object in the surroundings of the vehicle 2The time relation usually exists of a prediction of the time it takes before the object is crossed, reached or collided with 3The 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 4Examples are then TLC (time-to-line crossing), TTI (time-to- intersection) and TTC (time-to-collision)

3Time relations between the vehicle and other objects are used as safety margins by the driver 1Drivers 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 2These 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.

1Event based driver performance variables measure how drivers control safety margins. 2Another example of an important driver performance variable that reflects a safety margin is Time Headway (THW), although it is not event based. 3Measures of how drivers control their safety margins are then important performance variables that must be measured in driving simulators. 4In 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 = α * R v R v = radius of the vehicle path (u/yawrate) In order to compute α, you need to know the coördinate points [X v, Y v ] and [X r, Y r ] as well as R r = radius of the road (distance between centerpoint [X r, Y r ] 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 ?

1Because 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). 2This approximation gives very different results compared to the real TLC 3In 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 4Because 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: 1accurate path prediction of the vehicle (knowledge of the dynamics of the vehicle) 2accurate 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: 1Common use of the same driving simulator software: the same experimental scenarios can be ‘played’ on different simulators, ranging from low-end to high-end 2Standardization of scenario- and database formats 3Exchange of graphical databases and scenarios 4Development 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: OpenFlight tm 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 designerOpenFlight tm database Logical database

1Autonomous agents (vehicles, bicyclists, pedestrians) ‘scan’ the immediate environment in the logical database 2Based on what they perceive, they apply a number of behavioural rules 3And perform an action that changes speed and lateral position 4And 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