EXTRACTING REAL-TIME DATA FROM A DRIVING SIMULATOR SEYED AMIRHOSSEIN HOSSEINI. Bachelor of Engineering in Civil Engineering QIAU May 2012

Transcription

1 EXTRACTING REAL-TIME DATA FROM A DRIVING SIMULATOR SEYED AMIRHOSSEIN HOSSEINI Bachelor of Engineering in Civil Engineering QIAU May 2012 submitted in partial fulfillment of requirements for the degree MASTER OF SCIENCE IN CIVIL ENGINEERING at the CLEVELAND STATE UNIVERSITY December 2015

2 We hereby approve thesis Of Seyed Amirhossein Hosseini Candidate for the Master of Science in Civil Engineering degree. This thesis has been approved For the Department of Civil Engineering And CLEVELAND STATE UNIVERSITY College of Graduate Studies by Dr. Jacqueline M. Jenkins Department & Date Dr. Norbert Delatte Department & Date Dr. Lutful Khan Department & Date 12/02/2015 Student s Date of Defense

3 ACKNOWLEDGEMENTS I would like to thank Dr. Jacqueline Jenkins for her supervision, support, advice, and commitment to this work as well as Dr. Delatte and Dr. Khan for their time and advice.

4 EXTRACTING REAL-TIME DATA FROM A DRIVING SIMULATOR SEYED AMIRHOSSEIN HOSSEINI ABSTRACT A data extraction program was developed to gain real-time access to the data being generated by DriveSafety research simulators. A socket is defined in the initialization script for a scenario. When the scenario is run, the socket is created and the connection with the data extraction program is established. These particular simulators all use the same HyperDrive Authoring Suite for developing scenarios and therefore the program is suitable for use by all. An initialization script was written to search for the activation of triggers to gain access to data about specific points in the scenario. Similarly, a script was written to search for active data collection zones. The scripts use a virtual trigger which looks for activation at a rate of 60 Hz per second. When the search conditions are met, the values of the specified data collection variables are sent to the data extraction program via the socket. The function of the data collection program was verified by comparing the extracted data to that collected by the simulator during a simulation. For the point data, the two datasets were identical when the data collection rate was set to 60 Hz. At lower rates, the iv

5 percentage of matching records dropped. This result was expected as the recording of trigger activation is not guaranteed at lower rates. For the segment data, the two datasets were again identical when the data collection rate was 60 Hz. These results confirm that the data collection program is functioning as designed. The data extraction program and the simulator collect data at the same time but the simulator data collection file is only accessible after the simulation has ended. The data extraction program makes the data available in real-time and can therefore be used to monitor and evaluate performance as the participant drives the simulator vehicle. This functionality is valuable for evaluating whether participants are learning, have learned or are not learning to drive while driving a practice scenario. The data extraction program also provides the user more flexibility in data collection options. The simulator and the data extraction tool can collect data at different rates and collect a different set of data collection elements. This functionality is valuable when the user is interested in collecting data for two different purposes. Each can be used to filter the data in a different manner. v

6 TABLE OF CONTENTS Page ABSTRACT... iv LIST OF TABLES... ix LIST OF FIGURES... x CHAPTER I... 1 INTRODUCTION RS 100 and RS 600 Driving Simulators Existing Data Collection File Need for Real-Time Data Analysis Purpose Methodology Scope Contribution Organization of Thesis... 6 CHAPTER II... 7 LITERATURE REVIEW McGehee, Lee, Rizzo, Dawson and Bateman (2004) Sahami and Jenkins (2008, 2009) Sahami and Sayed (2010) Sahami and Sayed (2013) Ronen and Yair (2013) Jenkins and Moran (2014) vi

7 2.7 Jenkins and Seck (2014) Jenkins, Lewis and Hosseini (2015) Summary CHAPTER III HYPERDRIVE AUTHORING SUITE TM Creating a Scene Scripting Simulation Events Initialization Script Data Collection Functionality Data Collection and Scripting Variables Data Collection File CHAPTER IV DATA EXTRACTION PROGRAM Functional Requirements Socket Application for Triggers Application for Zones Application for Triggers and Zones Data Extraction Program CHAPTER V VERIFICATION Verification for Triggers Scenario vii

8 5.1.2 Data Analysis Verification for Zones Scenario Data Analysis CHAPTER VI CONCLUSIONS AND DISCUSSION Functioning of the Data Extraction Program Real-time Access Data Collection Filter REFERENCES APPENDICES A. DATA EXTRACTION PROGRAM viii

9 LIST OF TABLES Page Table 1. Comparing Data Collected for a Single Trigger ix

10 LIST OF FIGURES Page Figure 1. RS-100 at Cleveland State University... 2 Figure 2. RS-600 at Cleveland State University... 2 Figure 3. Previous Configuration of the RS-600 at CSU... 3 Figure 4. Application of the Client-to-Server Model for the Socket Figure 5. Initialization Script to Create Socket Figure 6. Modified Initialization Script to Push Trigger Data Figure 7. Modified Initialization Script to Push ZoneName Data Figure 8. Modified Initialization Script to Push Trigger and ZoneName Data Figure 9. A Sample of the Arrangement of the Target Arrows Figure 10. Percent Records Matching Figure 11. Data Collection Zone Amir x

11 CHAPTER I INTRODUCTION The topic of this thesis is the data collection capabilities of research driving simulators, specifically those developed by DriveSafety TM. These simulators have been sold to various research centers and universities in North America, and other countries. The simulators include their Vection TM runtime simulation software and their HyperDrive Authoring Suite TM. The data collection capacities are accessed by the user through the authoring suite. 1.1 RS 100 and RS 600 Driving Simulators Cleveland State University has two DriveSafety research simulators. Illustrated in Figure 1 is the RS-100, which has a Dell 2405 FPW 24 inch monitor, a PlaySeat driving seat, and Logitech steering wheel and pedals. Illustrated in Figure 2 is the RS-600, which has 5 high definition monitors and a partial Ford Focus cab. LCD panels replace the standard rear view and side mirrors. Prior to 2014, the RS-600 had a projector based 1

12 visual display. Figure 3 illustrates the previous visual display system, which included three over projectors and 3 flat projection screens. Figure 1. RS-100 at Cleveland State University Figure 2. RS-600 at Cleveland State University 2

13 Figure 3. Previous Configuration of the RS-600 at CSU These simulators are useful in studying the interaction between the driver and the driving environment. For instance, drivers response to different geometric alignments, traffic control devices and strategies, and traffic movements can be captured and examined. Additionally, the impact of the condition (e.g. distracted and impaired) of the drivers on their driving performance under various driving situations can be studied. The simulated environment provides a controlled environment where experiments can be conducted without the risk of causing real traffic collisions or injuries. 1.2 Existing Data Collection File The authoring suite is an advanced scenario development tool. It includes a number of libraries of preprogrammed simulation entities and scripting commands, and provides users the flexibility to program added functionality. Each scenario is developed by defining the size of the scenario space or drawing grid, then creating a scene and adding 3

14 entities, and simulation events. When the data collection functionality is enabled, details about the movement of the simulator vehicle and other entities during the simulation are written to a collection file. That file is available after the simulation for analysis. 1.3 Need for Real-Time Data Analysis Having real-time access to the data would be beneficial in tracking the performance improvement of those driving practice scenarios. Such scenarios are used to provide participants time to get comfortable with the simulated driving environment. Previous studies (McGehee, Lee, Rizzo, Dawson and Bateman (2004), Sahami and Jenkins (2008, 2009), Sahami and Sayed (2010, 2013), Ronen and Yair (2013), Jenkins and Moran (2014), Jenkins and Seck (2014) and Jenkins, Lewis, and Hosseini (2015)) have shown that not all participants improve and that the rate of improvement varies across people. With real-time data, performance trends could be monitored and used to screen participants who are not improving, and identify those who have improved and are ready to begin driving the subsequent experimental scenarios. 1.4 Purpose The purpose of this thesis was to extend the data collection capabilities of the DriveSafety TM research simulators by developing a program to extract the values of the data collection variables in real-time. The program needed to extract data when the simulator vehicle reached specific points in the scenario and/or traveled along specified road segments. The new functionality needed to be verified to ensure that it worked as intended. 4

15 1.5 Methodology The data extraction program was developed in three phases. During the first phase, a connection with the driving simulation was established. During the second phase, the values of the data collection variables were extracted for simulation frames when location triggers were activated. During the third phase, the values were extracted for frames within segments identified with specific zone names. At the end of the second and third phases, the functionality of the program was verified by comparing the data collected by the simulator and the data extracted by the program. 1.6 Scope The development of the data extraction program is one piece of a larger research project, focused on monitoring driver behavior during practice scenarios to assess whether drivers have learned to drive the simulator vehicle. To monitor the improvement in performance, gaining access to the driving simulator data is necessary. The data extraction program provides that functionality. This research is focused on establishing a connection with the simulator and extracting data in real-time. In the future, a graphical user interface (GUI) will be added to prove the user an easy way for selecting the desired data elements, manipulating the data into a preferred performance measure, and a graphical output to view the change in that measure while the simulator vehicle is being driven. 5

16 1.7 Contribution The data extraction program is an extension of the existing data collection functionality of the DriveSafety TM HyperDrive Authoring Suite TM. The intended benefit is the ability to monitor performance in real time. This will facilitate the screening of those participants who are not improving. It will also facilitate the identification of those who have improved and are ready to drive the subsequent experimental scenarios. The data extraction program can also be used to collect a filtered dataset, different than that collected by the driving simulator. The filtering would be done by selecting either a reduced number of data collection elements, or collecting data for specific locations and/or segments. 1.8 Organization of Thesis This thesis is organized into 6 chapters. Chapter I provides an introduction to the thesis topic and identifies the research need. The purpose, methodology and potential contributions of the work are also provided. Chapter II contains a review of the literature confirming that driver performance generally improves during a practice scenario but varies across individuals. Chapter III provides details about the functionality of the DriveSafety TM HyperDrive Authoring Suite TM, as background information for the development of the data extraction program. Chapter IV contains a detailed description of the initialization scripts and the data extraction program, with the actual code of the program provided in Appendix A. Chapter V details the verification tests that were performed to ensure that the program was functioning as designed. Chapter VI includes the conclusions and discussion about the development of the program. 6

17 CHAPTER II LITERATURE REVIEW In this chapter, the previous research examining the improvement in performance while driving a simulator is reviewed. Performance refers to both steering and speed control for a variety of driving tasks. A discussion of what is known could be organized by task, by type of control, or a combination thereof. Since the field is rather small, such organization would find many of the combinations sparse. Therefore, this literature review was organized chronologically and thus illustrates the progression of the simulation community s understanding about how performance improves over time. The results illustrate the need for providing participants time to practice and the benefit of monitoring the performance improvement in real-time. 2.1 McGehee, Lee, Rizzo, Dawson and Bateman (2004) McGehee, Lee, Rizzo, Dawson and Bateman (2004) examined the time it took for research participants to adapt their steering control of a fixed base driving simulator. The study was carried out using the University of Iowa s Simulator for Interdisciplinary 7

18 Research in Ergonomics and Neuroscience (SIREN), developed by DriveSafety. Fifty two older drivers (52 to 89 years old) and 28 younger drivers (24 to 35 years old) participated in the study by driving for approximately 25 minutes on a rural two-lane road. The steering performance of the participants on three eventful road segments was examined by analyzing various steering and lane position measures. The results generally supported their hypotheses that drivers would decrease their steering variation and adapt within 5 minutes, and that younger drivers would exhibit less variation in both steering and lane position than older drivers. In their review of how training was being conducted McGehee, Lee, and Rizzo (2004) made the assertion that specific measurements of adaptation and training were needed. In their analysis they used the number of 6 steering reversals per minute as a measure to track performance and defined the threshold for normal driving as no more than two 6 steering reversals per minute. 2.2 Sahami and Jenkins (2008, 2009) Sahami and Jenkins (2008) examined the potential of modelling the improvement in driving performance using a learning curve as a way to recognize the occurrence of adaptation. They modeled the acceleration and deceleration of five participants making speed changes every 40 seconds along a 29 km (18 mile), two-lane, rural road. The scenario was developed for the University of British Columbia s UBCDrive driving simulator. This simulator was developed by Oktal and features a mock-up of a cab and 5 flat screen televisions present the driving environment. 8

19 An ideal speed profile, representing the maximum performance of the simulator, was compared to that of the participants to arrive at an error measurement for each speed change. The error values for successive speed changes were plotted. Two trends were noted. First, those that showed continued improvement compared well to a negative exponential curve were said to be adapting or learning. Second, those who exhibited a quick improvement followed by a consistent error measure were said to have adapted. The remaining participants were identified as not adapting. Sahami, Jenkins and Sayed (2009) continued this work by running four additional participants and examining the cost and cumulative cost per trial using negative exponential curves. The use of the cumulative cost per trial trend allowed them to better distinguish between not adapting and adapted patterns. 2.3 Sahami and Sayed (2010) Sahami and Sayed (2010) examined the performance of participants negotiating left and right horizontal curves. Twenty five participants, 16 males and 9 females ranging in age from 20 to 64 years, drove a series of 18 horizontal curves. Half curved to the left and half curved to the right. The position of the vehicle in the lane was shown as a white horizontal bar so participants could see whether or not the simulator vehicle was encroaching or passing over a lane line. Participants were instructed to go as fast as possible and keep the vehicle in the center of the lane. Two participants lost control of the vehicle and were removed from the study. For the remaining 23 participants, the steering and speed performance through each curve was examined. 9

20 The steering performance, measured as the lateral shift from the center of the lane was found to decrease for all 23 participants for the left and right curves. An increase in the average speed was found for 21 participants on the left curves and 22 participants on the right curves. Sahami and Sayed had asked participants to indicate during the drive, when they felt comfortable. Their time to adapt was recorded and compared to their performance data. Overall, there was no significant correlation between the self-reported adaptation times and the times when performance became consistent. In addition, the overall average time reported was 122 seconds, which was far less than the performance based calculated average of seconds. 2.4 Sahami and Sayed (2013) In a follow-up study, Sahami and Sayed introduced a slalom scenario followed by the same 18 curve scenario used in their 2010 study. The slalom scenario had 12 trials of a slalom task designed with 7 cones spaced 100 feet (30.48 m) apart on a 20 m (65.6 ft) wide straight segment of roadway. Twenty seven participants (9 females and 18 males) drove both scenarios, developed for the University of British Columbia s UBCDrive driving simulator. During the slalom scenario, participants were told that their average speed through each slalom would be evaluated. Out of 324 slalom trials, 19 were removed because the participant lost control of the simulator vehicle. Analysis of the performance on the slalom task showed that 7 males and 4 females had adapted, 10 males and 5 females were still adapting, and 1 male was not adapting. 10

21 For the subsequent curve scenario, the average speed and the lateral shift from the center of the lane was analyzed. On the left curves, 9 males and 7 females showed improvement in speed control, while only 1 male showed improvement in steering control. On the right curves, 8 males and 3 females had an increase in speed, while 2 males and 2 females showed an improvement in lateral position. Sahami and Sayed conducted comparisons of the performance on the curve scenario between those who had adapted during the slalom scenario and those who hadn t adapted. They found that adaptation to the slalom task had a significant effect in reducing the adaptation time to the curve negotiation task, and interpreted that to mean that a significant amount of skill transfer occurred. 2.5 Ronen and Yair (2013) Ronen and Yair (2013) investigated whether more time is needed for participants to adapt while driving more complex roads. This hypothesis was based on the idea that driving demand is greater for curved roads than straight roads, as demonstrated by Oron- Gilad and Ronen (2007). Three different roads were used, which differed based on culture (i.e. rural and urban), geometry (i.e. curved and straight) and control (i.e. interrupted and uninterrupted). Three driving scenarios, one for each type of road being tested, were developed for a STI-SIM fixed-based driving simulator. This simulator was developed by Systems Technology Inc. and featured a full size vehicle. The environment was projected onto a 3 x 3 m (9.8 x 9.8 ft) screen providing a 40 forward field of view. 11

22 Forty five participants (34 males and 11 females) with an average age of 23.6 years were recruited. Each participant drove only one of the scenarios such that each scenario was driven by 15 participants. During the scenario, driving performance measures were recorded along with heart rate and the participants self-assessed level of adaptation. The characteristic negative exponential pattern for learning was found to fit the: root mean square of the lane position for the curved road; root mean square of longitudinal speed for the urban roads; root mean square steering wheel deviations for curved, urban, and straight roads; and number of road edge excursions for curved and straight roads. For each of the different road types, the distance driven for the various performance measures to improve and stabilize was determined: to 19.5 km (9.1 to 12.1 miles) for the curved road; 9.14 to 15.2 km (5.7 to 9.4 miles) for the urban road; and to km (6.8 to 13.6 miles) for the straight road. For the curved and urban roads, the self-assessed distance to adapt were km (9.2 miles) and 8.92 km (5.5 miles) respectively which were smaller than that calculated based on the performance measures. For the straight road the self-assessed distance of 12.2 km (7.6 miles) was comparable to the calculated distance. The effect of the road type on heart rate and heart rate variability was also examined. The straight road was associated with the highest decrease in heart rate and the highest heart rate variability. These results support the idea that the different roads have different demands on the driver such that the straight road was the least demanding of the three tested roads. 12

23 2.6 Jenkins and Moran (2014) Jenkins and Moran (2014) examined the improvement in steering control of participants making a series of lane changes. The scenario was developed for Cleveland State University s DriveSafety RS-600 driving simulator. The simulator included a partial Ford Focus cab and used three overhead projectors to present a forward field of view of approximately 150. The scenario was of a 4 lane divided highway in an urban setting. The desired travel lanes, and therefore the desired lane changes, were indicated using target arrows place either in the center of the lane or along the lane line between the two lanes. The target arrows were arranged into twenty groups of five arrows. The groups were spaced by 200 m (656 ft) and the individual target arrows were spaced 40 m (131 ft) apart. Twenty five participants (12 females and 13 males) were instructed to drive 25 mph (40 km/h) and drive through all 100 target arrows. The distance between the center of the front bumper and the center of the target arrow, the moment the target arrow was reached was defined as a lateral offset distance and used as a measure of performance reflecting steering accuracy. One participant exhibited consistently good performance from the very first target arrow, as indicated by small lateral offset distances. The remaining participants had larger lateral offset distances for the first two groups of target arrows and demonstrated a remarkable improvement during the third group. 2.7 Jenkins and Seck (2014) Jenkins and Seck (2014) used a similar lane changing task to examine both steering and speed control. Two scenarios were developed for the Cleveland State University s 13

24 DriveSafety RS-600 driving simulator. For each scenario, a 6 lane divided freeway was used and lane changes were identified by pairs of cones placed on the lane lines to indicate the desired travel lane. In the first scenario, there was a total of 50 lane changes. After each group of 5 lane changes, the speed limit changed. The lane changes were spaced such that the travel time at the speed limit would be 3.6 seconds between lane changes. Participants were instructed to adhere to the posted speed limits. In the second scenario, there was no posted speed limit. Participants made a series of 20 lanes changes. The first 10 were spaced 80 m (262 ft) apart and the next 10 were spaced 104 m (341 ft) apart to encourage higher travel speeds. Participants were instructed to travel as fast as they felt comfortable while still maintaining control of the simulator vehicle. Forty participants drove the two scenarios, half starting with the first scenario, the other half starting with the second scenario. After excluding poor data sets, and focusing on the first 20 lane changes driven by each participant, there were 20 lane changes for 18 participants (10 males and 8 females) for the first scenario and 20 lane changes for 18 participants (11 males and 7 females) for the second scenario that were analyzed. The lane position of the simulator vehicle at each set of cones and the travel time from the previous set of cones was combined into a cost value. The cost values and cumulative cost per lane change over successive lane changes was examined. For the first scenario, 10 participants were identified as having learned or adapted and 2 were identified as still learning. For the second scenario, 7 participants were identified as having learned and 3 were still learning. The first scenario was shown to be more efficient, such that directing 14

25 participants to drive a range of speeds while making lane changes accelerates their learning thus improving their control of the simulator vehicle. 2.8 Jenkins, Lewis and Hosseini (2015) Jenkins, Lewis and Hosseini (2015) investigated whether practicing one steering task improves performance on a subsequent steering task. The experiment was conducted using Cleveland State University s DriveSafety RS-100 driving simulator which has a mock-up cab with Logitech steering wheel and pedals, and a single, 24 inch Dell monitor. The three steering tasks were: 1) lane keeping (LK); 2) changing lanes every 85 m (279 ft) (85); and 3) changing lanes every 65 m (213 ft) (65). A rural 4 lane divided freeway was used to develop the scenario and the lane changes were identified using target arrows to indicated the desired travel lanes, similar to the study by Jenkins and Moran (2014). Participants drove one of four sequences: LK-65-85; LK; LK; and LK A total of 44 participants drove, 11 were assigned to each sequence. The lane position of the simulator vehicle at each target arrow and the travel time from the previous target arrow were combined into a cost value for each of the lane changes. For each sequence, the average cost for the participants was calculated and found to decrease over successive lane changes, thus indicating that participants were learning. When differences between the groups of participants for each sequence (i.e. age and sex) were taken into account, the effect of practicing one steering task on the performance of a subsequent steering task was not significant. 15

26 2.9 Summary A variety of steering and speed control measures have been used to evaluate driving performance and whether performance improves while practicing to drive a simulator vehicle. McGehee et al (2004) found that drivers decrease their steering variation and adapt within 5 minutes, and that younger drivers exhibit less variation in both steering and lane position than older drivers. Sahami and Jenkins (2008, 2009) found that learning and experience curves could be used to interpret the improvement in performance to identify those who are adapting, those who have adapted, and those who are not adapting. Sahami and Sayed (2010, 2013) showed that the learning during a slalom task transferred to the performance of a subsequent curve negotiation task. They also found the participants self-assessed time to adapt to be smaller than when the performance actual became consistent. Ronen and Yair (2013) found that the time to adapt differed depending upon the type of road and the measure used to assess performance. Jenkins and Moran (2014), Jenkins and Seck (2014) and Jenkins, Lewis, and Hosseini (2015) all used a lane changing task to evaluate adaptation. Jenkins and Moran found that participant either adapted very quickly or required 10 to 15 lane changes to exhibit consistent steering control. Jenkins and Seck found instructing participants to drive a variety of speeds was more efficient in terms of improving performance than allowing participants to choose a comfortable speed. Jenkins, Lewis and Hosseini found that improvement continued over subsequent steering tasks but that the type of steering task first practiced was not significant. Together this work illustrates that not all participants improve and that the rate of improvement varies across people, thus supporting the need to track individual participants in real time to assess their improvement. 16

27 CHAPTER III HYPERDRIVE AUTHORING SUITE TM In this chapter, the functionality of the HyperDrive Authoring Suite TM is reviewed to understand how the software is used to develop driving scenarios and capture data during simulations. The scenario development process begins with defining the size of the scenario space or drawing grid, then creating a scene and adding entities, and simulation events. 3.1 Creating a Scene The scene is created by selecting and arranging predefined roadway tiles, each representing a particular combination of topography, road type and alignment, traffic control, and setting. The roadway tiles are generally 200 m (656.2 ft) long by 200 m (656.2 ft) wide although some have extended lengths and/or widths. Each tile can be rotated by 90, 180, or 270 before being placed on the drawing grid. 17

28 3.2 Scripting Simulation Events The scene is transformed into a scenario by adding entities and simulation events. Static objects, such as signs, people, animals, vehicles, etc. are positioned in the scene to specific Cartesian coordinates (x, y, z) on the grid and oriented as desired. Dynamic objects, such as vehicles, are then added to the scene and controlled using scenario tools. Scenario tools include start points, location-based triggers, time-based triggers, routes, and paths. The start point is placed in the scene to identify the location and orientation of the simulator vehicle at the start of the scenario. Triggers initiate simulation events. The location triggers are placed in the scene at specific locations. When they are activated by the simulator vehicle or another specified entity the associated event is executed. The time triggers are very similar except that a lag from the time of activation to the time the event occurs can be controlled. Routes are used to schedule the turns a vehicle will make at intersections while paths define the exact positioning of the entity as it moves. Triggers are very flexible and therefore powerful scenario tools for the scenario developer. A single command or a complex combination of commands, written in Tool Command Language (TCL), can be included in a trigger. The authoring suite contains a library of available commands. 3.3 Initialization Script Simulation events can also be added to the scenario by defining them in an initialization script, which is global to the simulation. When the simulation is executed, the initialization script is run. 18

29 3.4 Data Collection Functionality To collect data during the execution of the simulation, the initialization script must include the command SimSelectDataCollectionElements. This command defines which data collection variables will be collected. If left undefined, a default set of variables will automatically be selected. The user can also define custom variables using the command SimCreateDataCollectionElement in the initialization script. The selection of the data collection element, default or otherwise, cannot be changed outside of the initialization script. The data collection function is then turned on/off using the SimCollectData command. When data collection is turned on, the specified elements are written to a data file at the specified rate, up to 60 Hz. The data collection command can be included in the initialization script or any other script, like that for a location trigger or time trigger. 3.5 Data Collection and Scripting Variables Version of the HyperDrive Authoring Suite contains 48 standard variables describing the simulation and the movement of the simulator vehicle and other entities. There is an additional variable which contains 34 digital inputs about the hardware of the simulator. The default variables for data collection are: ZoneName the name of the active data collection zone; Time the time in seconds from the beginning of the simulation; Frame the number of simulation frames from the beginning of the simulation; Velocity the speed of the simulator vehicle in meters per second; 19

30 LanePos the position of the simulator vehicle in the current lane, measured from the center of the vehicle to the center of the lane in meters; Steer the position of the steering wheel in degrees from center; Accel the position of the accelerator pedal, normalized from 0 for not depressed to 1 for fully depressed; Brake - the position of the accelerator pedal, normalized from 0 for not depressed to 1 for fully depressed; SubjectHeading the heading of the simulator vehicle in degrees where north is 0, east is 90, south is 180 and west is 270 ; SubjectX the x coordinate position of the simulator vehicle in meters; SubjectY - the x coordinate position of the simulator vehicle in meters; LatAccel the lateral component for the acceleration of the simulator vehicle; LongAccel the longitudinal component for the acceleration of the simulator vehicle; ActiveTrigger the name of the trigger activated during the simulation frame; and Collision the name of the object in collision with the simulator vehicle during the simulation frame. The values of all the data collection and simulation variables are updated for every frame of the simulation. The frame rate is ms or 60 Hz. 3.6 Data Collection File When the simulation is run, with the data collection functionality enabled, a data file is produced and saved. The file is not accessible during the simulation, only after the 20

31 simulation has been stopped. The file is a space delimited file with a datacol extension. Opening this file in Excel results in a spreadsheet, where the first row contains the names of the data collection variables and each subsequent row contains the values of the variables for every frame while the data collection function of the simulator was on. 21

32 CHAPTER IV DATA EXTRACTION PROGRAM In this chapter, the functional requirements for the data extraction program are provided, followed by a description of the socket and data extraction program. 4.1 Functional Requirements The purpose of the data extraction program is to gain real-time access to the data already being generated by the driving simulator. To do so, the following functional requirements needed to be satisfied: Establish and external connection to the simulator; Provide a one-way data flow from the simulator; Read the data; Display the data on the screen in real-time; and Store the data in a text file. The operation of the data extraction program then needed to be verified to ensure that it functioned as intended, thus satisfying these functional requirements. In addition, the 22

33 continuation of the data collection functionality of the simulator needed to be verified to ensure that the data extraction program was not causing any unexpected problems. The intent was to have the normal data collection capabilities of the simulator intact while providing a real time data collection function. 4.2 Socket A socket is an application programming interface (API) that commonly helps in the interaction among client servers. With the data extraction program functioning as the server and the simulator functioning as the client, the client-to-server model was applied, as seen in Figure 4. The connection to the driving simulator was made through the initialization script shown on Figure 5. The connection address is indicated, a socket is created, and the connection port is stored and configured. The script then signals the data extraction program to confirm the connection. Reading the socket defines a virtual trigger with an execution rate of 60 Hz. The data extraction program contains the other end of the socket. It receives the IP address, port, and socket information from the simulator. The information is checked and when valid, establishes the connection. If the information is found to be invalid, a message error is returned and the connection is terminated. 23

34 Figure 4. Application of the Client-to-Server Model for the Socket 24

35 set hostip set hostport 4444 set theinputsocket 0 set str "" proc sockread {} SimOutputMessage "Connecting to External PC: $::hostip on Port: $::hostport" set ::theinputsocket [socket $::hostip $::hostport] fconfigure $::theinputsocket -buffering line -blocking false puts $::theinputsocket "Simulator is Connected and Program Receives Data" VTriggerCreate pollsock { sockread } VTriggerAdd pollsock 60 Hz Figure 5. Initialization Script to Create Socket Application for Triggers To direct the simulator to push information about the activation of triggers through the socket, the initialization script was modified, as shown in Figure 6. When all the triggers in the scenario are not active the data collection variable ActiveTrigger contains the value - and no data is passed from the simulator. When a trigger is activated, the variable ActiveTrigger contains the unique name of the specific trigger activated and the values of the specified data collection variables are then pushed through the socket. All triggers in the scenario must be assigned a unique name. The entity which is permitted to activate the trigger is defined in the properties for each trigger. The size of 25

36 the activation area is also defined. The trigger is only activated during the first simulation frame that the entity contacts the activation area of the trigger. set hostip set hostport 4444 set theinputsocket 0 set str "" proc sockread {} { if { $::ActiveTrigger!= "-" } { puts $::theinputsocket "$::ActiveTrigger Accel= $::Accel Brake= $::Brake LanePos= $::LanePos LatAccel= $::LatAccel LongAccel= $::LongAccel Steer= $::Steer SubjectHeading= $::SubjectHeading SubjectX= $::SubjectX SubjectY= $::SubjectY Time= $::Time Velocity= $::Velocity " } } SimOutputMessage "Connecting to External PC: $::hostip on Port: $::hostport" set ::theinputsocket [socket $::hostip $::hostport] fconfigure $::theinputsocket -buffering line -blocking false puts $::theinputsocket "ZoneName Accel Brake LanePos LatAccel LongAccel Steer SubjectHeading SubjectX SubjectY Time Velocity " puts $::theinputsocket "Simulator is Connected and Program Receives Data" VTriggerCreate pollsock { 26

37 sockread } VTriggerAdd pollsock 60 Hz SimCollectData On 60 NONE Figure 6. Modified Initialization Script to Push Trigger Data Application for Zones To direct the simulator to push information about the presence of a particular entity in a specified segment of roadway, or zone, the initialization script was modified, as shown in Figure 7. When the subject vehicle is not in a specified zone, the value of the data collection variable ZoneName is - and no data is passed from the simulator. When the simulator vehicle is in a specified zone, the name of the zone is then contained in the ZoneName variable and the values of the specified data collection variables are pushed through the socket. set hostip set hostport 4444 set theinputsocket 0 set str "" proc sockread {} { if { $::ZoneName!= "-" } { puts $::theinputsocket "$::Zonename Accel= $::Accel Brake= $::Brake LanePos= $::LanePos LatAccel= $::LatAccel LongAccel= $::LongAccel Steer= 27

38 $::Steer SubjectHeading= $::SubjectHeading SubjectX= $::SubjectX SubjectY= $::SubjectY Time= $::Time Velocity= $::Velocity " } } SimOutputMessage "Connecting to External PC: $::hostip on Port: $::hostport" set ::theinputsocket [socket $::hostip $::hostport] fconfigure $::theinputsocket -buffering line -blocking false puts $::theinputsocket "ZoneName Accel Brake LanePos LatAccel LongAccel Steer SubjectHeading SubjectX SubjectY Time Velocity " puts $::theinputsocket "Simulator is Connected and Program Receives Data" VTriggerCreate pollsock { sockread } VTriggerAdd pollsock 60 Hz SimCollectData On 60 NONE Figure 7. Modified Initialization Script to Push ZoneName Data Application for Triggers and Zones To direct the simulator to push information about the activation of trigger and the presence of a particular entity in a specified segment of roadway, or zone, the initialization script was modified, as shown in Figure 8. 28

39 set hostip set hostport 4444 set theinputsocket 0 set str "" proc sockread {} { if { $::ActiveTrigger!= "-" } { puts $::theinputsocket "$::ActiveTrigger Accel= $::Accel Brake= $::Brake LanePos= $::LanePos LatAccel= $::LatAccel LongAccel= $::LongAccel Steer= $::Steer SubjectHeading= $::SubjectHeading SubjectX= $::SubjectX SubjectY= $::SubjectY Time= $::Time Velocity= $::Velocity " } if { $::ZoneName!= "-" } { puts $::theinputsocket "$::ZoneName Accel= $::Accel Brake= $::Brake LanePos= $::LanePos LatAccel= $::LatAccel LongAccel= $::LongAccel Steer= $::Steer SubjectHeading= $::SubjectHeading SubjectX= $::SubjectX SubjectY= $::SubjectY Time= $::Time Velocity= $::Velocity " } } SimOutputMessage "Connecting to External PC: $::hostip on Port: $::hostport" set ::theinputsocket [socket $::hostip $::hostport] fconfigure $::theinputsocket -buffering line -blocking false 29

40 puts $::theinputsocket "ZoneName Accel Brake LanePos LatAccel LongAccel Steer SubjectHeading SubjectX SubjectY Time Velocity " puts $::theinputsocket "Simulator is Connected and Program Receives Data" VTriggerCreate pollsock { sockread } VTriggerAdd pollsock 60 Hz SimCollectData On 60 NONE Figure 8. Modified Initialization Script to Push Trigger and ZoneName Data 4.3 Data Extraction Program The program was written in C++ and in provided in Appendix A. The data extraction program contains the other end of the socket, and when a connection is successfully established, the program receives the data pushed from the simulator. When the conditions set for Active Trigger and/or ZoneName are met, the data is pushed though the socket and received by the data extraction program. The data is printed to the screen in real time and written to a shared memory. Any set of standard or user-defined data collection variables defined in the initialization file can be included in the data packet received by the data extraction program. 30

41 CHAPTER V VERIFICATION In this chapter, the results of two verification tests are presented. These results show that the data extraction program was working as intended and did not compromise the data collection functionality of the simulator. 5.1 Verification for Triggers The data extraction program was tested to ensure it was functioning correctly when using the initialization script to pass values when triggers were activated. The testing included programming a scenario that included triggers, driving the scenario, and comparing the data collected by the simulator with that collected by the data extraction program Scenario The scenario included 5 kilometers of a rural 4-lane divided freeway. HyperDrive roadway tiles fwy4r_002, fwy4r_003, fwy4r_004, and fwy4r_005 were used to provide some variation in the roadside environment. Sixty target arrows were placed in 31

42 the center of the travel lanes to create a slalom pattern. The first 30 arrows were spaced 65 meters apart and the following 30 arrows were placed 85 meters apart. A sample of the arrangement of several target arrows is shown on Figure 9. Figure 9. A Sample of the Arrangement of the Target Arrows Location triggers were placed at the same locations as each of the target arrows. So when the subject (i.e simulator) vehicle drove through a target arrow, the location trigger would be activated. The initialization script, previously provided in Figure 6, was used. Each time a location was activated, the values of the default data collection variables were pushed through the socket, received by the data extraction program, written to the screen and stored. 32

43 The scenario was driven 7 times. Each time, the data collection rate for the simulator was changed. Data was collected at 1 Hz, 10 Hz, 20 Hz, 30 Hz, 40 Hz, 50 Hz and 60 Hz. The socket processed data packets at 60 Hz for each simulation Data Analysis To verify that the socket and data extraction program were working as intended, the data collected by the simulator and the data collected by the data extraction program were compared. It was expected that the data would be the same, if the program was working as intended and not disrupting the data collection functionality of the simulator. A sample of the data for one trigger is provided in Table 1. When the simulator (S) was collecting data at 60 Hz, 50 Hz, 40 Hz, and 20 Hz the data collected by the simulator was identical to the data received by the data extraction program (EP). These entries are highlighted in Table 1. At 30 Hz, 10 Hz, and 1 Hz, an exact match was not found. When the data matched exactly, the data file created by the simulator for that frame included a value for the ActiveTrigger variable. When there was not an exact match, the simulator data file did not have a frame for the activation of that specific location trigger. This outcome was expected, as the manual for the HyperDrive Authoring Suite TM states that there is no guarantee of obtaining ActiveTrigger data unless the data collection rate is set to 60 Hz. If the simulator data collection rate is set lower than 60 Hz, the activation of the location trigger may not align with a particular frame and therefore not captured. The data extraction program captured data for the activation of every location trigger because the virtual trigger defined in the initialization file polls for data at a rate of 60 Hz, 33

44 regardless of the defined data collection rate. Thus the data captured by the simulator and the data sent to the data extraction program differ. Table 1. Comparing Data Collected for a Single Trigger Source Time Velocity LanePos Heading SubjectX SubjectY S 1 Hz EP S 1 Hz S 10 Hz EP S 10 Hz S 20 Hz EP S 30 Hz EP S 30 Hz S 40 Hz EP S 50 Hz EP S 60 Hz EP

45 The activation of the location triggers, and therefore the number of identical records between the simulator data file and the file generated by the data extraction program were compared. Figure 10 shows the percentage of identical records as a function of the simulator data collection rate. As expected, the higher the data collection rate, the greater the chance the trigger activation was captured by the simulator. The date extraction file contained records for every location trigger confirming the data extraction program was working. At a data collection rate of 60 Hz, the trigger information for the two data sets were identical. Figure 10. Percent Records Matching 35

46 5.2 Verification for Zones The data extraction program was tested to ensure it was functioning correctly when using the initialization script to pass values for when the data collection variable ZoneName was used to identify specific road segments. The testing included modifying the previously programmed scenario to include a data collection zone, driving the scenario, and comparing the data collected by the simulator with that collected by the data extraction program Scenario To identify an active data collection zone, two location triggers were used. The first assigned a value to the data collection variable ZoneName and the second removed that assigned value, using the script SimSetZoneName. The result was a section of roadway where the ZoneName had a value and therefore met the condition for the socket to pull the values of the data collection variable and send them to the data extraction program. Two such zones were created and named Amir1 and Amir 2. The data collection zone Amir1 is shown on Figure 11. Before the subject (i.e. simulator) vehicle entered the data collection zone, the ZoneName variable had a - value. Once the vehicle drove over the first location trigger, the variable was assigned the value Amir and data began to be sent to the data extraction program. That continued until the next location trigger was reached which changed the value of ZoneName back to -. The process repeated for the second data collection zone, Amir2. 36

47 Amir1 Figure 11. Data Collection Zone Amir1 The data collection rate was set to 60Hz to ensure that the start and end of the data collection zone would be captured by the simulator. If a lower data collection rate was used, the simulation frame for the activation of the location trigger may not be one being collected and therefore the activation may not be captured Data Analysis With both the data collection rate and the virtual trigger for the socket set to 60 Hz, it was expected that the data collection files created by the simulator and the data extraction program would have identical values for all common data collection variables. The two data sets were compared and this expectation was verified, thus confirming that the data extraction program is working as expected. 37