subscribe: Posts | Comments | Email

Instrumentation: the driving simulator

0 comments
Instrumentation: the driving simulator

This is Chapter 3 of the Thesis from Adaptive control to adaptive driver behaviour, by van Winsum, 1996.

Other chapters of this thesis can be found here:

 

3.1. Background

The preparation of the experiments discussed in this thesis required a substantial amount of software design and implementation for the TRC driving simulator. A full description of the functionality and implementation of the simulator is beyond the scope of this chapter. The reader is referred to other documents for more detail and background (for example Van Wolffelaar & Van Winsum, 1992; Van Wolffelaar & Van Winsum, 1994).

The driving simulator of the Traffic Research Center (TRC) was developed as an instrument for behavioural research of driving. The GIDS project in which the TRC was involved at that time required a simulation testbed for mathematical driving modeling. Because of the dynamic complexities of driver tasks in multi-vehicle traffic, a dynamic traffic simulation was required as a test tool (Van Winsum and Van Wolffelaar, 1993). The objective of GIDS, an acronym for Generic Intelligent Driver Support, was ‘to determine the requirements and design standards for a class of intelligent co-driver (GIDS) systems that are maximally consistent with the performance requirements and performance capabilities of the human driver.’ (Michon and Smiley (1993). A prototype system was developed as a demonstrator for the essential features of the GIDS concept. One of the functions of the GIDS system was to compare required driving behaviour with actual behaviour. Required behaviour was modeled for a number of driving tasks and implemented in a computer system (Van Winsum, 1991; McLoughlin et al., 1993). It was decided at that time to design and implement a dynamic traffic simulation model and connect this with the driving simulator under development. From that moment the driving simulator evolved as a dynamic driving simulator with an interacting traffic world that could be connected to the GIDS system to serve as a test bed. After this, the simulator was also used as a testbed for other external driver support systems.

However, most importantly, the simulator is an instrument for the study of driver behaviour. Because it is used by researchers with very different questions and requirements, flexibility in software design has been considered to be important. This was accomplished by using the object-oriented computer language C++, and a multi-purpose UNIX machine instead of a single purpose dedicated simulation machine. To further increase flexibility for the researchers and to facilitate the design and testing of the experiments reported in this thesis, a fourth generation simulation language, SSL (Scenario Specification Language), was developed for the specification of experiments, together with a specification language (NSL, Network Specification Language) and software tools for roadnetwork creation. Data-sampling and data-processing facilities were added to facilitate experimentation.

 

3.2 The structure of the simulator

The simulator is composed of a number of software and hardware components that are connected via interfaces. The ‘conventional’ driving simulator consists of a physical car mockup, a car model implemented in software and a graphics system, together with a static road network environment. A dynamic traffic environment is added to this. The structure of these components as well as the object relations are shown in figure 1. In this figure several types of relations can be seen. An “is-a” relation specifies that a certain object type is a subtype of an other more abstract object type. For example, a BMW-car is some kind of car. This means that it inherits the functionality of the more abstract object type car. A “has-a” relation specifies that a certain objects has another object as a member. For example, a car has a traverser. The heavy printed arrows specify the direction of the flow of information. For example, there is an information flow from the object roadnet to the object sensor. This means that a sensor requests information from a certain instantiation of the object roadnet.

 

 

Figure 1. Logical structure of components of the driving simulator and relations between objects.

 

In addition to this, a number of facilities related to data-sampling and processing and experimental control are added to the simulator.

 

Car cabin. The steering wheel, clutch, gear, accelera­tor, brake and indica­tors of the car (a BMW 518) are connected to a Silicon Graphics Skywriter 340VGXT compu­ter (IRIS). Electromotors and other electronic appliances are built in the car to excert forces on the pedals and steering wheel and to send data on the steering wheel, accelerator pedal, brake pedal and indicators to the IRIS computer for further processing by the car model.

 

Car model. The IRIS computer processes these signals in a separate process referred to as the car model. The car model is described in more detail in Spaargaren (1994). It computes the longitudinal and lateral speed and acceleration that are the result of physical characteristics of the car and the input from the car cabin. From this the new coordinate position in the artificial world the car is driving in is computed. The output of the car model is used by the car traverser and by the graphics system. The traverser constitutes the link with the dynamic traffic process while the graphics system presents the output of the full system in a real-time visual format to the driver.

 

Graphics system. On a projection screen, placed in front, to the left and to the right of the driver, an image of the outside world from the perspective of the driver with a horizontal angle of 150 degrees is projected by three graphi­cal videopro­jectors that are controlled by the graphics software. Images are presented with a rate of 15 to 20 frames per second, resulting in a sug­gestion of smooth move­ment. The visual objects are buil­dings, roads, traffic signs, traffic lights and other vehicles.

In addition to this, the sound of the engine, wind and tires is presented by means of a digital soundsampler recei­ving input from the simulator computer.

 

Logical network (Roadnet). The logical network is the static environment in which the simulator car and traffic operate. The static environment consists of a database with a network of roads, traffic signs, traffic lights and buildings. This database is used for the visualization of the environment by the graphics system and by the artificially intelligent traffic to evaluate the present situation. The database can be generated in two ways:

– by NSL (Network Specification Language). This is a user specification language, created for the TRC simulator (Van Winsum, SSL/NSL specification release 1.2, 1994), by which a network of roads can be specified as an ASCII text. This text is processed by an NSL interpreter program that generates a road network database that is used by the simulator (Van Winsum, 1994, NSL scanner/ parser/interpreter computer program).

– by means of an interactive graphical program written in C++/OSF Motif (Van Winsum, 1993, program WORLDED). The user can specify a network of roads by means of click and point operations. The output of the NSL interpreter can also be used as input for this program to visualize and change the network.

 

The network consists of a structure of three base tables: a table with intersections, a table with paths and a table with segments. An intersection is a point in the network coordinate system with 1..n, {n >= 1}, outgoing paths. Coordinates are in meters. The following relations hold:

 

– n = 1: the intersection forms a terminal point in the network. If cars approach this intersection they cannot proceed beyond the intersection and provisions are made to ensure that the car turns around in the opposite direction as soon as the intersection is reached. The intersection has no physical layout and has the appearance of an ending road. The implication is that it is not possible for cars to move off the logical world.

– n = 2: the intersection is a virtual intersection in the sense that it has no specific layout and is not treated as an intersection by the traffic. The only purpose of creating such an intersection is for the convenience of the network constructor.

– n > 2: the intersection has more than two branches.

An intersection is of a certain type (f.i. a roundabout), it can be controlled by traffic lights with a certain control strategy, and it contains a list of references to outgoing paths. This list is ordered such that the path connections to the intersections are counterclockwise. In addition to this the intersection contains information about the layout, which is used by the graphics system and by the traffic.

 

A path is a logical connection between two intersections and always has one direction. It must start at one intersection A and end at one intersection B, where A may be equal to B. If A=B then the path is logically a circular path. All paths  have precisely one path in the opposite direction, referred to as a counterpath. It has a list of references to segments with 1..n elements, {n>=1} . This list is ordered such that the segments are in successive order. A path also contains information on right-of-way at the intersection at the end of the path, whether entry into this path is allowed, a reference to a traffic light at the end of the path if there is one, and information on buildings on the right side of the segments on the path.

To every path an ordered list with references to cars is attached. This list is ordered such that it reflects the order of the cars on the path and it may be empty. Cars can be added or removed at any time during the simulation process. In this way the simulator car and the computer controlled cars are connected to the static environment. Because every car is an object in the software-engineering conception that it has its own functions and data-structures, every car performs its own administration of detailed position (coordinates, distances from the last intersection and from the edge of the road etc.) in relation to the logical network.

The concept of path corresponds to the terminology of graph theory. Using that terminology, intersections are nodes.

 

The combination of nodes and paths may be described as a directed graph with the following properties:

– Suppose the network is represented as the graph G=(P,Z), with P being the set of intersections or nodes and Z being the set of ordered relations between the intersections, then P = {0..n} with n > 0. The fact that all intersections are member of a set ensures that all members occur once. The number of the intersections are in successive order. A set of intersections is, for example, {0,1,2,3}, meaning that there are 4 intersections. The set {0,1,3,4} is incorrect because the number 2 is missing.

– Z contains the relations between two nodes A and B, for example {{1,2}, {1,3}, {1,1}}. If {A, B} is a member of Z then {B,A} is also a member. This shows that all paths have a counterpath. A road can be traveled in two directions and this is the reason that every path has a counterpath. If only one-way traffic is allowed there are still two paths because physically it is possible to enter a one-way street into the wrong direction although legally it is not allowed.

– The fact that Z is described as a set suggests that the member {A,B} may occur only once. This restriction has been abandoned for practical purposes. There may be more than one instantiation of the relation {A,B}. In that sense Z is not a set but a collection. This restriction was loosened because sometimes there is more than one road between two intersections.

– A further restriction to the graph specification is that all nodes must occur in at least one relation, that is, a node that is fully unconnected is not allowed.

 

A segment is represented as a line through the middle of a roadpiece. It can be either straight or curved and is undirected. Segments are members of ordered lists connected to a path and the ordered list must contain al least one segment. A segment must be a member of one and only one ordered list. Segments represent the physical layout of the road, while a path represents the logical presence of a road. The direction depends on the path the segment is in. If the segment is straight the two end points are given in coordinates. If it is curved the segment contains the necessary information on the curvature, such as the radius, the centerpoint of the arc etc. A segment has a certain lane-width. At present only two-lane segments are allowed.

Traffic signs, buildings and traffic lights are connected to the network and have a certain position, angle, and type. Within the simulator program this roadnet representation is implemented as the separate object class in the roadnet module (Van Winsum, 1992, computer program class c_roadnet, roadnet.c). This object performs its own administration and can be queried from outside via an interface.

The following is an example of a definition of a simple network with NSL.

Define Inter[0] {

X := 100; Y:= 100;

}

Define Segment[0] {

Type   := Straight;

StartX := Inter[0].X;

StartY := Inter[0].Y

Length := 100;

Angle  := 90;

}

 

In this definition a straight road of 100 meters with an absolute angle of 90 degrees is created, starting at coordinate position [100, 100]. Paths are added automatically by the system. Since this definition of a network would result in a path without an end node, the system creates an end node (intersection number 1). Since the lane-width is not specified, the segment is assigned the default lane-width of 3 meters by the NSL system. In this case the NSL interpreter creates 2 intersections, 2 paths and 1 segment, no traffic signs, traffic lights or buildings. NSL contains a number of geometric transformation methods and rules to assists the user and to make it easier to build the network.

 

Traffic. Traffic consists of a list of cars that may be controlled by a human driver (the simulator car) or by an artificially intelligent ‘driver’. Every car has a number of properties, such as a length, a width, a wheel-base and so on and a number of objects that are needed for driving in the logical world. These objects are a traverser, a sensor and a decision (control) mechanism. In the case of a human-controlled car the decision mechanisms is of course the human driver who, together with the car model, determines the movement of the car. In the case of a computer controlled car the decision mechanism is composed of a set of decision rules. Traffic is implemented in the simulator program as a separate object container class (Van Winsum, 1992, computer program class c_traffic, traffic.c). It contains all kinds of methods for adding or removing cars from a traffic list. The class traffic contains references to cars which may be very different in type. The mechanisms of late binding and virtual classes and inheritance, which are properties of the object-oriented methodology used, ensure that in the future all kinds of other moving objects such as pedestrians and bicyclists may be added to traffic. Every car has its own instantiation of a traverser, sensor and control object. These objects also may be of different types. For example, a human controlled car (the simulator car) would need a somewhat different traverser than a computer controlled car or maybe a pedestrian.

In the case of a human driver, the output of the car model, i.e. the speed and the angle of lateral displacement, are input for the traverser. For computer-controlled cars, the output of the artificially intelligent decision mechanism is the input for the traverser. The traverser calculates the lateral position (with respect to the right side of the road), the longitudinal displacement with respect to the road, it connects the car to the network of roads, checks which path is selected if the car is on an intersection and performs a number of other checks to maintain the position of the car accurate with respect to other traffic. It uses deadreckoning techniques in this process. The traverser is the interface between traffic and the road network and it also connects the simulator car with the interactive traffic world. The traverser is implemented as a separate object class in the simulator program, such that every car has a reference to its own instantiation of a traverser object (Van Winsum, 1992, computer program class, c_traverser, travers.c)

The sensor is an object that really consists of a set of sensors. Both the human controlled car and the computer controlled cars have a sensor object but they use it differently. In general, the sensor is used to ‘look’ into the network. In this way every car, including the simulator car, can evaluate the present type of road and curvature, evaluate the distance and speed of traffic in front etc. This means that the sensor is an interface between the network and the car in that it requests information from the network. The human controlled car uses this information for data storage purposes and to give input to driver support systems. The computer controlled cars use this information for the decisions they are required to make concerning their speed and course. Sensor is implemented as a separate object class in the simulator program (Van Winsum, 1992, computer program class c_sensor, sensor.c). Every car has a reference to its own instantiation of a sensor object.

The control mechanism for the human driver is the human information processing system that uses visual information received via the graphics system, to exert the controls in the car cabin. These car control signals are processed by the car model. The output of the car model is used to update the graphics and as input for the traverser that connects the simulator car to the network. The control mechanism of the computer controlled cars consists of a set of decision rules. Every computer controlled car has rules for different driver tasks on the tactical level. These tasks are related to curve negotiation, car-following, overtaking, negotiating intersections, speed choice on straight roads and processing road sign information. The car evaluates which tasks are presently performed and computes a required speed and lateral position. Since multiple tasks can be performed at the same time, a decision mechanism selects the appropriate speed and lateral position together with the required acceleration and wheel-angle to reach this state, after all tasks have been evaluated for the present car . This results in a natural and human-like behaviour that contributes in an important way to the fidelity of the simulator. For computer controlled robot cars the artificial intelligence is implemented in a separate object class in the simulator program (Van Winsum, 1992, computer program class c_control, control.c).

3.3 Data collection and processing

A large quantity of performance data can be collected with any sampling frequency. Examples are time-to-collision, time-to-intersection, time-to-line crossing, lateral position, speed, acceleration, brake force and so on. The user creates an ASCII text with keywords that specify the sample frequency and the data to sample with that frequency. The data are then sampled during a simulation run and stored into a binary file. The real-time handling of data-storage during a simulator run is controlled by a separate object class c_data that is implemented in the simulator program (Van Winsum, 1992, computer program class c_data, newdata.c).

After a simulator run the data can be visualized and preprocessed with a graphical program written in C++ and X-windows/OSF motif (Van Winsum, 1994, program DATAPROC).

 

For the experiments described in this thesis the real-time sampling of time-based information was required. The variables used are TTC (time-to-collision), TLC (time-to-line crossing) and THW (time-headway during car-following). These measures are defined and implemented as follows:

 

– THW is defined as D/u

for u > 0, else THW = infinite (undefined)

with D = bumper to bumper distance in meters along the path between

the simulator car and the lead vehicle, and

u = speed of simulator car in m/s

 

– TTC is defined as D/(u – ulead)

for (u – ulead) > 0, else TTC = infinite (undefined)

with ulead = speed of lead vehicle in m/s

 

– TLC is calculated differently depending on whether the car is on a straight road or in a curve.

In general, TLC = DLC/u,

for u > 0, else TLC = infinite (undefined)

with DLC = distance to line crossing along the vehicle path and

u = speed of simulator car in m/s.

 

DLC is solved goniometrically using the cosine rule. Normally, the car is not driving in a straight line but it alternates between curves to left and to right. The radius of the vehicle path is calculated using the coordinates of the centerpoint of the curve the car is driving. This centerpoint is calculated as the point where the perpendicular lines through the frontwheel and the rearwheel, with slipangles added to the wheelangles, intersect. Rv, the vehicle radius, is then computed as the distance between the center of gravity of the car and the centerpoint of the vehicle curve. Rv1 then is the distance between the front (left or right) wheel and the centerpoint of the vehicle curve. TLC then measures the time until either the left or right front wheel crosses the left or right lane boundary, given the current vehicle path and speed.

First the case for straight roads is described if the vehicle makes a left turning curve, see figure 2. DLC is computed as a*Rv1. Since Rv1 is known, only a has to be computed, using the cosine rule.

 

 

Figure 2. Determination of the length of the arc DLC for driving on straight roadsections.

– The length of the linepiece A is computed as Rv1-(dleft/cos(ha)), with dleft being the distance between the left frontwheel and the lane boundary (in a line perpendicular on the road) and ha the angle between the line perpendicular on the road and the line from the front wheel to the centerpoint of the vehicle curve.

– The length of the linepiece C is computed as  (2*A*cos(ß)+Ö((2*A*cos(ß))2-4*(A2-Rv12)))/2

Then a = arccos((A2 + Rv12 – C2)/(2*A*C))

and DLC = a*Rv1

 

Figure 3. Determination of the length of the arc DLC for driving on curved roadsections.

 

Figure 3 shows the situation for determining the TLC while the car is negotiating a road curve. Again, DLC is determined as a*Rv1. In this case a is computed differently.

– The length of linepiece A represents the distance between the centerpoint of the roadcurve and the centerpoint of the vehicle curve.

– Angle ß is computed as the angle difference between the line from the centerpoint of the vehicle curve to the centerpoint of the roadcurve and the line from the centerpoint of the vehicle curve to the left front wheel (if the vehicle turns towards the inner lane boundary).

– Angle a1 is computed as arccos((A2 + Rv12 – Rr2)/(2*A*Rv1))

– a= ß – a1 and DLC = a*Rv1

 

In addition to this, vehicle control information was required for the experiments. The position of the accelerator pedal, expressed as a percentage pressed, the position of the brake pedal and the force excerted by the foot on the braking pedal were used in the studies on car-following, while steering wheel angle was used in the study on steering performance and curve negotiation. The results of these control actions, such as speed, acceleration, heading angle and lateral position, were sampled and processed as well.

For every experiment automatic data processing programs were written to extract and process the required data. These data were then transformed into a format suitable for processing by SPSS.

 

3.4 Scenario Specification Language (SSL)

SSL is a user specification language that was defined and implemented as a tool for specification and design of experiments. It contains most of the functionality of the simulator. A description of SSL then essentially gives a description of the functionality of the TRC simulator. For a full specification of the language the reader is referred to the SSL/NSL specification document (Van Winsum, 1994).

An ASCII file with SSL commands is analyzed by a scanner and parser module during initialization of the simulator program and syntactical errors are reported to the user. (Van Winsum, 1994, SSL scanner/parser/interpreter modules). If no syntactical errors are found, the SSL commands are converted to an internal data-structure that is interpreted in real-time by the SSL-interpreter during execution of the simulation process. Since the simulation process is a dynamic process in which the state is determined by SSL specifications, the human driver, the behaviour of traffic and by the process operator who interacts with the computer via the user interface, the course of events is not deterministic. However, SSL commands can be used to force identical situations for all subjects in an experiment. Since SSL commands are often conditional, the state of the traffic world can be queried and events can be triggered if some condition is true or false.

Scenarios are defined in a SSL text file. A scenario is a predefined list of situations with a start and an end condition: the scenario starts when the start condition is fulfilled and terminates when the end condition is fulfilled. A scenario may involve 0..n cars, referred to as participants, in addition to the simulator car. A participant is a car that performs conditional actions. A scenario may be used for controlling traffic and traffic lights, for indicating when data must be stored, for communication with the driver with spoken or written messages, for sending messages to other devices, and so on. SSL is not exclusively a language for specification of traffic situations during an experiment. It also may be used for rapid prototyping of driver support systems, for creating test situations and for debugging. It is important to note that SSL is often used to override default settings and default behaviour. For example, if a computer-controlled car is created with SSL, the car follows its own rules unless specified differently with SSL.

The following is an example of an SSL description.

 

Define Scen[1] {

Var { time; }

Start {

When ( Part[MainTarget].LeadCar != Absent and

Part[MainTarget].DisToLeadCar < 50 );

Scen[].NrTimes := 1;   time := runtime();

}

End {

When ( runtime() – time > 20 );

}

Define Part[1] {

Start {

Part[].CarNr  := Part[MainTarget].LeadCar;

Part[].MaxVelocity := 50/3.6;

}

End {

Part[].MaxVelocity := 100/3.6;

}

}

}

 

This scenario specifies that if there is a lead vehicle and the distance to it is less than 50 meters then this lead vehicle starts to drive with a maximum speed of 50 km/h during 20 seconds. After 20 seconds (at the end of the scenario) this vehicle pulls up to a speed of 100 km/h.

SSL files contain the full script for an experiment and are thus complete specifications of an experiment. This ensures repeatability and detailed documentation of experiments. Since researchers are able to make their own SSL script files they can design and test experiments with a minimal dependency on technical staff and computer programmers.

 

3.5 The use of the simulator in the experiments

The driving simulator offers a number of advantages compared to studying driver behaviour on the road.

1) The sensors of the simulator car and of other cars used in the car-following experiments contain important information that is much harder to obtain with current technology in a real world test situation. This information is vital as input for the control of experiments and data-sampling. For the experiment on curve driving the measurement of TLC information during curve negotiation would be very hard to obtain in real world driving. A simulator is the only practical way to obtain complex measures such as the TLC in curves. Although time-to-collision information may be obtained during on-road experiments it is measured more practically and efficiently in the simulator.

2) All kinds of situations can be generated and tested that would be very hard or impossible to generate in the real world. In the curve negotiation experiment the drivers are required to negotiate a number of different road curves with a specific lane width and radii. Roads with the precise characteristics required by this experiment are very hard to find in the real world. During the car-following experiments the lead vehicle was sometimes required to drive with a certain fixed time-headway in front of the simulator car. This would be difficult to establish in on-road experiments.

3) The responses of drivers to maneuvers too dangerous to be tested in real world driving can easily be tested in the simulator. This is especially important in the car-following and braking experiments discussed in the chapters 5 to 9.

4) Situations can be brought under experimental control. This is important for the comparability of the results since all subjects have encountered precisely the same situations. In on-road experiments traffic density and weather conditions are hard to control. In this respect a simulator has important advantages compared to real world experiments.

 

In the experiments performed in the context of this thesis, the time-based safety margins TLC and TTC play an important role. The perception of TTC has been studied in a large number of experiments (see chapter 6). These studies have given strong support for the idea that TTC information is extracted from the optic flow field. The expansion of the image on the retina gives sufficient information for the extraction of TTC information without requiring the driver to assess speed or distance information. Since the graphical properties of optical perspective, visual angle and optical expansion rate are the same in the TRC simulator as in real world driving, there is reason to assume that the driving simulator is suitable for the type of research discussed in the chapters 5 to 9. An important prerequisite for a smooth optic expansion is a high graphical frame rate. In order to obtain a high frame rate, the visual scenes in all experiments are limited to the essential components while substantial effort has been invested in the design of fast algorithms for traffic handling and experimental control.

 

Comments are closed.