ISSN 1055- 1425
January 2011
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation, and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Report for FHWA Exploratory Advanced Research Program
Cooperative Agreement DTFH61- 07- H- 00038
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
Cooperative Adaptive Cruise Control:
Testing Drivers’ Choices of Following
Distances
UCB- ITS- PRR- 2011- 01
California PATH Research Report
Christopher Nowakowski, Steven E. Shladover,
Delphine Cody, et al.
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
Cooperative Adaptive Cruise Control:
Testing Drivers’ Choices of Following Distances
PATH Research Report for
FHWA Exploratory Advanced Research Program
Cooperative Agreement DTFH61- 07- H- 00038
Christopher Nowakowski, Steven E. Shladover, Delphine Cody, Fanping Bu,
Jessica O’Connell, John Spring, Susan Dickey, David Nelson
i
Abstract
A Cooperative Adaptive Cruise Control ( CACC) system has been developed by adding a
wireless vehicle- vehicle communication system and new control logic to an existing
commercially available adaptive cruise control ( ACC) system. The CACC is intended to
enhance the vehicle- following capabilities of ACC so that drivers will be comfortable using it at
shorter vehicle- following gaps than ACC. This can offer a significant opportunity to increase
traffic flow density and efficiency without compromising safety or expanding roadway
infrastructure.
This report describes the design and implementation of the CACC system on two Infiniti FX- 45
test vehicles, as well as the data acquisition system that has been installed to measure how
drivers use the system, so that the impacts of such a system on highway traffic flow capacity and
stability can be estimated. The results of quantitative performance testing of the CACC on a test
track are presented, followed by the experimental protocol for on- road testing with human
subjects. Finally, the results from the field testing by 16 naïve drivers are presented to show the
user acceptance and quantitative measurements of how these drivers used the ACC and CACC
systems, and how these systems affected their choice of car following gap.
Key Words: Adaptive Cruise Control, Cooperative Adaptive Cruise Control, Vehicle Following,
Driver Behavior, Vehicle- Vehicle Communication
ii
Executive Summary
This report provides documentation of the design and implementation of a Cooperative Adaptive
Cruise Control ( CACC) system on two Infiniti FX- 45 vehicles that were provided to the project
by Nissan Motor Company. The CACC system has been developed by adding a wireless
vehicle- vehicle communication system and new control logic to an existing commercially
available adaptive cruise control ( ACC) system. The CACC is intended to enhance the vehicle-following
capabilities of ACC so that drivers will be comfortable using it at shorter vehicle-following
gaps than ACC, offering a significant opportunity to increase traffic flow density and
efficiency without compromising safety or expanding roadway infrastructure.
The CACC concept is defined and described, and then the specific implementation for this
project is described. The control logic of the CACC system is explained, and its implementation
on the test vehicles is described. Quantitative measurements of the performance of the system in
controlled tests at Nissan’s Arizona proving ground are shown so that its advantages over
conventional autonomous ACC can be understood. The enhanced performance makes it possible
to operate the CACC at time gaps between 0.6 s and 1.1 s, compared to a range of 1.1 s to 2.2 s
for the ACC. The shorter CACC gaps could enable significant highway capacity increases,
while the longest CACC gap was set identical to the shortest ACC gap to provide a direct
comparison.
Because the most important experiments involving these vehicles require measurements of the
performance and behavior of drivers chosen from the general public, an important element of the
project is a digital data acquisition system that records how the vehicles are driven. This system
is used to record baseline driving data when the test drivers drive one of the vehicles as their
regular personal car for two weeks, recording quantitative measurements of vehicle motions and
driver actions, together with five channels of video data. When the same drivers drive the other
vehicle using CACC during comparable test drives accompanied by a PATH researcher, the
same measurements are recorded for comparison with the baseline driving. The design of the
data acquisition system and the information that it records are described here for reference. The
experimental protocol for the driver tests is explained and the questionnaires used to elicit the
drivers’ subjective reactions are presented.
The results of the field tests of 16 drivers drawn from the general public are presented. The
demographic characteristics of this gender- balanced sample of drivers are explained, followed by
the summaries of their subjective reactions and the objective measurements of how they used the
ACC and CACC systems. The subjective reactions of the drivers were generally very positive,
indicating a high likelihood of acceptance of the C/ ACC systems, but without any indication of
willingness to pay more for a vehicle equipped with one. The objective measurements showed
that drivers of the CACC system selected vehicle- following gaps that were approximately half
the length of the gaps they selected when driving the ACC system, and the latter gaps were
comparable to today’s vehicle- following gaps in congested highway driving. There was a
significant gender difference in car- following gap selection, with the male drivers consistently
choosing shorter gaps in both ACC and CACC ( and to a lesser extent in baseline manual driving
as well). The results indicate that drivers are likely to choose the shorter gaps enabled by CACC,
thereby contributing to highway lane capacity increases.
iii
Table of Contents
Abstract....................................................................................................................... ................... i Executive Summary ...................................................................................................................... ii Table of Contents ......................................................................................................................... iii List of Figures........................................................................................................................ ...... vi List of Tables ............................................................................................................................... ix 1 Introduction ............................................................................................................................. 1 2 Definitions of terms ................................................................................................................. 2 3 Cooperative Adaptive Cruise Control ( CACC) System ...................................................... 4 3.1 CACC concept ................................................................................................................... 4 3.2 System design..................................................................................................................... 4 3.2.1 Communication System .............................................................................................. 4 3.2.2 CACC control system ................................................................................................. 5 3.2.2.1 CACC control implementation ............................................................................ 5 3.2.2.2 CACC State Machine and CACC Vehicle Identification .................................... 6 3.2.2.3 CACC Controller Structures and Enhanced Speed Servo Loop .......................... 8 3.2.2.4 CACC Gap Closing Controller Design ................................................................ 9 3.2.2.5 CACC Gap Regulation Controller Design........................................................... 9 3.2.2.6 Proving ground test results................................................................................. 10 3.2.3 Driver Vehicle Interface............................................................................................ 19 3.2.3.1 ACC Driver- Vehicle Interface ........................................................................... 19 3.2.3.2 CACC Driver- Vehicle Interface ........................................................................ 21 4 Data Acquisition System ( DAS) ........................................................................................... 23 4.1 DAS Hardware................................................................................................................. 23 4.2 DAS Software .................................................................................................................. 26 5 Data Collection, Processing, and Reduction ....................................................................... 29 5.1 Engineering and Video Files Created by the DAS........................................................... 29 5.1.1 Engineering files ....................................................................................................... 29 5.1.2 Video Files ................................................................................................................ 32 5.1.3 DAS System Failures ................................................................................................ 34 5.2 Questionnaires................................................................................................................. 35 5.2.1 Drivers’ characteristics files...................................................................................... 35 5.2.2 ACC and CACC comfort assessment questionnaire................................................. 35 5.3 Data Analysis Plan ........................................................................................................... 35 5.4 Initial Data Processing ..................................................................................................... 37 5.4.1 Data Transfer Process ............................................................................................... 37 5.4.2 Data Repository Organization................................................................................... 38 5.4.3 Initial Data Processing .............................................................................................. 39 5.4.4 Manual Data Coding ................................................................................................. 42 5.5 Data Reduction................................................................................................................. 43 6 Experiment Protocol ............................................................................................................. 45 6.1 Overview .......................................................................................................................... 45 6.2 Participant Recruitment.................................................................................................... 46 6.3 Test Procedures ................................................................................................................ 46 6.3.1 Phase 1: Gaining Experience with ACC Systems..................................................... 46
iv
6.3.1.1 Step 1: Vehicle Delivery .................................................................................... 47 6.3.1.2 Step 2: One Baseline ( Non- ACC) Driving Day................................................. 47 6.3.1.3 Step 3: Six ACC Driving Days .......................................................................... 47 6.3.1.4 Step 4: Second Baseline ( Non- ACC) Driving Day............................................ 48 6.3.1.5 Step 5: Three More ACC Driving Days............................................................. 48 6.3.2 Phase 2: Using the CACC system............................................................................ 48 7 Overview of Participants and Trips .................................................................................... 50 7.1 Test Participants ............................................................................................................... 50 7.2 Data Set of Participant Trips ............................................................................................ 50 7.3 Participant Commute Characteristics............................................................................... 52 7.3.1 Overview ................................................................................................................... 52 7.3.2 Commute Length....................................................................................................... 53 7.3.3 Opportunity to Use the ACC- CACC Systems During Commutes............................ 55 7.4 Summary and Conclusions............................................................................................... 57 8 Baseline Vehicle- Following Behavior .................................................................................. 59 8.1 Definition of Baseline Vehicle- Following Events ........................................................... 59 8.2 Baseline Following- Event Analysis Results .................................................................... 60 8.2.1 Overview ................................................................................................................... 60 8.2.2 Following- Event Speeds ........................................................................................... 61 8.2.3 Following Time- Gaps Under Manual Driving.......................................................... 61 8.3 Summary and Conclusions............................................................................................... 65 9 ACC & CACC Driving Behavior......................................................................................... 67 9.1 ACC Usage....................................................................................................................... 67 9.1.1 Duration of ACC Usage ............................................................................................ 67 9.1.2 Conditions at ACC System Activation and Deactivation ......................................... 69 9.1.2.1 Speed Control..................................................................................................... 69 9.1.2.2 Time- Gap Setting Choices ................................................................................. 73 9.1.3 Description of Time- Gap Setting Usage During ACC System Activations ............. 78 9.2 CACC Usage.................................................................................................................... 81 9.2.1 Duration of CACC usage .......................................................................................... 81 9.2.2 Conditions at CACC System Activation and Deactivation....................................... 83 9.2.2.1 CACC Speed Control Choices ........................................................................... 83 9.2.2.2 CACC Time- Gap Setting Choices ..................................................................... 85 9.2.3 Description of Time- Gap Setting Usage During CACC System Activations........... 90 9.2.4 Analysis of Ride Quality Settings ............................................................................. 93 9.3 Comparison of ACC & CACC System Usage................................................................. 94 9.3.1 Statistical Model Design ........................................................................................... 94 9.3.2 ACC/ CACC System Usage....................................................................................... 95 9.3.3 Mean System Time- Gap Setting Preference ............................................................. 98 9.3.4 Mean System Time- Gap Setting Preference During Vehicle Following.................. 99 9.3.5 Preferred Gap Setting by Usage.............................................................................. 100 9.4 Questionnaire Results – Subjective Impressions ........................................................... 102 9.4.1 Comfort and Convenience....................................................................................... 103 9.4.2 Safety....................................................................................................................... 105 9.4.3 Driving with the system .......................................................................................... 107 9.4.4 Road and traffic conditions ..................................................................................... 108
v
9.5 Summary of Driver ACC and CACC Usage.................................................................. 109 References ............................................................................................................................... .. 111 Appendix A : DAS Software Architecture............................................................................. 112 Appendix B : Participant Consent Materials ........................................................................ 116 Appendix C : ACC & CACC Participant Questionnaires ................................................... 123 Appendix D : Answers to open questions in ACC and CACC questionnaires................... 142
vi
List of Figures
Figure 2.1: Vehicle naming convention for ACC system familiarization ( Phase 1 testing) _____ 2 Figure 2.2: Vehicle naming convention for CACC system testing ( Phase 2 testing) __________ 3 Figure 3.1: Configuration of Existing Nissan ACC Controller.___________________________ 5 Figure 3.2: Add- on System Design for PATH CACC__________________________________ 6 Figure 3.3: State Machine for PATH CACC Controller ________________________________ 7 Figure 3.4: Comparison of relative speed output between ACC sensor and DSRC ___________ 8 Figure 3.5: PATH CACC Gap Closing Controller ____________________________________ 8 Figure 3.6: PATH CACC Gap Regulation Controller __________________________________ 9 Figure 3.7: Trajectory Planning for CACC Gap Closing Controller _______________________ 9 Figure 3.8: Proving ground test: steady state speed performance________________________ 11 Figure 3.9: Proving Ground Test: steady state time gap performance_____________________ 11 Figure 3.10: Proving Ground Test: steady state acceleration performance _________________ 12 Figure 3.11: Speed response when leading car brakes while CACC car is approaching_______ 13 Figure 3.12: Time gap response when leading car brakes while CACC car is approaching ____ 13 Figure 3.13: Acceleration response when leading car brakes while CACC car is approaching _ 14 Figure 3.14: Brake pressure response when leading car brakes while CACC car is approaching 14 Figure 3.15: Speed profiles when leading car brakes and accelerates repeatedly ____________ 15 Figure 3.16: Time gap profiles when leading car brakes and accelerates repeatedly _________ 15 Figure 3.17: Acceleration profiles when leading car brakes and accelerates repeatedly_______ 16 Figure 3.18: Brake pressure profiles when leading car brakes and accelerates repeatedly _____ 16 Figure 3.19: Three car platoon test – speed profiles __________________________________ 17 Figure 3.20: Three car platoon test – time gaps ______________________________________ 18 Figure 3.21: Three car platoon test - accelerations ___________________________________ 18 Figure 3.22: Three car platoon test – brake pressure __________________________________ 19 Figure 3.23: ACC display and controls as illustrated in vehicle owner’s manual ____________ 20 Figure 3.24: ACC displays ( left) and controls ( right) _________________________________ 20 Figure 3.25: CACC display ( right of steering wheel) _________________________________ 21 Figure 3.26: CACC Driver Vehicle Interface _______________________________________ 22 Figure 4.1: C/ ACC DAS and Engineering Computer _________________________________ 24 Figure 4.2: Computer enclosure in luggage compartment behind rear seat of vehicle, with cover
closed.__________________________________________________________________ 24 Figure 4.3: DGPS Antenna ( left) and DSRC Communication Antenna ( right)______________ 25 Figure 4.4: Vehicle Interior, Showing Locations of Video Cameras______________________ 26 Figure 4.5: DAS Data Flow for Silver FX45 ( ACC or lead vehicle for CACC) _____________ 27 Figure 4.6: DAS Data flow for Copper ( CACC) Vehicle ______________________________ 28 Figure 5.1: Example of video file content ( left is front view, right is quad view)____________ 33 Figure 5.2: Sample screenshot of the CACC data import and validation tool_______________ 38 Figure 5.3: Plot of key vehicle and cruise control parameters for a trip ___________________ 40 Figure 5.4: Google Earth Plot of a trip taken by a participant ___________________________ 41 Figure 7.1: Bay Area Freeways Covered During the Study ____________________________ 52 Figure 7.2: Relationship Between Commute Length and Study Phase. ___________________ 53 Figure 7.3: Relationship Between Commute Length, Day of the Week, Time of Day. _______ 54 Figure 7.4: Relationship Between Commute Length, Day of the Week, Time of Day, Excluding
CACC Testing Days. ______________________________________________________ 55
vii
Figure 7.5: Opportunity for ACC/ CACC System Use by Study Phase. ___________________ 56 Figure 7.6: Gender by Time- of- Day by Cruise Control System Interaction. _______________ 56 Figure 7.7: The Relationship Between Time of Day, Day of the Week, and Opportunity for
System Use. _____________________________________________________________ 57 Figure 8.1: Cumulative Distribution of Baseline Following- Event Durations. ______________ 60 Figure 8.2: Cumulative Distribution of Baseline Driving Vehicle- Following Time- Gaps. ____ 61 Figure 8.3: Mean Vehicle- Following Time- Gap vs. Following- Event Duration. ____________ 62 Figure 8.4: Gender Differences in the Cumulative Distribution of Following Time- Gaps. ____ 63 Figure 8.5: Gender Differences in the Time Spent Manually Following at Different Time- Gaps.
_______________________________________________________________________ 64 Figure 9.1: Cumulative Distribution of the Duration of Individual ACC Usage Events.______ 67 Figure 9.2: Number of ACC Activations and Average Activation Duration per Participant. ___ 68 Figure 9.3: Extraction of Information About Beginning and End of System Activations. _____ 69 Figure 9.4: Extracting Patterns of ACC System Activation. ____________________________ 70 Figure 9.5: Actual Speed at ACC System Activation Onset vs Set Speed. _________________ 71 Figure 9.6: Actual Speed at ACC System Deactivation vs Set Speed. ____________________ 73 Figure 9.7: Number of Trips by the Number of Activations per Trip._____________________ 74 Figure 9.8: Distribution of Time- Gap Settings at Activation Onset by Activation Number per
Trip. ___________________________________________________________________ 75 Figure 9.9: Distribution of Actual Gap Size Relative to Gap Setting at ACC Activation. _____ 76 Figure 9.10: Distribution of Time- Gap Settings at Deactivation by Activation Number.______ 77 Figure 9.11: Distribution of Gap Size Relative to Gap Setting at ACC Deactivation. ________ 78 Figure 9.12: Distribution of ACC Time- Gap Setting Usage.____________________________ 79 Figure 9.13: ACC Usage as a Function of System Mode and Gender. ____________________ 79 Figure 9.14: ACC Time- Gap Setting Usage as a Function of Experience with the System.____ 80 Figure 9.15: Distribution of ACC Time- Gap Setting Usage by Driver. ___________________ 81 Figure 9.16: Cumulative Distribution of CACC Activation Event Durations. ______________ 82 Figure 9.17: Average Duration of CACC Use and Number of Activations per Participant.____ 83 Figure 9.18: Actual Speed at CACC System Activation Onset vs Set Speed._______________ 84 Figure 9.19: Actual Speed at CACC System Deactivation vs. Set Speed. _________________ 85 Figure 9.20: Number of Trips by Number of CACC Activations per Trip._________________ 86 Figure 9.21: Distribution of Time- Gap Settings at Activation Onset vs. Activation Sequence
within a Trip. ____________________________________________________________ 87 Figure 9.22: Distribution of Actual Gap Size Relative to Gap Setting at CACC Activation. ___ 88 Figure 9.23: Distribution of Time- Gap Settings at System Deactivation per Activation
Occurrence. _____________________________________________________________ 89 Figure 9.24: Distribution of Actual Gap Size Relative to Gap Setting at CACC Deactivation. _ 90 Figure 9.25: Distribution of CACC Time- Gap Setting Usage. __________________________ 91 Figure 9.26: CACC Usage as a Function of System Mode and Gender. ___________________ 92 Figure 9.27: CACC Time- Gap Setting Usage as a Function of Experience with the System. __ 92 Figure 9.28: Distribution of CACC Time- Gap Setting Usage by Driver. __________________ 93 Figure 9.29: Frequency Distribution of ACC/ CACC System Activation Events Per Trip. ____ 96 Figure 9.30: Frequency Distribution of ACC/ CACC Active Following Events Per Trip. _____ 97 Figure 9.31: Time Spent with the ACC/ CACC System Actively Following a Lead Vehicle. __ 97 Figure 9.32: Overall Mean Time- Gap Settings.______________________________________ 98 Figure 9.33: Mean Vehicle- Following Time- Gap Settings._____________________________ 99
viii
Figure 9.34: Mean Following Time- Gap Setting by Driver. ___________________________ 100 Figure 9.35: Time- Gap Setting Preferences by Usage. _______________________________ 101
ix
List of Tables
Table 5.1: Contents of the ' a' File ( CACC Data) _____________________________________ 30 Table 5.2: Contents of the ' c' File ( Communication Data)______________________________ 31 Table 5.3: Contents of the ' d' File ( Driver Behavior Data) _____________________________ 32 Table 5.4: Initial trip summary data set ____________________________________________ 41 Table 6.1: Summary of testing condition per day. ____________________________________ 45 Table 7.1: Test Participant Characteristics__________________________________________ 50 Table 7.2: Overview of Commuting Trips in the Data Set _____________________________ 51 Table 7.3: Summary of Trips in the Data Set by Participant ___________________________ 51 Table 9.1: Categorization of Actual Gaps Relative to ACC System Gap Settings.___________ 75 Table 9.2: Categorization of Actual Gaps Relative to CACC System Gap Settings. _________ 87 Table 9.3: Following Time- Gap Usage Preferences by Driver._________________________ 102 Table 9.4: Impressions About Comfort and Convenience. ____________________________ 103 Table 9.5: Impressions about safety. _____________________________________________ 106 Table 9.6: Impressions about driving style. ________________________________________ 107 Table 9.7: Impressions about the impact of road and traffic conditions on ACC and CACC use
______________________________________________________________________ 109
1
1 Introduction
This project is an element of PATH’s research on methods for mitigating congestion via the
application of Intelligent Transportation Systems. The first part of this research focused on the
evaluation of the impact of Adaptive Cruise Control ( ACC) and Cooperative Adaptive Cruise
Control ( CACC) vehicles on traffic patterns via computer simulations [ 1, 2]. ACC systems are
now commercially available on high- end vehicles. These systems enable the drivers to set a
desired cruising speed as well as a desired following gap with respect to a lead vehicle. If no
lead vehicle is present, then the system will regulate the vehicle speed, as any conventional
cruise control does, but once a lead vehicle is detected, the system will adjust the vehicle’s speed
to maintain the gap set by the driver, with no intervention needed from the driver. The ACC
functions with information it senses about the lead vehicle, and needs to sense a change in the
lead vehicle’s motion important enough to trigger a slowing down. Because of this delay in
sensing a change in the vehicle following situation, there is a threshold for the minimum gap
than can be technically achieved. On the other hand, a CACC benefits from the communication
of information regarding the speed and brake actuation of the lead vehicle, which allows it to
have faster responses, and therefore allows, from a technical point of view, a considerable
reduction in the size of the gap that can be safely controlled by the system.
One of the primary questions raised during the simulation research relates to the size of car
following gaps that drivers would be willing to use with comfort. This question led to the
current research initiative, which includes three main thrusts: i) development, implementation
and testing of the technical performance of a CACC; ii) data collection regarding its use by
naïve drivers and analysis of those data; and iii) integration of the knowledge gained about
driver use of the system into a traffic flow simulation. The CACC driver can choose a gap from
0.6 to 1.1 s, in contrast to the available ACC settings from 1.1 s to 2.2 s. The shorter CACC gaps
could lead to a significant highway capacity increase, while the longest CACC gap provides a
basis for direct comparison with the shortest available ACC gap.
This report describes the design and development of the Cooperative ACC system that was
implemented by modifying the factory- installed ACC system on the ( Nissan) Infiniti FX- 45
vehicles and the data acquisition system that was added to the vehicles. It also includes the
results of the testing of the technical performance of the system and the protocols for evaluation
testing by naïve drivers. The report concludes with the results of the human factors experiments
to learn about how drivers use the system and what they like or dislike about it.
2
2 Definitions of terms
Some of the important terms that will be used in the rest of this report include:
Adaptive cruise control ( ACC) – a system that automatically controls the gap between vehicles
driving at highway speeds ( by actuating engine and brake controls) based on measurements of
the distance to the preceding vehicle.
Cooperative adaptive cruise control ( CACC) – an enhancement to ACC that enables more
accurate gap control and operations at smaller gaps by adding communication of vehicle status
information ( primarily speed) from the preceding vehicle
DSRC – dedicated short- range communication, a wireless communication system that provides
very reliable and low- latency communication of data between vehicles and the roadside or
between vehicles and other vehicles ( as it is used here)
ECM – electronic control module
Lidar – laser radar, a sensor that uses an infrared laser to measure the distance to the back of a
preceding vehicle
Gap – the time between when the rear end of the lead vehicle and the front end of the following
( ACC) vehicle pass the same location along the roadway. This is measured in terms of seconds.
The distance corresponding to this gap is the clearance ( the product of the time gap and the
following vehicle speed).
This research focuses on the evaluation of drivers’ comfort when following a lead vehicle at a
short range controlled by an automation system. The vehicle that the observed drivers will be
using is called the Subject Vehicle, or SV. As the prototype that is tested involves the presence
of a specific vehicle as the predecessor of the SV, this vehicle is called the Lead Vehicle, or LV.
Because the data collection protocol involves two distinct phases, we will further distinguish the
names of the vehicles. In the first phase, the participant will be using a commercially available
ACC in the silver- colored Infiniti FX45, while in the second phase the driver will be using a
prototype CACC implemented in the copper- colored Infiniti FX45 ( following the silver Infiniti,
which will act as its lead vehicle, communicating data to it). The Principal Other Vehicle ( POV)
is the vehicle immediately ahead of the CACC lead vehicle during the CACC testing. The
naming convention is illustrated in the two figures below.
Figure 2.1: Vehicle naming convention for ACC system familiarization ( Phase 1 testing)
ACC SV ACC Lead
3
Figure 2.2: Vehicle naming convention for CACC system testing ( Phase 2 testing)
CACC Lead CACC POV
vehicle
CACC SV
4
3 Cooperative Adaptive Cruise Control ( CACC) System
The CACC prototype has been built on top of the commercially available ACC of the Infiniti
FX 45. Only the CACC characteristics are presented in this report, as the commercially
available ACC characteristics are the property of Nissan and were not developed under this
project.
3.1 CACC concept
All production- level ACC systems are autonomous, which means that they can only obtain
information about their distance and closing rate to the lead vehicle using their forward ranging
sensors ( typically radar or lidar). These sensors are subject to noise, interference and
inaccuracies, which require that their outputs be filtered heavily before being used for control.
That introduces response delays and limits the ability of the ACC to follow other vehicles
accurately and respond quickly to speed changes of the other vehicles, which in turn limits the
potential for ACC to contribute favorably to traffic flow capacity and stability. Augmenting the
forward ranging sensor data with additional information communicated over a wireless data link
from the preceding vehicle, ( e. g., speed, acceleration, braking capability) makes it possible to
overcome these limitations. Such a Cooperative ACC ( CACC) system can be designed to follow
the preceding vehicle with significantly higher accuracy and faster response to changes. This
would in turn enable the regulation of shorter gaps than current systems can provide. From this
perspective, CACC should be better able to dampen shock waves in the traffic stream.
However, the potential performance advantages cannot be realized in practice unless drivers are
interested in acquiring and using the system. This is why the experiments with the drivers are
important, to learn what they like and dislike about the cooperative ACC and which performance
settings they prefer. If drivers like the shorter gap settings, CACC could produce significant
improvements in lane capacity. However, if they do not find the shorter gaps acceptable these
improvements will not be achievable.
3.2 System design
The primary elements of the CACC system, in addition to the underlying ACC system on which
it is based, are the wireless system used for communication from the target vehicle to the subject
vehicle, the CACC control system, which decides how to modify the driving commands issued to
the vehicle’s engine, transmission and brakes, and the driver interface, which is an expanded
version of the ACC driver interface.
3.2.1 Communication System
Data are communicated from the CACC lead vehicle to the CACC subject vehicle using WAVE
Radio Modules ( WRMs) supplied by Denso ( WAVE stands for Wireless Access in the Vehicular
Environment). These use the IEEE 802.11p DSRC standard, but were developed and installed
prior to the completion of the IEEE 1609 standards and therefore do not rely on those standards.
The WRM radios are connected to antennas, which are temporarily mounted on the roofs of the
test vehicles for the CACC testing.
5
3.2.2 CACC control system
3.2.2.1 CACC control implementation
Figure 3.1 shows the configuration of the ACC controller. The ACC sensor is a fixed five- beam
LIDAR on the silver FX- 45 and a scanning LIDAR on the copper FX- 45, representing two
different generations of the Nissan ACC product. The sensor provides measurements relative to
the preceding vehicle such as distance and relative speed, which is sent to the ACC control unit
through the CAN bus. Limited brake actuation (< 0.3 g) is realized with a brake booster. A
brake pressure sensor is installed to provide brake pressure information for fine brake control.
The ACC control unit also sends CAN messages to actuate the engine through the engine ECM.
The ACC controller is housed in the ACC control unit with a two- layer architecture. At low
level, a speed servo controls the vehicle brake and engine so that vehicle speed will track the
speed command generated by the upper level quickly and accurately. At the upper level, the
ACC controller sends out appropriate speed commands based on the ACC sensor measurements
so that a desired time gap to the preceding vehicle is maintained.
Figure 3.1: Configuration of Existing Nissan ACC Controller.
To develop a CACC control system, it is necessary for the prototype controller to have the
capability to actuate the vehicle’s brake and engine one way or another. Based on the existing
ACC controller structure shown in Figure 3.1, this could potentially be accomplished in three
different ways:
1. The prototype CACC controller directly actuates vehicle engine and brake ( in this case,
the brake booster). In this way, the prototype controller would have the full control
authority for the vehicle longitudinal control purpose. However, actuating engine/ brake
directly would involve extensive modifications to the existing vehicle’s hardware and
software.
2. The prototype CACC controller sends out the same desired speed command as the higher
level ACC controller. Although this would reduce the flexibility of the prototype
controller design compared with the first option, the existing speed servo function could
be utilized for the CACC controller design. Since the desired speed command is inside
6
the ACC control unit, substantial hardware/ software modifications to the existing vehicle
would still be required.
3. As shown in Figure 3.2, the ACC sensor sends the relative distance and speed of the
preceding vehicle to the ACC control unit through the CAN bus. A simple way for
implementing the cooperative vehicle longitudinal control is that the prototype CACC
controller accepts the ACC sensor measurement information and sends out calculated
virtual relative distance and speed to the ACC control unit instead. Although this
includes the existing Nissan ACC controller in the loop and poses additional difficulties
for the CACC controller design, it only requires minimum modifications to the existing
Nissan software.
Figure 3.2: Add- on System Design for PATH CACC
Given the time frame of this project, the third option was chosen for the prototype CACC
controller implementation. The configuration of the add- on system design for the prototype
CACC is shown in Figure 3.2. With the CAN message definitions provided by Nissan, the
prototype CACC controller can access the ACC sensor measurement and vehicle information
such as wheel speed, gear position and engine RPM through the vehicle CAN bus. At the same
time, the prototype CACC controller can also receive information about the preceding vehicle
such as wheel speed, gear position, engine RPM, throttle pedal position and accelerator pedal
position via DSRC wireless communication. A CACC control algorithm, which will be detailed
in the following sections, calculates the virtual distance and relative speed command and sends it
to the ACC control unit through the CAN bus.
3.2.2.2 CACC State Machine and CACC Vehicle Identification
Figure 3.3 illustrates the state machine for the prototype CACC controller. The nominal mode of
CACC operation is gap regulation, but it is important to account for how this mode is initiated
and terminated. The transition from conventional ACC operation to CACC gap regulation is
accomplished through the target ID mode, which is needed to verify consistency between the
ACC sensor data and the DSRC communication data. If the gap is larger than a suitable
threshold for gap regulation, the gap closing mode is invoked.
Whenever there is a target change ( e. g., a vehicle cuts in between the CACC and its lead
vehicle), the prototype CACC controller retreats to the ACC mode by sending ACC sensor
measurements directly to the ACC control unit. The following step is to identify if the preceding
7
vehicle is the vehicle exchanging information through DSRC wireless communication. If the
preceding vehicle is identified as one of the CACC vehicles, the gap between these two vehicles
will be accessed. If the vehicle gap is too large, the PATH CACC controller will switch to gap
closing mode until the vehicle gap is shortened below a predetermined threshold. The function
of the gap regulation mode is to maintain the desired gap between the two vehicles.
Figure 3.3: State Machine for PATH CACC Controller
Before using the information from DSRC wireless communication for CACC control purpose,
we really need to identify if the ACC sensor target is the vehicle that is communicating through
the DSRC wireless communication. This is the primary function of the target ID mode. This
problem would be much more complicated if there were multiple vehicles with DSRC wireless
communication around, but that is not being addressed in these experiments, which are focused
on the human factors issues of driver use of the system. The complete target association problem
will have to be addressed in future research before the CACC system can be commercialized.
Since there will only be two DSRC equipped vehicles during our testing, a simple method is
adopted for the target ID purpose. Figure 3.4 shows the comparison of relative speed output
between the ACC sensor and DSRC when the ACC sensor target is the DSRC vehicle. The ACC
sensor output follows the DSRC output with about 0.5 sec time delay. This characteristic is used
to confirm the target ID.
8
Figure 3.4: Comparison of relative speed output between ACC sensor and DSRC
3.2.2.3 CACC Controller Structures and Enhanced Speed Servo Loop
Figure 3.5 and Figure 3.6 show the controller structures for the CACC gap closing controller and
CACC gap regulation controller. One of the important components of the prototype CACC
controller is the enhanced speed servo. As mentioned in the previous section, the actuation of
the existing engine/ brake is implemented by sending virtual relative distance/ speed commands to
the ACC control unit through the CAN bus. To fully utilize the existing ACC controller and
simplify CACC controller design, the enhanced speed servo is designed to maintain the vehicle
speed according to the desired speed command from the higher level controllers ( e. g., speed
trajectory planning for the prototype CACC gap closing controller). In the implementation, the
virtual relative distance command is always kept at the desired time gap and the virtual relative
speed command is used as the control input. After extensive frequency response testing, the
enhanced speed servo loop was designed using the loop shaping method. This controller
structure is very similar to the successful existing ACC controller.
Figure 3.5: PATH CACC Gap Closing Controller
9
Figure 3.6: PATH CACC Gap Regulation Controller
3.2.2.4 CACC Gap Closing Controller Design
When the relative distance between two vehicles is much larger than the desired time gap,
controller saturation will occur if the high- gain gap regulation controller is engaged immediately.
Such controller saturation will generate an oscillating response and make the driver
uncomfortable. One way to resolve this problem is to introduce controller switching. The
CACC gap closing controller will be engaged before the relative distance reaches a
predetermined threshold value. The CACC gap closing controller is a “ semi” open loop
controller. A trapezoidal relative speed trajectory is planned with respect to relative distance as
shown in Figure 3.7. All the parameters ( e. g. ) can be tuned to provide different driver
comfort levels.
Figure 3.7: Trajectory Planning for CACC Gap Closing Controller
3.2.2.5 CACC Gap Regulation Controller Design
When the distance between two vehicles is reduced below a certain threshold by the CACC gap
closing controller or when the distance between two vehicles is already below that threshold, the
CACC gap regulation controller is engaged to maintain a desired time gap between two vehicles.
As shown in Figure 3.6 the CACC gap regulation controller consists of preceding vehicle state
estimation, speed tracking and gap regulation.
Lead Vehicle State Estimation and Feedforward
One of the advantages of CACC is that lead vehicle information such as throttle pedal position,
brake pedal position, gear position and engine RPM can be transmitted to the following subject
10
vehicle through DSRC wireless communication. Such information is related to the specific
vehicle and cannot be used in the CACC controller design directly. The function of lead vehicle
state estimation is to assess the lead vehicle motion states. In the prototype CACC controller
design, lead vehicle acceleration is estimated and used in the feedforward control part.
Speed Tracking
The speed tracking module is designed to provide fast response to the speed changes of the lead
vehicle. In the CACC controller, a bandpass filter is used for speed tracking. It has low gain at
low frequency, high gain from 1 Hz to 5 Hz and 40 db roll- off above 5 Hz.
Gap Regulation
The gap regulation controller is a high gain linear controller designed with the loop shaping
method.
3.2.2.6 Proving ground test results
To fine tune the control design and controller parameters, two testing trips were made to the
Nissan Arizona vehicle proving ground. At the end of the second field trip, a series of scenarios
was performed to test the performance of the final controller under a range of representative
driving conditions:
- change of time gap setting while CACC car is approaching the leading car
- leading car brakes moderately while CACC car is approaching it and closing the gap
- leading car does repeated accelerate and decelerate maneuvers while CACC car follows it
- a manually- driven POV does repeated accelerate and decelerate maneuvers, followed by the
ACC car acting as the leading car for the CACC car, following in sequence.
Figure 3.8 – Figure 3.10 show performance in the scenario when the CACC car is approaching
the leading car, and the time gap setting is changed from 1.1 sec to 0.9 sec. Smooth action is
taken by the CACC car to approach the leading car and the time gap is then well regulated at 0.9
sec.
11
Figure 3.8: Proving ground test: steady state speed performance
Figure 3.9: Proving Ground Test: steady state time gap performance
12
Figure 3.10: Proving Ground Test: steady state acceleration performance
Figure 3.11 – Figure 3.14 show the scenario when the leading car brakes at about 0.16 g while
the CACC car approaches. With the feedforward information from the wireless communication,
the CACC controller reacts very quickly, as can be seen in both Figure 3.13 and Figure 3.14.
Therefore, the CACC car can always follow the speed of the leading car and regulate the time
gap at the desired time gap setting at the end.
13
Figure 3.11: Speed response when leading car brakes while CACC car is approaching
Figure 3.12: Time gap response when leading car brakes while CACC car is approaching
14
Figure 3.13: Acceleration response when leading car brakes while CACC car is approaching
Figure 3.14: Brake pressure response when leading car brakes while CACC car is approaching
To further illustrate the advantages of the feedforward information from wireless
communication, Figure 3.15 – Figure 3.18 show the scenario that the leading car makes repeated
braking and acceleration transients. The largest magnitude of braking is around 0.25 g, which is
close to the maximum capability of the brake actuator. As shown in Figure 3.15, the CACC car
15
is always able to track the leading car’s velocity, even with this aggressive braking. Figure 3.17
and Figure 3.18 also show that the CACC car brakes almost immediately following the lead car’s
braking.
Figure 3.15: Speed profiles when leading car brakes and accelerates repeatedly
Figure 3.16: Time gap profiles when leading car brakes and accelerates repeatedly
16
Figure 3.17: Acceleration profiles when leading car brakes and accelerates repeatedly
Figure 3.18: Brake pressure profiles when leading car brakes and accelerates repeatedly
At the end of the performance testing, a three car platoon scenario was conducted to test the
string stability effect and compare the performance between the conventional autonomous ACC
controller and the CACC controller. A manually driven Infiniti G35 led the platoon and the silver
Infiniti FX45 followed it with the factory ACC controller turned on. The copper Infiniti FX45
17
followed the silver one with the PATH CACC controller turned on. The G35 made repeated
aggressive braking and acceleration maneuvers. As shown in Figure 3.19, the autonomous ACC
equipped silver FX45 tracked the leading car’s speed with a much larger time lag compared with
the CACC equipped copper FX45’ s tracking of the silver FX45. Therefore, a large variation of
time gap regulation is shown in Figure 3.20 for the autonomous ACC equipped silver FX45.
More importantly, the amplification of the time gap variations for the autonomous ACC shows a
potential loss of string stability, which is compensated successfully by the cooperative ACC’s
enhanced vehicle following capability.
Figure 3.21 shows how the acceleration transients of the lead car are attenuated by the ACC car
following it, while the CACC car is able to keep the acceleration transients at a similarly
attenuated level, smoothing the ride for the vehicle occupants. Similarly, Figure 3.22 shows how
the brake pressure transient for the CACC car is attenuated from that for the preceding ACC car.
This attenuation is only possible because of the use of the vehicle- vehicle communication of the
CACC system; in its absence these transients would have been amplified.
Figure 3.19: Three car platoon test – speed profiles
18
Figure 3.20: Three car platoon test – time gaps
Figure 3.21: Three car platoon test - accelerations
19
Figure 3.22: Three car platoon test – brake pressure
3.2.3 Driver Vehicle Interface
The Driver- Vehicle Interface ( DVI) for the CACC was based on the original DVI for the Infiniti
ACC. Ideally, there should have been no change in the CACC DVI; however, the standard
dashboard display provided in the Infiniti vehicles could not be modified to support displaying
all of the gap settings that would be available during the CACC testing. This necessitated that an
additional LCD display be mounted in the CACC test vehicle to show the correct current gap
setting. Both the ACC and CACC DVIs are explained in the subsequent sections.
3.2.3.1 ACC Driver- Vehicle Interface
The ACC DVI consists of a set of 4 buttons located on the right side of the steering wheel and
two visual displays located on the dashboard. Figure 3.23 and Figure 3.24 depict the dashboard
displays and the steering wheel controls. The main ACC display is located at the bottom of the
tachometer dial on the instrument panel, adjacent to the transmission gear indicator, as shown in
Figure 3.24. This picture shows how the display looks when the ACC has first been activated,
but the set speed has not yet been selected. Additionally, the vehicle is not moving fast enough
for a lead vehicle to be detected and indicated.
20
Figure 3.23: ACC display and controls as illustrated in vehicle owner’s manual
Figure 3.24: ACC displays ( left) and controls ( right)
The first visual display is the “ CRUISE” indicator light, located along the left side of the
instrument cluster, which is activated with a green background when the on/ off switch is pushed
down. In case of system malfunction, this display background turns to orange. This light only
indicates that the cruise control system has been turned on, and not that it is currently active and
controlling the vehicle speed.
The second, and main, ACC display is located within the tachometer to the left of the current
gear indication (“ P” in Figure 3.24). This display shows the current ACC set speed ( for
example, 60 mph in Figure 3.23). The display also shows the current gap setting. Each square
between the vehicle and dot represents an increasing gap setting. If all squares are visible, the
longest gap has been selected. When the shortest gap has been selected, only the square closest
to the dot is present. Finally, this display indicates whether or not a lead vehicle has been
detected by the system. If no lead vehicle has been detected, there is no car icon to the left of the
current gap setting ( as shown in Figure 3.24). If a lead vehicle has been detected, there is a car
icon to the left of the current gap setting ( as shown in Figure 3.23).
The driver controls the ACC with four buttons. The ACC is activated by the driver pushing the
“ on/ off” button ( the left side of the middle button on the steering wheel), as shown in Figure 3.23
and Figure 3.24. The set speed is selected by toggling the top button down, and then toggling it
up or down to increase or decrease the set speed. Short toggles produce changes of 1 mph in set
21
speed, while holding the button in the up or down position for about one second produces a
change of 5 mph in the corresponding direction. The bottom button (“ Cancel”) is used to
interrupt the ACC action at any time the user chooses, analogous to hitting the brake pedal, but
retaining the set speed value for the next time the system action is resumed by toggling the top
button up.
3.2.3.2 CACC Driver- Vehicle Interface
From a driver’s perspective, the CACC operation is identical to that of the original factory-installed
ACC. Therefore, the existing ACC driver interface ( described above) has been adapted
for the CACC with minor changes on the display. The primary differences between the two
systems lie in the number of available gap settings and the location of the display. On the
copper- colored FX- 45, which is used for the CACC driving experiments, this display is located
on an additional larger LCD screen, mounted to the right of the steering wheel as shown in
Figure 3.25. This display was provided for experimental convenience and will not be a topic for
evaluation in the experiments.
This display allows both the driver and the experimenter to see the CACC system status and
current gap settings during the experiment. One additional icon was added to the CACC display,
resembling a radio transmitter icon. The presence or absence of this icon indicates whether or
not the vehicle- vehicle communication is operational.
Figure 3.25: CACC display ( right of steering wheel)
Note that in Figure 3.25 there is also a small video camera mounted by this display, pointed at
the driver’s face. This camera is used to verify that the correct person is driving the vehicle, and
22
that it has not been driven by an unauthorized driver who is not part of the experiment. ( See the
DAS section of this report for more details on data collection setup.)
Figure 3.26: CACC Driver Vehicle Interface
Figure 3.26 shows a close- up of the CACC display with the set speed indication and lead vehicle
icon ( indicating that the system has identified the lead vehicle for possible following). The four
bars behind the lead vehicle icon indicate that the driver has selected the largest following gap
setting. As the driver toggles the gap setting switch ( the right side of the middle button shown in
Figure 3.24), this cycles through the three shorter gap settings in sequence, until only one bar
remains. If the driver toggles it again, the system switches back to the longest gap setting. The
CACC time gap settings are 1.1, 0.9, 0.7 and 0.6 seconds ( compared to 2.2, 1.6 and 1.1 seconds
for the ACC on these vehicles).
23
4 Data Acquisition System ( DAS)
An identical data acquisition system is installed on both vehicles. The silver ACC vehicle will
be used for establishing a baseline; i. e., observing the driver’s following behavior without the use
of any system, and also to collect data during the ACC familiarization. The test of CACC
driving will be conducted with the participant driving the copper vehicle. The data collected on
each vehicle will provide the opportunity to compute the parameters classically used for
describing driver behavior, such as time gap or time to collision, describe the participant’s
control of the vehicle with either system, and characterize some of the driving environment
conditions, making it possible to compare the driver behavior with the systems and the use of
each system.
The data acquisition system records a variety of engineering variables to characterize the
motions of the vehicles, the driver actions, and the functioning of the ACC and CACC systems.
In addition, it records two channels of video data to provide additional information about the
driving environment ( forward and rear driving scenes, especially for cut- in and cut- out
maneuvers that may be difficult to interpret from the lidar data) and three to record the driver’s
actions ( four views are grouped on a four to one video splitter: use of pedals, hand motions for
adjustment of speed and gap settings, driver’s face for ensuring that the driver is indeed the
experiment participant, and rear view of the traffic).
4.1 DAS Hardware
For each of the vehicles, the DAS package contains the following equipment:
• Video computer ( PC 104 – Linux)
o 5 video cameras
o One “ four- to- one” video splitter
o 2 titlers ( Horita)
• Engineering data computer ( PC 104), connected to the C/ ACC system computers to
provide data about the vehicle controls use ( e. g. steering wheel, pedals), system uses
( C/ ACC on/ off, gap selected) and dynamics ( speed, yaw rate)
• Accelerometer: longitudinal and lateral acceleration
• DGPS: latitude, longitude and UTC
The DAS is shown in Figure 4.1, which illustrates the connection between the ACC and CACC
computers with the engineering computer already interfaced with the CAN bus. ( See Figure
3.2.)
24
Figure 4.1: C/ ACC DAS and Engineering Computer
Figure 4.2 shows the computer installation with the cover closed, as it will be seen by the test
participants. The closed cover protects the equipment and leaves the participants with trunk
space behind it for storing goods that they need to transport.
Figure 4.2: Computer enclosure in luggage compartment behind rear seat of vehicle, with cover
closed.
25
The DGPS system is used to provide continuous information about the location of the vehicle
and the accurate time reference. It receives satellite signals from an antenna mounted on the roof
of the vehicle, adjacent to the additional antenna used to receive the vehicle- vehicle DSRC
communications, as shown in Figure 4.3.
Figure 4.3: DGPS Antenna ( left) and DSRC Communication Antenna ( right)
The locations of the video cameras in the front portion of the vehicle interior are shown in Figure
4.4. An additional video camera is mounted in the rear window of the vehicle, facing back, to
capture images of the traffic scene behind the vehicle.
26
Figure 4.4: Vehicle Interior, Showing Locations of Video Cameras
4.2 DAS Software
The software architecture on the vehicles consists of a set of processes running on PC- 104
computers and communicating through the Publish/ Subscribe database. The software is written
in C or C++ and runs either on the QNX 6.2 ( engineering computer) or 6.3 ( Communication and
control computer) real- time operating system and Linux ( video computer). Specific details of
the software architecture, such a listing of processes and diagrams of how they interact, can be
found in Appendix A, while a higher level description of the data flows can be found in Figure
4.5 and Figure 4.6. Figure 4.5 describes the data flow in the Silver Infiniti FX45 which only has
the factory ACC enabled for vehicle control, but also serves as the lead vehicle for CACC
testing. Figure 4.6 describes the data flow in the Copper Infiniti FX45 which has the CACC
system enabled.
27
Figure 4.5: DAS Data Flow for Silver FX45 ( ACC or lead vehicle for CACC)
The yellow boxes in Figure 4.5 and Figure 4.6 contain the information that is sent from the silver
ACC vehicle to the copper CACC vehicle from the Communication Computers. The silver lead
vehicle logs the information that it sends to the copper CACC equipped vehicle while the copper
CACC vehicle logs the information that it receives from the silver lead vehicle.
Communication
computer
( QNX 6.3)
Engineering
computer
( QNX 6.2)
Video
computer
( Linux)
CAN bus
Set gap
Set speed
On/ off
Cancel
Lidar
Range,
Range Rate,
yaw rate
ECU/ VBS
speed,
acceleration,
brake
Switches
Range,
Range Rate,
Yaw rate
Speed,
Acceleration,
Brake
Set gap
Set speed
Time
Range,
Range
Rate,
yaw rate
speed,
acceleration
brake
Time
Time
Stamper
Time
Time
DGPS
( WAS)
UTC
Lat
Long
UTC
Lat
Long
Accelerometer
Lateral acceleration
Longitudinal acceleration
Video
splitter
Time
Stamper
Time
camera
28
Figure 4.6: DAS Data flow for Copper ( CACC) Vehicle
CACC control computer
Copper QNX 6.3
Engineering
computer –
Bronze QNX 6.2
Video computer
Brass
CAN bus
On/ off
Set gap
Set speed
Cancel
Lidar
Range,
Range Rate,
yaw rate
ECU/ VBS
speed,
acceleration,
brake
Switches
Range,
Range Rate,
yaw rate
speed,
acceleration,
brake
On/ off
Cancel
Set gap
Set speed
Time
Range,
Range Rate,
yaw rate
speed,
acceleration,
brake
Time
Time
Stamper
Time
Time
DGPS
( WAS)
UTC
Lat
Long
UTC
Lat
Long
Accelerometer
Lateral acceleration
Longitudinal acceleration
Video
splitter
Time
Stamper
Time
camera
DVI
Set gap
Set speed
29
5 Data Collection, Processing, and Reduction
Two types of data files were generated by the ACC and CACC vehicle Data Acquisition Systems
( DAS). First, the vehicles generated engineering files, collected and stored on the engineering
computer installed each vehicle. Second, the vehicles generated two digital video files from the
five onboard cameras, which were stored on a separate video collection computer. Additionally,
two paper questionnaires were also administered during the experiment regarding driving
practice and ACC/ CACC usage.
5.1 Engineering and Video Files Created by the DAS
5.1.1 Engineering files
The engineering files are essentially text files containing rows and columns of numeric vehicle
data such as speed, distance, latitude, longitude, etc. Data were recorded every 50 ms ( 20 Hz
sampling rate) and the files were saved every two minutes. Three types of engineering files were
recorded by the DAS and their contents are described in Table 5.1 to Table 5.3. Although it may
seem trivial, much effort was put into creating a file naming method that would insure that each
file contained a unique name, thus avoiding any potential to accidentally overwrite data when
they are copied or moved. The engineering filenames were constructed using the following
convention:
[ V][ F][ MMDD][ TTTT][ SSS]. dat
Where:
- [ V] is a single character representing the vehicle on which the data are collected:
' c' is used for data from the copper car, equipped with the CACC prototype
' s' is used for data from the silver car, with the commercial ACC
- [ F] is a single character representing the type of data that will be contained within the file:
' a' is used for C/ ACC data
' c' is used for communication from the lead vehicle data
' d' is used for driver behavior and target data
- [ MMDD] is the date with 2 characters for month and 2 characters for the day of the month
- [ TTTT] is a 4- digit Trip ID number which is incremented each time the vehicle is started
- [ SSS] is a 3- digit sequence number which starts at 000 and increments every 2 minutes
When the engineering files are downloaded from the vehicle, they are grouped into the concept
of a trip, where a trip corresponds to each time the vehicle ignition was switched on. The files
are copied into a single trip directory which is named using the following convention:
e[ YYMMDD][ TTTT]
where:
- ' e' is the indication that the directory contains engineering ( instead of video) data
- [ YYMMDD] is the trip date with 2 digits representing year, month, and day
- [ TTTT] is a 4- digit Trip ID which matches the trip ID number of the enclosed files
30
Table 5.1: Contents of the ' a' File ( CACC Data)
Column Description Unit/ Range
1 A Time of day this entry was recorded hh: mm: ss. sss
2 B Number of seconds since start of process sec
3 C Virtual pedal position ( from driver, ACC or CACC) percent
4 D Engine RPM rpm
5 E Mean effective torque Nm
6 F During shift ( no/ yes) 0/ 1
7 G Current gear 0- 7
8 H Front right wheel speed rpm
9 I Brake pressure bar
10 J Change counter 0- 7
11 K Output Shaft revolution rate rpm
12 L Turbine revolution rate rpm
13 M Target engine torque Nm
14 N Target lock 0/ 1
15 O Virtual distance ( CACC output command) m
16 P Virtual speed ( CACC output command) m/ s
31
Table 5.2: Contents of the ' c' File ( Communication Data)
Column Parameter Units
1 A Time of day this entry was recorded hh: mm: ss. sss
2 B Number of seconds since start of process sec
3 C Time wireless comm message sent sec
4 D Time wireless comm message received sec
5 E Time engineering message sent sec
6 F Time engineering message received sec
7 G Message count 0- 255
8 H My time msec
9 I Accelerator pedal position ( from driver) percent
10 J Virtual pedal position ( from driver, ACC or CACC) percent
11 K Engine RPM rpm
12 L Mean effective torque Nm
13 M During shift ( no/ yes) 0/ 1
14 N Current gear 0- 7
15 O Front right wheel speed rpm
16 P Driver braking ( no/ yes) 1/ 0
17 Q Target lock 0/ 1
18 R Car space ( ACC gap selection) 1- 3
19 S Set speed km/ h
20 T Brake pressure bar
21 U Distance from silver Nissan to target vehicle m
22 V Relative speed ( between silver Nissan and its ACC
target vehicle)
m/ s
23 W Yaw rate deg/ s
24 X Vehicle Speed km/ h
32
Table 5.3: Contents of the ' d' File ( Driver Behavior Data)
Column Parameter Units
1 A Timestamp of file write hh: mm: ss. sss
2 B Number of seconds since start of process sec
3 C Time wireless comm message was sent sec
4 D Time wireless comm message was received sec
5 E Time engineering message was sent sec
6 F Time engineering message was received sec
7 G Yaw rate deg/ s
8 H X- Acceleration g
9 I Y - Acceleration g
10 J ACC Active ( off/ on) 0/ 1
11 K Car Space ( ACC or CACC Gap Setting) 2- 3- 4- 5 for copper
1- 2- 3 for silver
12 L Target Approach Warning ( false/ true) 0/ 1
13 M MainSW – ACC powered on ( off/ on) 0/ 1
14 N ACC Buzzer - Master Alarm ( off/ on) 0/ 127
15 O ACCBuzzer2nd - Target Approach Warning ( off/ on) 0/ 1
16 P ACCBuzzer3rd 0/ 1
17 Q ACC/ CACC Set speed km/ h
18 R Accel. PedalPosition ( from driver) percent
19 S VirtualPedalPosition ( from driver, ACC or CACC) percent
20 T Driver Braking ( off/ on) 1/ 0
21 U ACCMainSW – ACC powered on ( off/ on) 0/ 1
22 V Brake pressure bar
23 W Vehicle Speed km/ h
24 X UTC Time HHMMSS: ss
25 Y Longitude degrees & minutes
26 Z Latitude degrees & minutes
27 AA Altitude m
28 AB GPS Speed Over Ground km/ h
29 AC Numsats ( number of GPS satellites available) -
30 AD Date ddmmyy
31 AE Change Counter -
32 AF Distance to Lead Vehicle m
33 AG Relative Speed Compared to Lead Vehicle
(+ if closing gap / - if opening gap)
m/ s
5.1.2 Video Files
Video data were recorded continuously from five cameras into two divx digital video files at a
rate of 500 kbps. The files were roughly two minutes long such that the ends of the video files
were synchronized with the ends of the corresponding engineering files. Unfortunately, due to
technical constraints and some level of randomness with the time it takes to open a new video
33
file in real time, the beginnings of the video files are not necessarily synchronized with the
beginnings of the engineering files. The video files typically contain an additional 1 to 2 seconds
of video at the beginning to avoid the possibility of a loss of video.
Figure 5.1 illustrates the views provided by each of the two video file types. The image on the
left is the front scene from a single forward looking camera. At the bottom of the image is the
time, in hours, minutes, seconds and milliseconds and the date. The image on the right is a
composite of 4 cameras using a video quad splitter. In the top left corner is the rear view. In the
top right corner is a view of the steering wheel. In the bottom left corner is a view of the driver’s
right foot above the accelerator and brake pedals, and finally, in the bottom right corner is a view
of the driver’s face.
Figure 5.1: Example of video file content ( left is front view, right is quad view)
As with the engineering filenames, care was taken to ensure unique video filenames which
followed the following naming convention:
[ V][ F][ MMDD][ TTTT][ SSS]. avi
where:
- [ V] is a single character representing the vehicle on which the data are collected.
' s' is used for the silver car.
' c' is used for the copper car.
- [ F] is a single character representing the video file type or channel
' f' represents the file containing the single video looking out of the front window
' q' represents the file containing the four ( quad) video images
- [ TTTT] is a 4- digit Trip ID number which is incremented each time the vehicle is started
- [ SSS] is a 3- digit sequence number which starts at 000 and increments every 2 minutes
Similar to the engineering files, the video data files were organized and copied into video trip
directories. The video trip directories were named using the following convention:
34
v[ YYMMDD][ TTTT]
where:
- ' v' is the indication that the directory contains video data.
- [ YYMMDD] is the trip date with 2 digits representing year, month, and day
- [ TTTT] is a 4- digit Trip ID which matches the trip ID number of the enclosed files
5.1.3 DAS System Failures
There were typically between one to three DAS system failures per participant, which resulted in
the loss of all or partial data for an individual trip. Three modes of failure were common during
the experiment. The first mode of failure happened only during the first six participants, after
which the problem was identified and repaired. For the first six participants, there were a
number of trips of both the copper and silver vehicles that were simply not recorded. This mode
of failure was eventually traced to a routine in the DAS startup that was relying on updates from
the GPS receiver before starting to record data. If the GPS did not start receiving current
information shortly after the DAS was started ( often due to clear sky issues, such as the vehicle
being parked in an underground garage), then there was the potential for the DAS to become
hung and to not record the subsequent trip. Failures of this type were discovered during the data
download and validation stage by comparing the list of trips imported from the DAS to the hand-written
driver log sheets.
A second mode of failure involved a communication failure between two of the DAS system
computers. In this mode of failure, the serial communication connection failed between the data
recording computer and the computer that interfaces with both the vehicle’s CAN data and the
DSRC antenna. Although the DAS system still recorded some parameters for the entire trip,
such as GPS and accelerometer, most vehicle data parameters, such as vehicle speed and cruise
control settings, became frozen at the last value received just prior to the communication failure.
This mode of failure generally occurred fairly early in the trip, so these trips were not included in
subsequent analyses. Failures of this type were discovered by manually reviewing graphs of the
data parameters during the initial data processing step, the manual coding step, or even
sometimes upon the examination of outliers in a particular analysis.
A third common mode of failure was characterized as a result of a DAS system reboot occurring
during the middle of a trip. While the cause of the DAS system reboots is unknown, this mode
of failure did not result in a total loss of trip data. This mode of failure typically resulted in the
loss of 2 to 3 minutes of data while the DAS rebooted, but once the system finished rebooting,
the recording of the data (. dat) files resumed. Unfortunately, after the reboot, the DAS system
generally did not record video files. Failures of this type were generally discovered by manually
reviewing the graphs of the data parameters during the initial data processing and coding step.
Trips with system reboots were generally included in data analyses.
Other DAS failures occurred less frequently and were usually the result of isolated incidents in
which data or video files for a particular trip were either missing or corrupted. As an example,
video file corruption occurred on several trips taken by participant 10 which were later diagnosed
as having occurred as a result of running low on disk drive space. Overall, the number of
35
missing commute trips per driver was generally no more than one or two, and the impact of the
data collection failures on the subsequent analyses should be minimal. All drivers had at least 10
ACC and 3 CACC commute trips that could be analyzed.
5.2 Questionnaires
5.2.1 Drivers’ characteristics files
Information that might allow a subject to be identified is always kept confidential; however,
there are some attributes that get coded for each participant. This information is entered
manually by an experimenter in either Excel or SPSS, and then coded to a random participant
number assigned to each participant.
The driver characteristics that are typically coded for each participant include the following:
• Age
• Gender
• Typical Annual Mileage Driven
• Daily Commute Miles Driven One Way & Round Trip
5.2.2 ACC and CACC comfort assessment questionnaire
Two questionnaires were administered during this experiment, and copies of them can be found
in Appendix C. The first questionnaire was administered after the participant had about a week’s
worth of experience with the ACC system, but before the participant had a chance to experience
the CACC system. Thus, the first questionnaire focused on comparing the ACC system to both
conventional cruise control and manual driving. The second questionnaire was administered at
the end of the study, after the participant had experienced both the ACC and CACC systems, and
more or less repeated many of the questions found on the first questionnaire. This allowed for a
more direct comparison of the ACC and CACC systems. The questionnaires were administered
on paper, and later, they were manually transcribed to electronic data files.
The questionnaires covered four basic topics:
1. Comfort and Convenience
2. Safety
3. Driving with the System
4. Road and Traffic Conditions
5.3 Data Analysis Plan
The main question posed by this study is whether or not drivers will be comfortable with the
shorter gaps provided by the CACC system. In order to do so, both opinions and more
“ objective” data were gathered to observe:
• Their use of the systems
• The influence of the system on their driving
36
The part of their driving of primary interest is:
• Gap regulation with a lead vehicle
• Lane changes, in terms of number and location, along the commute trip.
The data analysis activities proceeded in roughly six steps or phases:
1. Each section of each trip is described in terms of the time when the driver is following a
vehicle versus the times when the driver is driving “ alone”, i. e. no targets are sensed. Each
trip may have a number of vehicle following episodes or epochs of varying duration.
Furthermore, this description is examined from two perspectives:
• First, from the chronological time perspective,
• Second, from the location or distance perspective as there may be certain locations where
the ACC/ CACC is systematically used/ not used
2. Each following epoch is then characterized along the following dimensions:
• Duration
• Initiation condition ( e. g. SV catches up with slower POV, SV changes lane, POV
changes lane)
• Time gap at ACC initiation
• Average time gap
• Number of braking events
• Max braking level
• SV speed
• End condition ( SV changes lane, POV changes lane, POV distances SV)
3. For each following epoch, a number of graphs and metrics are examined including, but not
limited to, the following:
• Lead vehicle speed and speed variability over the duration of the epoch
• ACC vehicle speed and speed variability
• Time gap to lead vehicle
• Time To Collision ( TTC)
4. Lane changes are identified, and the causes for each lane change are identified and
categorized as best as possible. This must be done to distinguish between lane changes for
overtaking and lane change for following a route.
5. ACC/ CACC system use is characterized along the following dimensions:
• For each trip using one of the ACC/ CACC systems
o Number of episodes when the system is used
o Length of each of these episodes
o Sections when the system is engaged/ disengaged.
• For each system use episode within a trip
o Initial set speed
37
o Conditions of disengagement of the system ( brake pedal vs. button on steering wheel)
o Elapsed time between disengagement and next engagement
o Setting used, for speed and gap, and conditions for changes
6. ACC/ CACC comparison
• Comparison of system engagement and use, e. g., is the ACC or CACC typically
disabled by the driver under conditions when the other variant would normally be
used?
• How and when is each of the systems disengaged by the driver and is there a
difference for these disengagements for which the system type might account, e. g.,
does the closer gap maintained by the CACC system cause the driver to brake
( thereby disengaging the system) more often?
• Comparison of typical system gap settings used.
5.4 Initial Data Processing
5.4.1 Data Transfer Process
For each test participant, somewhere between 8 and 11 GB worth of data were collected across
the two, in- vehicle, DAS computers. A number of automatic and manual steps or procedures are
required to retrieve the data, verify its integrity, and move it to a server where it could be
archived and analyzed. On the vehicle DAS computers themselves, when a new trip is generated
( each time the vehicle is started), the files for the last completed trip are automatically copied to
a directory on the DAS video computer and put into a queue to be downloaded. The data
remained stored on the vehicles until the vehicles were brought back to California PATH to be
readied for another participant. The transfer of data from the vehicles to the storage server was
done manually using external disk drives. When an external drive is attached to the video DAS
computer via USB, a script could be activated that would copy all of the data in the download
queue to the external drive. After the download, a copy of the data remained on the vehicle until
it was manually deleted, a process that was done after every few participants.
The data were transferred from the vehicles to a data repository server for storage and analysis.
The data repository server was attached to a secured computer in a secured room at California
PATH. To assist in uploading the vehicle data from the USB drive to the repository, a data
importing tool was written in the RealBasic programming language. The data import tool served
six functions ( listed below) and a screenshot is provided in Figure 5.2:
1. The tool displays the list of trips recorded by the DAS in a table that can be easily read by an
analyst. The analyst can then cross- reference the trips that were downloaded from the
vehicles with the paper trip logs kept by the test participants to determine whether or not data
for any of the trips made by the participant were missing.
2. The tool allows the analyst to filter out or skip the importing of inconsequential trips, such as
short trips when the vehicle is simply moved, or trips when there was no opportunity for
freeway travel and ACC use.
3. The tool allows the analyst to assign a Driver ID number to the trips.
38
4. The tool imports ( copies) the files from the USB drive to the storage server, while both
restructuring and renaming the files to make subsequent data processing easier.
5. The tool provided the first step in the verification of the integrity of the data being copied by
reporting any expected, but missing files, and by checking for potential sensor failures on the
vehicles.
6. The tool created an import log file of all operations performed and errors encountered.
After the data were imported to the repository, several backups were made of the data after
various steps in the subsequent data processing. First, the data repository storage server used
Raid5 technology for fault tolerance against any one disk drive failing. Second, periodic
backups were made of all of the project data on the storage server to an external hard disk to
guard against more catastrophic failures. The backups contained on the external hard disk were
kept in a locked file cabinet with the subject paper records in order to limit access and protect the
confidentiality of the records. Third and finally, the original data for each subject were backed
up to a series of DVDs, stored in a locked media vault off- site.
Figure 5.2: Sample screenshot of the CACC data import and validation tool
5.4.2 Data Repository Organization
While the file naming conventions used on the vehicles were optimized to prevent the possibility
of overwriting files due to duplicate file names, the resulting file- naming structure was a bit
unwieldy for a person or analyst to visually parse and comprehend. As the files were imported to
the data repository, the directory structure and files names were changed to match the following
conventions:
39
▼  Driver[ XX]
▼  [ Vehicle]
▼  Date[ YYMMDD]
▼  Trip[ TTTT]
▼  [ SSS]
 [ V][ F][ TTTT][ SSS].[ EXT]
Where:
- [ XX] is a two- digit test participant ID number
- [ Vehicle] is the name of the vehicle from which the data were collected
' Silver’ is used for the silver ACC- enabled car
' Copper’ is used for the copper CACC- enabled car
- [ YYMMDD] is the trip date with 2 digits representing year, month, and day
- [ TTTT] is a 4- digit Trip ID number which incremented each time the vehicle was started
- [ SSS] is a 3- digit sequence number which started at 000 and incremented every 2 minutes
- [ V] is a single character representing the vehicle on which the data is collected.
' s' is used for the silver car.
' c' is used for the copper car.
- [ F] is a single character representing the data file type
' a' is used for C/ ACC data
' c' is used for communication from the lead vehicle data
' d' is used for driver behavior and target data
' f' represents the file containing the single video looking out of the front window
' q' represents the file containing the four ( quad) video images
- [ EXT] is a 3- letter file extension, either . dat or . avi for data or video files, respectively.
The resulting file and directory naming conventions allowed analysts to more easily navigate the
data and find a particular driver, trip, or video segment. The resulting directory structure also
aided in keeping any additional data, generated during post- processing, organized. As examples,
a summary file generated to detail each trip taken by a particular driver would be stored in the
driver directory; whereas graphs that were generated to summarize a particular trip were stored
in each trip directory.
5.4.3 Initial Data Processing
After a participant’s data were downloaded from the vehicle, validated, and uploaded to a data
repository, a number of initial data processing steps needed to be performed. The initial data
processing was done using a script written for MatLab. This script basically ran through the data
for each trip in order to summarize key parameters on both a trip- by- trip basis and on a
participant- by- participant basis. On a trip- by- trip basis, the initial data processing script
generated the following:
1. a best estimate synchronization between the DAS system clock and time as obtained by the
GPS receiver on the vehicle. This synchronization was required in order to compare events
that occurred in the lead vehicle with events that occurred in the following vehicle.
2. a number of indices, tables, and sensor calibration files which could be used in later
processing steps.
40
3. graphs of key system and vehicle parameters versus time ( shown in UTC time corrected for
the US Pacific Time Zone), as shown in Figure 5.3.
4. a KML file from the GPS points collected by the vehicle, which could be loaded into Google
Earth allowing an analyst to visualize the trip’s starting and ending points along with the
route taken by the vehicle during the trip. ( See Figure 5.4.)
Figure 5.3: Plot of key vehicle and cruise control parameters for a trip
On a participant- by- participant basis, the initial data processing script generated a trip summary
dataset which listed all of the trips taken by a driver during the experiment. See Table 5.4 for a
description of the metrics that were generated for the initial trip summary data set. Although this
data set was used to perform subsequent analyses, its immediate use was as a tool to help an
analyst perform the manual trip coding task.
41
Figure 5.4: Google Earth Plot of a trip taken by a participant
Table 5.4: Initial trip summary data set
Parameter Description
Driver ID Number A random ID number assigned to each test participant
Vehicle Description Silver ( ACC Vehicle) or Copper ( CACC Vehicle)
Trip ID Number A vehicle- specific sequential trip number
Day/ Month/ Year Trip Date
Clock Start/ End Original System Clock Times
UTC- P Start/ End Clock synchronized to UTC Pacific Time
Trip Length Duration of Trip
ACC On Events Number of times the ACC/ CACC system was turned on
ACC On Time Total length of time that the ACC/ CACC system was on
ACC On Set Speed Mean set speed when ACC system was on
ACC On Mean Speed Mean vehicle speed when ACC system was on
ACC Active Events Number of times that the ACC/ CACC system was activated
ACC Active Time Total length of time that the ACC/ CACC system was active
ACC Active Set Speed Mean ACC/ CACC set speed when the system was active
ACC Active Mean Speed Mean vehicle speed when the ACC/ CACC system was active
Gap Setting Events For each available gap setting, the number of times that the driver
selected that gap setting
Gap Setting Times For each available gap setting, the amount of time that the driver
spent using that gap setting
Gap Setting Set Speeds For each available gap setting, the mean set speed that the driver
had set while using that gap setting
Gap Setting Mean Speeds For each available gap setting, the mean vehicle speed that the
driver was travelling while using that gap setting
42
5.4.4 Manual Data Coding
Once the initial automated data processing step was completed, an analyst was required to
manually sort through each trip. The analyst was first looking for common DAS system failures,
and second, coding trip characteristics. The end result of the manual coding step was to create a
list of trips and their characteristics which could then be used during the data reduction step as
means to filter certain types of trips to be included or excluded from the subsequent analyses.
Trips were coded along five dimensions:
1. Day of Week ( e. g., Monday, Tuesday, etc.)
2. Day of Study ( i. e., number of days since receiving the ACC vehicle)
3. Trip Purpose ( Morning Commute, Evening Commute, or Other)
4. Trip Mode ( Baseline, ACC, CACC, or Urban Driving)
5. Full or Partial Trip
The coding for the trip purpose separated out morning and evening commutes from other casual
trips. This coding was done using both the time of the trip and the GPS traces recorded during
the trip. Morning commute designated a trip from home to work, and evening commute
designated a return trip from work to home. Since participants did not always go directly
between home and work, there was some subjectivity regarding the coding of which trips were
actually commutes, and occasionally, a commute may span multiple trips. However, the guiding
principle for calling a trip a commute was whether or not the trip was made on roads that the
participant frequently travelled between their home and their work. Thus, for all trips that were
labeled as commutes, it can be assumed that the participant was highly familiar with the route.
Most of the analyses performed for this report focused only on commuting trips, and this focus
can be justified by the desire to limit the variability that comes from extraneous sources. Drivers
are generally very familiar with their commuting route and the traffic patterns that they will
likely encounter. By limiting the initial analysis to commuting trips, there is a good chance that
most of the variations in ACC and CACC usage will be due to driver preference and local traffic
conditions.
The coding for trip mode allowed for four possibilities: baseline, ACC, CACC, or urban driving.
Baseline trips were trips taken on designated baseline days where the participant was instructed
not to use the ACC system. However, since the participants did not always follow the baseline
day instructions, baseline day trips were manually verified to ensure that the participants did not
use the ACC system during the trip before the trip was officially coded as a baseline trip. Trips
coded as ACC indicated that the participant was free to use the ACC system during that trip,
regardless of whether or not the participant actually chose to use the system. Trips coded as
CACC trips indicated that the participant was driving the copper CACC- equipped vehicle, and
finally, trips coded as urban driving indicated that due to the trip’s length and the roads being
travelled during the trip, there was no opportunity for the participant to use either the ACC or
CACC system.
Finally, trips were coded as to whether or not they were full trips or partial trips. This coding
was of particular concern for commutes. A partial trip could occur either from a data acquisition
system error or from the driver breaking up a longer trip into smaller ones. As an example, a
43
driver may have decided to stop at a mall or grocery store on the way home. If the store was
near their work or home, then this was not of particular concern; however, sometimes, the store
may have been half- way between work and home. Thus, instead of having a typical 45- minute
trip home on the freeway, the evening commute was split between a 15 minute trip and a 30
minute trip. The coding of partial trips was accomplished using both the participant’s trip logs
and the GPS traces recorded during the trip.
5.5 Data Reduction
The final step of the data processing before the analysis phase is commonly referred to as the
data reduction phase. The goal of the data reduction phase is to filter, combine, and process the
DAS system data and any other required observations into meaningful metrics that can be coded
into a data set and subsequently analyzed. As an example, if one wanted to analyze the
conditions when drivers activated the ACC system, the data reduction step would consist of the
following steps:
1. Define the criteria that would constitute an ACC activation event. In this case, the criterion
that defines an ACC activation event is already recorded in a single value in one of the DAS
data files. However, for more complicated analyses, the criteria that would constitute an
event of interest might include filtering a number of different parameters.
2. Define a set of metrics of interest that would describe the event or the conditions around the
event. In this case, the metrics may include vehicle speed and following distance at the time
of the ACC system activation.
3. Locate all ACC activation events for all trips.
4. Process each ACC activation event, calculating and recording the selected metrics of interest
for each event.
The amount of data collected during this study was quite large and unwieldy to process and
analyze. For each driver there is approximately 10 GB of data and video files. That equates to
roughly 15 to 18 hours of video and millions of lines of data. The sheer amount of data that
needed to be processed required a number of tools to be created to both efficiently access, search,
processes, and view the data.
Several architectures and data processing tools for storing and accessing the data were evaluated,
and the decision came down to two leading candidates. The first candidate was to create a
database with data. While this method holds some promise for the future, the issues in building
and maintaining this type of system provided too challenging for the resources of this project.
The second candidate architecture was to store the data in flat files using the standardized
conventions previously discussed in Section 5.4.2. While this architecture was simple to
implement, it necessitates the use of a number of tools to efficiently locate and access the data, as
well as a trip key that was manually created ( described in Section 5.4.4).
The majority of the data reduction was done using scripts written in MatLab, an interactive
programming environment. For each analysis discussed in the results sections, one or more
scripts were written to process the raw system and vehicle data in order to create the appropriate
44
metrics that were required for analysis. Manual checking of the video data was used to clarify or
code additional parameters or metrics as needed.
At the lowest level of the data processing architecture, functions were written to open and merge
all of the original 2- minute data files for a single trip. At this level, each time the data for a trip
was loaded into memory, unit conversions were applied, new parameters were generated, and
filters were applied to smooth the data before any data processing commenced. As examples, all
speed data were converted to m/ s, acceleration was calculated and filtered based on vehicle
speed, and new parameters such as time- to- collision and required deceleration were computed.
Additionally, at this level of the architecture a number of general functions and utilities were
written to support data format conversions, to support the creation and manipulation of graphs,
and to support file operations, such as reading and saving the various data files generated during
the analysis.
At the middle level of the automated data processing architecture, several analysis templates
were written to facilitate running an automated analysis on either the entire set of data or on a
subset of the data. The primary purpose of the analysis template was to cycle through each trip
in the master list of trips for the project, load a trip into memory, process that trip, and compile
and save the resulting data set in a format that could be easily imported into SPSS for statistical
analysis or Excel for producing graphs.
The top level of the automated data processing architecture consisted of trip filter plug- in scripts
and analysis plug- in scripts which could be referenced by an analysis template. Trip filter plug-in
scripts allowed an analysis to examine a subset of the trips contained in the master list of trips.
As an example, the list of trips to be processed by the analysis template could be filtered by
driver, time of day, day of the week, whether or not the trip was a commute, etc. Most of the
analyses in this report examined only commuting trips. Some of the analyses in this report
examined only Baseline trips, while others examined ACC or CACC trips only.
The analysis plug- in scripts provided the instructions on how to process a trip once it was loaded
into memory and what data parameters to calculate and save. The data files that come from the
vehicles are all time- coded lists of when certain things happened in the data, such as the speed at
any given time or when the driver activated the ACC/ CACC system. An analysis plug- in script
might, for example, search a trip for every instance when the vehicle is traveling greater than 35
mph and following a lead vehicle with a following time gap of less than 3 second. Each of those
following events might then be summarized in terms of length, average speed, peak deceleration
rates, etc. Thus, the analysis plug- in script defines the meaning of each row and column that
goes into the data set that will be output by the analysis template.
This data analysis architecture provided advantages in data processing speed and efficiency. In
order to generate a new analysis, one only needed to write an appropriate trip filter and an
analysis script to analyze a single trip. Once these were written, the lower levels of the
architecture took care of scaling the analysis up from being applied to a single trip to being
applied to all of the relevant trips contained in the entire experiment data set.
45
6 Experiment Protocol
6.1 Overview
The experiment protocol was designed to evaluate the perceived acceptability of the shorter gap
settings offered by the CACC system using an on- the- road, in- real- traffic, study. Although the
goal of the experiment was to test the shorter gaps provided by the CACC system, most drivers
in the U. S. are unfamiliar even with the already available ACC systems that are currently on the
market. At the time of this study, ACC systems were generally only available on high- end,
luxury cars, and often as a fairly expensive option, resulting in a very small market penetration.
Thus, the experimental protocol that was developed needed to first allow the test participants
enough time to get acquainted with a standard ACC system before the testing of a CACC system
could begin.
The experiment protocol was split into two phases. ( See Table 6.1.) In the first phase, the test
participants were given the silver Infiniti FX45 with the factory installed ACC system to drive as
their own ( without an experimenter present) for a period of about 11 days. During that period,
there were roughly 7 week days when the test participant would be commuting to and from work
with the vehicle and 4 weekend days when the test participant was free to use the vehicle
wherever they were going. Additionally, there were minor variations between participants. As
an example, some participants had the car delivered on Thursday morning, making Friday the
baseline day.
The second phase of the experiment lasted for two days, immediately following the last day of
the first phase. In this phase, the test participant drove the copper Infiniti FX45 with the CACC
system for their morning and evening commutes. During these four trips an experimenter was
present in the vehicle with the test participant, and the silver Infiniti FX45 was driven by a
confederate to play the role of the lead vehicle during the commute. Additionally, sometimes the
CACC testing days ended up falling on Tuesday/ Wednesday instead of Monday/ Tuesday due to
the holidays, rain, or other variations in the participant’s work schedule.
Table 6.1: Summary of testing condition per day.
Wednesday Thursday Friday Saturday Sunday Monday Tuesday
Week 1 Vehicle
delivered
Day 1
No ACC
Day 2
ACC
Day 3
ACC
Day 4
ACC
Day 5
ACC
Day 6
ACC
Week 2 Day 7
ACC
Day 8
No ACC
Day 9
ACC
Day 10
ACC
Day 11
ACC
Day 12
CACC
Day 13
CACC
After the fourth participant, there was a slight change to the second phase protocol to add a short
CACC practice session before conducting the CACC testing during the participant’s morning
and evening commutes. The half- hour CACC practice session was conducted at the participant’s
convenience between days 8 and 11. The purpose of this practice session was simply to
familiarize the participant with the CACC system. This additional practice session was added
because it subjectively seemed that it took the participants about a half hour to get comfortable
with the CACC system, and this learning effect might have been influencing the first CACC
testing day.
46
The CACC driving sessions took place on public highways on the routes designated by the
participants. Thus, the CACC testing was all done on routes with which the participants were
already familiar. The test participants were informed that they could stop at any moment or
choose any route that they desired, but they were asked to drive in accordance with all state and
local driving laws.
6.2 Participant Recruitment
To be eligible to participate in the study, potential candidates needed to meet the following
criteria:
• Have a valid California driver’s license
• Have a clean driving record with no moving violations within in the last 3 years and no DUIs
• Commute daily with 25 or more minutes spent traveling at freeway speeds each way
• Have relatively secure parking at both home and work
• Be between the ages of 25 and 55 years of age
The initial test participants were recruiting using the U. C. Berkeley and U. C. San Francisco
Research Subject Volunteer Program, which is a basically a website bulletin board where
potential participants can browse studies which are currently seeking volunteers. After an
experimenter validated a candidate participant’s eligibility, either through a phone call or email,
a participant packet was mailed to the participant. ( See Appendix B.) The packet contained a
cover letter, study consent forms, and a DMV records release form ( to verify the candidate’s
eligibility to participate). A potential participant’s DMV records were checked either by having
the participant mail the DMV directly and obtain a copy of their records or by consenting to have
California PATH check their DMV records electronically using the Volunteer Select Plus service
available from LexusNexis Risk & Information Analytics Group, Inc.
As part of the consent form package, three documents had to be signed by the participants. The
first document provided participants with informed consent regarding their participation in the
study. This document detailed the study, providing the participants with enough information to
make an informed decision about whether or not they still wanted to participate in the study. The
second document was a video and photographic image release form which allowed participants
to designate appropriate uses for any images collected during the study. Finally, there was a fuel
card user agreement, which was only required if the participant wished to use a University
provided fuel card to purchase gas for the vehicle. It was not required if the participant wished
to purchase fuel on his or her own and submit receipts for reimbursement at the end of the study.
The participants generally had several weeks to review the consent materials and ask questions,
as the forms were not signed until the day that the vehicle was delivered to the participant.
6.3 Test Procedures
6.3.1 Phase 1: Gaining Experience with ACC Systems
The goal of the first phase of the experiment was to allow the driver to acclimate to the test
vehicle and to gain experience with a typical ACC system, since it was assumed that most
drivers in the US would be unfamiliar with such a system. The first phase also allowed for the
47
collection of baseline driver behavior data during two days when the test participant was asked to
drive the vehicle without using the ACC system. This phase of the protocol could further be
broken into five steps over 11 days.
6.3.1.1 Step 1: Vehicle Delivery
After a potential participant’s eligibility to participate in the experiment was verified, a testing
date was scheduled, and the vehicle was delivered to the participant’s place of residence or work
by an experimenter on either a Wednesday or a Thursday. At the time of delivery, the
experimenter completed a vehicle checkout checklist, and trained the test participant in the
features of the vehicle and the use of the ACC system.
The first part of the training took place when the vehicle was parked. The experimenter
explained the ACC functions, how to activate them, and how to turn them off. The test
participant was invited to ask questions throughout this step.
The second part of the training involved taking the vehicle on a highway for a short trip with the
experimenter in the passenger seat. The participant was then instructed to turn the ACC system
on whenever he or she felt comfortable to do so. The experimenter then talked the participant
through the features of the system and answered any additional questions that the driver had
about the system. The experimenter also stressed the following important parts of the
experimental protocol to the test participant.
• The participant was the only person allowed to drive or ride in the vehicle.
• The participant was to try to use this vehicle as he/ she would use their personal vehicle.
• The participant should try to use the ACC when conditions allowed ( highway driving
with relatively free flow traffic) as much as possible on the non- baseline days of the
protocol.
• The participant was encouraged to try the different gap settings until finding one with
which they were comfortable.
• The participant was reminded to fill out a logbook entry for each trip taken in the vehicle.
6.3.1.2 Step 2: One Baseline ( Non- ACC) Driving Day
On Day 1, the first full day with the ACC equipped vehicle ( which was typically a Thursday),
the test participant was instructed to drive the vehicle without using the ACC system. Although
the participant was not actively using the ACC system, the DAS was still recording all of the
data that would normally be collected when the ACC system was active. The data collected
from this day was then used as a baseline to characterize the test participant’s normal driving
behavior.
6.3.1.3 Step 3: Six ACC Driving Days
After the baseline driving day, the participant was allowed to drive the vehicle for the next six
days while freely using the ACC system. This would include four days of commutes and two
weekend days of experience with the ACC system. Data from the vehicle’s DAS were typically
downloaded on day 6 while the test participant was at work.
48
6.3.1.4 Step 4: Second Baseline ( Non- ACC) Driving Day
At this point, the test participant has had the ACC equipped vehicle for about a week. On Day 7,
the second Thursday, the participant was again instructed to drive the vehicle without using the
ACC system. This day served as a second baseline to allow for comparisons to be made between
the participant’s behavior before using the system and the participant’s behavior after using the
system to see whether or not the system had an influence on the participant’s typical behavior.
6.3.1.5 Step 5: Three More ACC Driving Days
On Days 8 through 11, the test participant was again allowed to drive the vehicle using the ACC
system. This would include one commute day and two weekend days. During this period of
time, the participants were instructed to fill out the first survey on their experiences with the
ACC system ( see Appendix C).
6.3.2 Phase 2: Using the CACC system
For most of the participants ( excluding the first four), the second phase of the experimental
protocol generally began with a half- hour practice CACC test drive. The experimenter and a
confederate lead- vehicle driver generally met the test participant at his or her residence or place
of work with the CACC equipped vehicle. The test participant then drove the CACC- equipped,
copper- colored, FX45 with the experimenter present in the passenger seat, while the silver-colored
FX45 was driven by the confederate driver to serve as the lead vehicle. The purpose of
the practice session was to familiarize the participants with the CACC system. After a brief
introduction to the differences between the ACC and CACC system while the vehicle was
parked, a 15 to 30- minute practice drive was conducted on a nearby road selected by the
participant. During the practice drive the participant was asked to try each of the new gap
settings for a few minutes, just to get an idea of what the settings were like.
After the practice session, the protocol provided for two days ( four commute trips) using the
CACC system. For each CACC test trip, the experimenter and confederate lead- vehicle driver
met the participant at their home or workplace with the CACC- enabled, copper- colored, FX45.
Although an experimenter was present during this phase of testing, the participant still scheduled
the times of departures, routes taken, and even the lane of travel. All of this was communicated
to the lead vehicle driver via two- way radio. The experimenter also served as a safety observer
since the CACC system was a prototype, and was only reliably capable of following the
communication- enabled, silver- colored FX45. If the CACC system misbehaved or other
vehicles cut in between the two test vehicles, the experimenter was able to turn the system off
with a kill switch which, in effect, mimicked the functionality of the CACC on/ off switch.
At the end of the last day of CACC testing, the participant was asked their general impressions of
the CACC system and given a survey on their experiences with both the ACC and CACC system
to be completed and mailed back ( see Appendix C). The participants were then thanked and paid
$ 100 for their participation in the experiment. They were also reimbursed for any fuel expenses
incurred while in possession of the ACC equipped vehicle. The vehicles were then inspected and
readied for the next participant.
49
It should be noted that the reimbursement of fuel expenses served partially as an additional
incentive for participation. However, since the research vehicles required premium fuel and the
EPA rated fuel economy was less than most vehicles, the fuel reimbursement also served as a
means to make sure that participants did not have to pay a monetary penalty to participate in the
experiment, especially if the participant typically drove a more fuel efficient car on their daily
commute.
50
7 Overview of Participants and Trips
7.1 Test Participants
The sample was composed of 16 participants, 8 females and 8 males with ages ranging from 25
to 46 ( mean 35, std dev 6.2). All of the participants had a clean driving record for at least 3
years, and none of the participants had a DUI on record. Table 7.1 below details some of the
participants’ characteristics. The self- estimated annual average mileage of the participants
ranged from 10,000 to 26,000 miles per year with a mean of 17,500 mi and a standard deviation
of 5600 mi. The daily commutes of the participants in the study ranged from 24 to 44 miles
( each way), with a mean of 30 (± 7) miles ( where ± is used to denote the standard deviation), and
the commutes ranged from 27 to 72 minutes with a mean of 45 (± 19) minutes. All participants
were familiar with conventional cruise control, but none had experienced driving an ACC
equipped vehicle before participating in this study.
Table 7.1: Test Participant Characteristics
# Gender Age Est. Annual
Mileage
Commute
( miles)
Mean Commute
Time ( minutes)
Month of
Participation
1 Female 32 10,000 24 27.0 October 2008
2 Male 36 15,500 28 44.8 October 2008
3 Female 40 15,000 37 63.7 November 2008
4 Female 38 12,000 23 35.2 December 2008
5 Female 45 24,000 33 53.9 January 2009
6 Male 33 18,000 44 64.8 February 2009
7 Male 35 25,000 43 58.7 April 2009
8 Male 32 15,000 24 30.5 April 2009
9 Male 29 15,000 29 41.7 May 2009
10 Male 30 10,000 23 33.4 June 2009
11 Female 27 18,000 30 57.8 June 2009
12 Male 38 22,000 25 45.4 July 2009
13 Female 25 10,000 25 23.7 July 2009
14 Male 46 20,000 34 43.4 August 2009
15 Female 43 25,000 24 50.4 September 2009
16 Female 38 26,000 37 72.7 November 2009
7.2 Data Set of Participant Trips
The results presented and discussed in this report primarily focus on the participants’ commutes,
defined as a trip or series of trips taken by the participant between their home and work. A
single commute may be broken into a series of trips because, in the context of this study, a trip is
defined as the data gathered from the time when the vehicle was turned on until the time when
the vehicle was turned off. Thus, if a participant drove from work to a store, parked the vehicle,
51
and then later drove from the store to home, then the commute would span two trips. Table 7.2
summarizes the data set of commutes and individual trips that have been analyzed in this report.
Table 7.2: Overview of Commuting Trips in the Data Set
Baseline Driving ACC Driving CACC Driving
Commutes 51 173 62
Individual Trips 58 180 62
Events of Interest 412 following events 689 system activations 352 system activations
Based on the experimental plan, it was expected that there would be approximately 64 baseline
commutes ( 4 per participant); 160 ACC commutes ( 10 per participant); and 64 CACC commutes
( 4 per participant). However, there were a number of reasons for the differences between the
expected and actual number of commutes collected during the experiment. Some trips that were
taken were lost to DAS system failures, and others may have been lost to normal variations in the
participant’s schedule, such as having an engagement after work. Furthermore, a number of
baseline trips were missing due to participants forgetting to follow the protocol on baseline days,
which partly accounts for the increase in the number of ACC commutes collected. Additionally,
variations between participants regarding on which day the ACC vehicle was handed out resulted
in a few extra ACC trips for some of the participants. As shown in Table 7.3, even with minor
data losses, all of the participants had at least 1 baseline driving trip, 7 ACC commuting trips,
and 3 CACC commuting trips to analyze.
Table 7.3: Summary of Trips in the Data Set by Participant Participant Morning BEavseelninineg Other Morning EAveCnCi ng Other Training MCoArCniCn g Evening 1 Female 2 2 0 6 6 4 ‐ 1 1 2 2 Male 0 1 0 10 7 9 ‐ 2 1 3 Female 1 1 0 6 6 10 ‐ 2 2 4 Female 2 3 1 5 5 0 ‐ 2 2 5 Female 1 1 0 5 6 4 1 2 2 6 Male 1 0 0 6 5 0 1 2 1 7 Male 2 2 0 6 4 5 1 2 2 8 Male 4 2 0 6 5 15 1 2 2 9 Male 3 3 0 5 5 11 1 2 2 10 Male 0 1 0 9 6 21 1 2 2 11 Female 2 1 2 5 6 0 1 2 3 12 Male 0 2 0 6 7 18 02 2 2 13 Female 2 3 0 5 4 4 1 2 2 14 Male 1 2 0 5 7 6 1 2 2 15 Female 3 4 0 5 4 19 1 2 2 16 Female 1 2 0 4 3 2 1 2 2 Totals 25 30 3 94 86 128 123 31 31
1 No pre- commute CACC training was provided for participants 1 through 4.
2 Pre- commute CACC Training was provided for participant 12, but the data was lost.
52
The data set also contained 128 trips that were recorded when the ACC was used even though
the trip was not part of a commute, and 123 trips were recorded when the driving was primarily
low speed without a chance to use the ACC system. Neither of these sets of trips was analyzed
in this report.
7.3 Participant Commute Characteristics
7.3.1 Overview
There were 265 commuting trips recorded that were comprised of a single trip that was, more or
less, directly between the participant’s home and work. The overall mean commuting distance
was 30.2 miles, and the mean commuting time was 45.5 min (± 19 min std. dev.), with individual
commutes ranging from as little as 15.5 min to 105.3 min. Table 7.1 previously detailed the
mean length of each participant’s commute both in terms of distance and time, and Figure 7.1
depicts the general freeway routes of the study participants. The shortest commutes were
approximately 24 miles, taking an average of 27 minutes; and the longest commutes were on the
order of 37 to 44 miles taking, on average, 58 to 73 minutes. However, commuting distance was
not always a very good predictor of commuting time due to variations in traffic patterns.
Figure 7.1: Bay Area Freeways Covered During the Study
53
As shown in Figure 7.1, most of the freeways in the San Francisco Bay Area were covered as
part of this study. Each color overlaid on the map represents a different driver’s commute during
the study. However, what is not depicted in the figure is the fact that most of the participants had
what would commonly be considered partial reverse commutes. Given the congested nature of
Bay Area freeways during commuting hours, this bias was both by design and necessary since
the ACC and CACC systems only worked when the vehicles were travelling more than 35 mph.
Participants who had highly congested commutes were simply not selected for the study.
7.3.2 Commute Length
As previously stated, the overall mean commuting trip length was 45 (± 19) min, but the
commutes varied greatly by participant. Thus, the lengths of the commuting trips in the data set
were examined using a repeated measures, generalized linear model to understand whether or not
there were any inherent biases in the data set that might lead participants or groups of
participants to favor one mode of driving over another. The model included a full factorial of
gender ( a between- subjects effect), cruise control system ( baseline, ACC, and CACC), and
commute time- of- day ( both within- subjects effects). Two other factors, day- of- the- week and
day- of- the- study, were included in the model as within- subjects covariates since there would
have been missing cell problems if they were included as factors. In essence both of these
covariates are confounded with the main effect of cruise control system since baseline and
CACC testing occurred only on specific days of the week and CACC testing always occurred at
the end of the study. Gender was not significant, but the cruise control system factor was
statistically significant, Wald χ2
2= 6.49, p=. 039. As shown in Figure 7.2, commutes when the
CACC system was used tended to be about 6 to 7 minutes longer than the commutes on baseline
days or ACC days.
Figure 7.2: Relationship Between Commute Length and Study Phase.
The roughly 6- minute difference in commuting times between CACC trips and other trips was
most likely an artifact of the experimental protocol. The instrumented vehicles typically take
several minutes for the DAS to fully start up and start recording data. Thus, on Baseline and
ACC trips, this would mean that the first few minutes of the trip, typically urban driving, were
54
not recorded. However, during CACC testing, the experimenters and participants typically
waited for both the ACC and CACC vehicles to complete their startup sequence before
beginning a commute in order to make sure that the CACC communication was working
properly. Thus, the apparent additional commuting time for CACC trips is most likely explained
by the pre- trip coordination between the ACC and CACC vehicles.
Additionally, as one might expect, both time of day ( Wald χ2
1= 4.23, p=. 04) and the interaction
between time of day and day of the week ( Wald χ2
1= 12.58, p<. 001) were found to have a
significant impact on the length of the commute. As shown in Figure 7.3, evening commutes
were generally longer than morning commutes, and Thursday and Friday evening commutes
were typically the longest during the week. However, there are some biases in this figure
because, as described earlier, CACC trips were generally longer than Baseline or ACC trips, and
CACC trips usually only took place on Mondays or Tuesdays. As such, Figure 7.4 removes the
confounding CACC trips, showing only Baseline and ACC trips as a function of day of the week.
This graph is probably a better representation of the effects of time of day and day of the week
on the length of the commute during the study. While the general trends are similar between the
two figures, the removal of the CACC trips lowered the mean commute lengths on Monday,
Tuesday, and Wednesday.
Figure 7.3: Relationship Between Commute Length, Day of the Week, Time of Day.
55
Figure 7.4: Relationship Between Commute Length, Day of the Week, Time of
Day, Excluding CACC Testing Days.
7.3.3 Opportunity to Use the ACC- CACC Systems During Commutes
The overall length of the commuting trips, which was examined in the previous section of this
report, provided some confidence that there were no inherent biases in the data set; however, the
overall commute length may not necessarily equate to equal opportunity for ACC or CACC
system use. Since the ACC and CACC system generally only functioned ( or at least could be
engaged) when the vehicle was travelling faster than 35 mph, the analyses detailed in this section
examined both the number of times and the total length of time that the participant’s vehicle was
travelling faster than 35 mph during each commuting trip.
Overall, there was a median of 12 and a mean of 14.8 (± 10.3) events when the vehicle was
travelling greater than 35 mph, with a minimum of 1 and a maximum of 50 events per trip. The
number of events was modeled using a repeated measures, generalized linear model. In the
model, gender was considered a between- subjects factor, and cruise control system and commute
time of day were considered within- subjects factors. Day of the week ( excluding weekends),
was again modeled as a within- subjects covariate, even though it was confounded with the cruise
control system factor. None of the model factors had a statistically significant impact on the
number of over 35 mph events per trip, but there was a slight trend for fewer events during the
morning commutes, median of 11 and mean of 13.6 (± 9.3), than there were during the evening
commutes, median of 12 and mean of 16.0 (± 11.1).
Examining the total time spent travelling faster than 35 mph, the overall mean was 24.9 (± 8.3)
minutes. Using the same analysis and model as described above, several factors were found to
be significant. First, the cruise control system main effect was significant, Wald χ2
2= 6.19,
p=. 045. As shown in Figure 7.5, trips that were designated as baseline driving ( without the aid
of ACC or CACC) resulted in a shorter time spent travelling faster than 35 mph. This bias was
probably due to the fact that baseline driving days were usually designated for Thursdays or
Fridays, which as discussed in Figure 7.4, tended to be days with longer commutes due to
increased traffic.
56
Figure 7.5: Opportunity for ACC/ CACC System Use by Study Phase.
While the heavier traffic typically present later in the week may have provided less opportunity
for participants to be travelling at speeds greater than 35 mph during the baseline driving trips,
the analysis of the time spent travelling above 35 mph also found one of the higher order
interactions to be significant, which may also account for the biases in the baseline driving
condition. The interaction between gender, time of day, and cruise control system was found to
be significant, Wald χ2
2= 6.785, p=. 034. Typically, in small sample sizes, higher order
interactions end up being the result of some bias in the sample, and in this case, that appears to
hold true. As shown in Figure 7.6, the morning baseline drives for males resulted in more time
spent above 35 mph, 26.2 minutes, than the other baseline drives, which ranged from 21.4 to
21.8 minutes spent above 35 mph. The reason for this appears to be a small sampling bias in the
number of baseline drives that were collected for the males. For whatever reason, be it system
failure or the participant simply forgetting that it was a baseline driving day, there were no
morning baseline driving trips recorded for three of the male participants, who also just
happened to be the three males with the shortest commutes ( ranging from 23 to 28 miles).
Figure 7.6: Gender by Time- of- Day by Cruise Control System Interaction.
57
Finally, in the analysis of the time spent above 35 mph, both time of day and day of the week
were marginally significant, Wald χ2
1= 2.73, p=. 098 and Wald χ2
1= 2.75, p=. 097, respectively.
As shown in Figure 7.7, morning commutes tended to offer more opportunity for ACC/ CACC
system use, and as the week progressed, there was decreasing opportunity for ACC/ CACC use
during the commutes. However, the mean difference in opportunity for cruise control system use
between morning and evening commutes was less than a minute, and the mean difference in
opportunity for cruise control system use between early in the week and later in the week was on
the order of two- and- a- half minutes.
Figure 7.7: The Relationship Between Time of Day, Day of the Week, and
Opportunity for System Use.
7.4 Summary and Conclusions
One of the key concerns when running a short- duration, naturalistic, field experiment on public
roads is the potential for uncontrolled circumstances, such as weather or traffic patterns, to
systematically bias the results. The focus of this report section was to provide a description of
the study participants, and to examine the resulting data set of commuting trips to determine
whether or not there were any obvious biases which may have influenced the participants’
decisions to use the ACC or CACC systems. The sample collected in this study appeared to be
well balanced in terms of gender, driver age, and commute length, and the commuting trips
collected during this