Automotive Collision Avoidance System Field Operational Test Program
FIRST ANNUAL REPORT

11 CW FUNCTION (Task C3 and C5)

11.1 Threat Assessment Simulation Development (Task C3A and 5A)

Objectives

The objective of this task is to develop and document a computer simulation of ACAS threat assessment performance during forward collision scenarios. The product of this effort, the TASIM (Threat Assessment SIMulation), will be a ‘user-friendly’ computer code – to be run on a PC, with three-dimensional graphics available for use on a Silicon Graphics, Inc. (SGI) workstation – with appropriate models and fidelity to accurately gauge the effectiveness of unique user-defined ACAS threat assessment algorithms. In order to accomplish this, an important sub objective of the simulation development is to integrate ACAS-specific or relevant ‘reusable’ sensor, fusion, vehicle, and roadway models into a useable and reasonable simulation of ACAS performance.

A key component to ‘useable’ will be the provision of additional tools to provide a graphical user interface for setting up simulations based on scenario definitions, observing the effect of various threat assessment algorithms, and analyzing output data. Additionally, an annotated example of a forward collision scenario with ACAS operation will be provided to GM, plus the provision of a tutorial at Warren, Michigan by February 28, 2001.

Approach

The block diagram for TASIM is shown in Figure 11.1. It shows the integrated architecture of TASIM, with constituent blocks representing discrete modules. Note that the block diagram is divided at the top level into a "simulated world" and a "sensor & hardware model". The modules within the "simulated world" primarily draw from the UC Berkeley PATH Program’s SmartAHS model (http://www.path.berkeley.edu/smart-ahs/index.html) with ACAS-specific upgrades recently provided in the Host Vehicle States block (and described later in this report under Work Accomplished).

The modules within the "sensor & hardware model" block are provided by other members of the ACAS team, GM (In-Vehicle Sensors, Vision System, GPS/Map-Based Road Geometry, Radar Target Detection, Target Selection, Threat Assessment), Delphi (Driver Visual Interface) and HRL (Data Fusion). For the most part, these modules are provided in pseudo-code or block diagram form, and PATH developers have written them into C-language. Figure 11 2 illustrates how the configuration control is implemented.

Figure 11.1 Integrated Architecture for TASIM

Figure 11.1 Integrated Architecture for TASIM

 

Figure 11.2 Example HTML Interface: In-Vehicle Sensors Module

Figure 11.2 Example HTML Interface: In-Vehicle Sensors Module

Consistency and control is maintained by defining input and output variable definitions via HTML scripting, wherein hyperlinks to summon these definitions can be called. For example, the In-Vehicle Sensors Module in Figure 11.1 can be double-clicked to show Figure 11.2. From Figure 11.2, variable declarations, internal modules, or source code can be accessed. Hence, with the module interfaces frozen, multiple developers at PATH can (and have) translated pseudo-code and block diagrams of the modules in Figure 11.1 into C-language code, with the primary formal interface enforced through a controlled check-in and check-out registry.

The TASIM tool development integrates:

  1. SHIFT3 models of vehicles, highways and controllers
  2. Uniform interfaces between the C and the SHIFT codes to support independent development and re-coding of C-code modules should new or refined models be added in the future
  3. GUI supporting testing and evaluation.

In essence, and as illustrated in Figure 11.3, the TASIM development integrates user-provided C-code with a simulation kernel implemented in the SHIFT programming language, with 2-D visualization implemented in tcl/tk (in a version called TkSHIFT, with point-of-departure look and feel shown in Figure 11.4), and 3-D visualization implemented in SGI Performer software (with point-of-departure look and feel shown in Figure 11.5). The software will compile with MSVC 6 and run under Windows. This strategy allows:

  1. Use of considerable legacy investment in SmartAHS
  2. Simplified user interaction
  3. In implementation, avoids delays and inefficiencies due to interprocess communication; and
  4. Simplified programming, especially the task of porting from Unix to Windows.

Figure 11.3 TASIM Layers: TkSHIFT, SHIFT and C

Figure 11.3 TASIM Layers: TkSHIFT, SHIFT and C

 

Figure 11.4 Starting Point of 2-D GUI for TASIM

Figure 11.4 Starting Point of 2-D GUI for TASIM

 

Figure 11.5 Starting Point of 3-D Visualization for TASIM

Figure 11.5 Starting Point of 3-D Visualization for TASIM

Work Accomplished

1. Conducted module and code architecture tradeoff study
2. Conducted detailed TASIM interface/specification meeting with GM
a. Achieved consensus on module and code architecture
b. Defined level of vehicle host simulation fidelity
c. Received preliminary definition of simulation scenarios
3. Received preliminary TASIM modules from GM
a. In-Vehicle Sensors

Accelerometer

Compass

Wheel Speed Sensor

Yaw Rate Sensor

Steering Wheel Angle Sensor

b. Vision System
c. GPS/Map-Based Road Geometry
d. Radar Target Detection
e. Data Fusion
f. Target Selection
g. Threat Assessment
h. Driver Visual Interface
4. Coded in-vehicle sensor models
Coded vision system model
Coded the radar model (field of view test and target report generator) for a single target
Developed preliminary host and target vehicle models

Coding of GM Modules

Coding was underway with the set of TASIM modules received from GM, with an anticipated completion of August 2000. Some testing was conducted to eliminate memory and compilation mistakes. At this junction, there was no testing done to ensure the correctness of the model, but this is planned as a major component to the TASIM development effort, as discussed in Plans for Next Six Months.

Development and Implementation of PATH Modules

The new PATH modules, host vehicle dynamics and controllers and target vehicle kinematics, have been integrated into the SHIFT-based world simulation, although there are a few remaining host vehicle lateral and longitudinal features (e.g., lateral dynamics under slip or wet conditions) that are not yet implemented; expected completion is September 2000.

The vehicle host dynamics models are designed to provide sufficient granularity and fidelity inputs to the in-vehicle sensors which later effect the threat assessment. Specifically, the host vehicle dynamics interface with the road geometry, environment and path planning modules. In order that the vehicle follows a pre-defined trajectory, a controller is also designed. The task internal to the vehicle model is following a reference trajectory such that the test scenario definitions are satisfied. The models are written such that in the closed loop mode, the vehicle will follow a desired trajectory while obeying its physical dynamics.

3-D Visualization

The existing SmartPath 3.2 animation suite is the basis for the TASIM 3-D visualization. In the current period, it was investigated for suitability for development and/or delivery as under x86 Linux and IRIX 6.4. Since SGI released Performer under Linux, it is possible to port SmartPath to Linux without rewriting the entire program to use another scene graphing package. This will allow a high performance, cost effective and stable platform (PC) for graphics and visualization.

Specific accomplishments include:

  1. Compilation and running of SmartPath 3.2.1 on IRIX 6.4.
  2. Installation and running of Performer for Linux at ~60 and ~120fps on TNT2 and GeForce2 GTS, respectively.
  3. Compilation of running of SmartPATH 3.2.1 on Linux operating system underway; currently in the debugging process, particularly with overcoming need for SGI widgets.

Synchronous Video Images

Several tasks were accomplished with displaying synchronous video images:

  1. In conjunction with GM, defined data specifications for:
  1. Using these specifications, digitized test files and generated MJPEG clips.
  2. Implemented software utility created by GM to convert .log files into MJPEG files
  3. Played back GM-created .log files at PATH (using Microsoft Media Player using MJPEG codec distributed by Pegasus Imaging (http://www.jpeg.com)

Scenario Definition

ACAS scenarios provided by GM and shown in Table 1 were examined and decomposed into constituent atomic maneuvers with the goal that each of these maneuvers can automatically be instantiated in SHIFT and that the user could therefore build the current or a similar expanded (or more complex) set of maneuvers.

Table 11.1 Nominal ACAS Scenarios

 

 

SV

POV

Coordination

Roadway

Environment

Maneuver

Maneuver

Inter-vehicle

Segments

 

C1

constant v straight

stopped middle of the lane

none

straight

right (no direct lighting)

C2

constant v straight

constant v straight

"

unpaved or poorly paved

-

C3

constant v straight

braking moderately

"

-

-

C6

constant v (curvature)

stopped middle of the lane

"

straight+transition (<20m)+curve (r, speed (SV))

wet

C8

constant v (curvature)

constant v (curvature)

"

tight curve

-

C9

constant v straight

constant cuts in front of SV

TBD

straight

-

C10

change lanes

stopped

none

straight

-

C12

SV follows POV

(10+5s) follow lane+braking

TBD

straight

-

C13

constant v straight

constant v straight

none

straight

-

constant v straight

"

-

constant v straight

"

-

C14

constant v straight

constant v straight

"

straight

-

constant v straight

"

-

C16

=C6

=C6

"

=C6+poor lane markings

-

A7

Highway speeds tailgating a lead vehicle

 

 

 

 

V8

Lead-follower, curve, leader decelerates

 

 

 

 

Two types of atoms are conceived:

  1. Open loop with the following parameters:
  1. Feedback (in increasing order of difficulty)

Follow center of the lane. Parameters:

Landmark based navigation. Follow center of lane until the detection of a static feature. Parameters:

Closed-loop based navigation. Examples:

From this, subject vehicle atomic maneuvers listed in Table 11.2 are conceived.

Table 11. 2 Maneuvers for Subject Vehicle

2a. Total Set:

Maneuver

Description

Constant v straight Constant longitudinal speed on a straight line
Constant v following center lane Constant longitudinal speed following center of lane
Change lanes  

Follow a leader at a prescribed distance Follow a designated vehicle at a prescribed distance
Emergency braking Brake according to a defined brake pattern
Start Start motion from the side of the highway

2b. Required for Maneuvers Shown in Table 1:

Maneuver

Description

Constant v straight

Constant longitudinal speed on a straight line

Constant v following center lane

Constant longitudinal speed following center of lane

Change lanes

 

Emergency braking

Brake according to a defined brake pattern

Start

Start motion from the side of the highway

Undertaking a similar exercise, the set of atomic maneuvers for the target vehicle is listed in Table 11.3.

Table 11.3 Maneuvers for Target Vehicle

Maneuver

Description

Follow lane

Follow lane with a certain longitudinal speed profile

Changetoadjacent lane

Move from the current lane to the line crossing between this lane and the adjacent one (left or right as a parameter)

Follow a leader at a prescribed distance

Follow a designated leader vehicle within a prescribed distance

Brake

Initiate and maintain a braking profile

Startfromside

Start moving from the side of the highway till the center of the highway

Null

Do nothing

Table11. 4 lists the preliminary codification of inputs to these atomic maneuvers, while Table11. 5 lists the outputs. The internal state and termination conditions to these maneuvers are provided in Tables 11.6 and 11.7, respectively. The termination conditions, which will be user input, are the conjunction of the main condition and the enabling condition. Maneuver commands are to be recalculated at each time step. All these computations will be encapsulated in C functions that take the inputs to determine the current value of the commands. The acceleration and braking profiles are encapsulated in these functions, and they can be re-coded by the user.

Table 11.4 Inputs to Atomic Maneuvers

Input

Description

Idriverc

Category of driver

Imaneuverc

Category of maneuver



imaxdistance
itime_out
idesired_lspeed
idesired_lane

Termination conditions:

  • Distance to travel
  • Duration of the maneuver
  • Speed to attain
  • Lane to cross to



Ilspeed

Ixt

Initial error conditions:

  • The maximum tolerable error in the initial longitudinal speed
  • The maximum tolerable error in the distance from the center of the lane



Ixcenter_of_lane
ixvehicle
ispeedl_of_leaderv
iypos_of_leader
icurvature
i_lspeed;

Feedback info:

  • X position of the center of the lane
  • x position of the vehicle
  • longitudinal speed of leader (if any)
  • y position of the leader
  • curvature of the lane
  • longitudinal speed


Table 11.5 Outputs from Atomic Maneuvers

Output

Description

Longspeed

Long acell

Commands to the longitudinal controller

Offset from the lane center

Command to the lateral controller


Table 11. 6 Internal State of Atomic Maneuvers

State

Description

Slenght

Distance traveled

Sduration

Elapsed time


Table 11. 7 Termination Conditions

Condition/event

Enabling condition 
(set to true or false)

slenght >= imaxdistance enlenght
olong_speed >= idesired_lspeed endesired_lspeed
sduration >= itime_out entime_out
Event Reachnextlane enlane
Event Abort -

Plan for Next Six Months

The critical focus will be to continue work on the combined simulation application, extending the user interface to support features desired for TASIM. Specifically, we will:

  1. Develop 2-D GUI

  2. Integrate legacy 3-D visualization

  3. Integrate synchronized video playing into the application, to include GM road test files anticipated to be provided to PATH Oct – Nov 2000

  4. Connect world simulation to threat assessment by way of vehicle sensors

  5. Perform module- and system-level tests.

Testing in particular will be emphasized, with the philosophy of testing from "bottom to top", that is, all modules are tested individually first, then they are tested as part of the system. In the next 6 months, individual models will be tested separately. In doing so, test data for each of the models will be taken from the developer of the model. Alternatively, the tester will suggest test data. In both cases the developer of the model should approve test results in a checklist manner. Further discussion is warranted on the radar detection module testing for several reasons: at this writing it is the furthest along, and it is also a pivotal module within TASIM; its veracity will likely most affect that threat assessment algorithm.

The radar detection module is designed so that it can be tested in two ways: either test the probability of detection for a specific radar cross-section and type of weather, or test the whole radar detection for a specific scenario. The user can choose the target cross-section, the targets fluctuation model, the atmospheric conditions, and turn on or off multipath effects.

The basic radar detection model test plan is for five scenarios, ranging from one target to three targets in 3 lanes. The basis for verification is probability of detection for different cross-sections and different weather conditions per GM data set. Three additional test items supplement the basic test plan: a non-flat road, a sixth scenario (one target on a curved lane) and the sorting of track ID numbers in the target tracker. The target tracker could also be tested in the case of more than 15 targets in the field of view. Additionally, in the target discrimination test, an enhanced test plan could consider the case when the range is more than 2 m and the range rate more than 3 m/s. Also, the merged target could be put back into the oldest index. In the target tracker, the azimuth could be predicted in the case when the targets are not going straight down their lanes.

Figure 11.6 TaskC3A and 5A Schedule, Page 1

Figure 11.6 Task C3A & 5A Schedule, Page 1

 

Figure 11.7 Task C3A and 5A Schedule, Page 2

Figure 11.7 Task C3A & 5A Schedule, Page 2

11.2 Threat Assessment In-Vehicle Development (Task C3B and 5B)

Objectives

The objectives of these tasks are to:

  1. Develop threat assessment algorithms through analysis and simulation

  2. Test the threat assessment algorithms in an instrumented vehicle on test tracks and real traffic

  3. Coordinate the implementation of the NHTSA Algorithm on the GM EDV and Prototype vehicles.

Approach

The usefulness of the driver alert warning depends on the robustness of the threat assessment algorithm. The threat assessment algorithm must determine the probability of a collision with a vehicular target that is in the forward path of motion of the Host vehicle. This estimation is determined from the Host vehicle’s and target’s velocity and deceleration, the distance between the vehicle and object, and the driver’s reaction time. The time of collision could be determined from these parameters if these parameters were deterministic. However, in real-world traffic scenarios, these parameters are confounded by multiple traffic lanes, roadway curvature, multiple vehicles, roadside obstacles, and driver attentiveness and reaction times. Because of these non-deterministic occurrences, modeling techniques must be developed to assist in the selection of the algorithm or algorithms with the highest chance of success. Several iterations of algorithm candidates will have to be simulated and analyzed.

The threat assessment algorithms will be integrated into a project vehicle for real-time evaluation and assessment. This project vehicle will be driven in various traffic conditions and on test track situations, which simulate potential crash situations, to determine hit and nuisance rates for the various combinations of threat and path prediction algorithms. Six threat algorithms will be evaluated with each of the path prediction methods (e.g., conventional approach, scene tracking approach, vision sensor, and enhanced GPS approach). The six candidate algorithms are called GMR1, GMR2, NHTSA, CAMP, HW and TTC.

To measure the driver’s vigilance, selective subsystems of the instrument panel (e.g., windshield wiper control, HVAC & radio adjustments, etc.) will be monitored and used to further enhance the threat assessment processing by attempting to anticipate the attentiveness and potential reaction time to an imminent alert. For example, application of the windshield wipers would suggest rain, and adjustment of the radio would suggest momentary inattention/distraction of the driver. In these two cases, additional warning time might be provided to compensate for slippery roadway or slower driver reaction time.

Since these parameters are non-deterministic for the future state, only an estimate of a collision event can be provided. The algorithm development of the threat assessment process was initiated during the ACAS program. Further development of these threat assessment algorithms will continue based on the findings initiated during the ACAS Program. These algorithms will be evaluated in the collision warning simulation tool and project vehicles. They will be evaluated for collision warning usefulness and for nuisance alert potential. As previously discussed, minimization of nuisance alerts is paramount to the successful acceptance of this warning approach. Based on previous experience, many modeling, simulation, analysis, and vehicle test iterations will be required to obtain an alert system robust enough for field operation test drivers.

The algorithm development team will collaborate with the other subsystem development teams in order to provide both algorithm performance refinements and subsystem integration capabilities during the integration phase of the program. Additionally, this team will provide the appropriate support required to address any CW system anomalies experienced during the FOT phase.

Milestones and Deliverables

A joint Team/NHTSA collaborative meeting was conducted in order to develop a detailed work plan for securing access to relevant Government-sponsored studies/data.

Work Accomplished

The following threat assessment activities have been accomplished in the last year:

  1. Characterization and first delivery of GM R&D Algorithms 1 and 2

  2. Received Time to Collision and Time Headway Algorithms from GM

  3. Have provided in software provisions for CAMP and NHTSA Algorithms

  4. Hosted four of six algorithms (GMR1, CAMP, HW and TTC) on FCW Processor

  5. Provided support for NHTSA Algorithm implementation

  6. Started development of algorithm MOE’s

  7. Made significant progress on FCW Simulation

  8. Have almost completed GM EDV Hardware and Software

Research Findings

Research findings to date have been primarily in the areas of analytical development. Once completed, these results will be implemented in the simulation described in Section 11.1 and the vehicles described in Section 13. The following describes a summary of the GM Research threat assessment algorithm that is being readied for simulator and vehicle testing.

Threat Assessment Description

The I/O data to/from Threat Assessment are taken from and put onto the CAN bus by the system modules. The Threat Assessment process is as follows:

  1. Target Selection inputs, to the FCW Processor (via the CAN bus), certain radar track data of selected radar track with the following criteria:

    1. The closest in-path moving vehicle (CIPV)

    2. The closest in-path stationary object (CIPS)

    3. All moving vehicles that are projected to enter the host vehicle’s path (PIHP)

  2. The FCW Processor collects (for the Threat Assessment Algorithms) the required radar track data (see Table 11.8) sent over by Target Selection, from the CAN bus.

  3. The FCW Processor also collects the other required Threat Assessment input data (see Table 11.9), from other modules, from the CAN bus.

  4. Threat Assessment then calculates an Alert Level and determines other messages (see table 11.10). The FCW Processor outputs this data to the CAN bus.

Table 11.8 Radar Track Data

 

Alert Parameter Source

a.

Radar Track ID, Radar Scan Number, Range, Relative Range Rate, and Relative Acceleration of the closest in-path moving target (CIPV)

Target Selection

b.

Radar Track ID, Radar Scan Number, Range, Relative Range Rate, and Relative Acceleration of the closest in-path stationary target (CIPS)

Target Selection

c.

Radar Track ID, Radar Scan Number, Range, Relative Range Rate, Relative Acceleration, Lateral Offset, and Lateral Offset Rate of all target projected to be in the host vehicle path in the near future (PIHP)

Target Selection


Table 11.9 Threat Assessment Input Data

 

Alert Parameter Source

a.

Following (host) vehicle speed

Class 2 bus

b.

Following (host) longitudinal acceleration

Vehicle sensors

c.

Required following vehicle acceleration

ACC Controller

d.

Distraction Level

Data Fusion

e.

Road Surface Condition

Data Fusion

f.

Rain Rate

Data Fusion

g.

Brake Applied

Vehicle sensors

h.

ACC On/Off

DVI

i.

FCW Sensitivity/

DVI


Table 11.10 FCW Processor Output Data

 

FCW Output Message

a.

Alert Level: a number between 0 and 1 which results in an indication to the driver of the potential for a rear-end collision with the most threatening (CIPV, CIPS, or PIHP) vehicle

Max_AL

b.

Indicates alert being inhibited

FCW_Inactive

c.

Indicates that Threat Assessment is limited by operational or environmental factors

System_Limitation

d.

Indicates that the FCW Processor is not operational

FCW_Fault

Figure 11.8 below defines the terms in the discussions to follow.

Figure 11.8 Definition of Threat Assessment Algorithm Terms

Vf = Following Vehicle velocity

af = Following Vehicle acceleration

Vl = Lead Vehicle velocity = Vf + Rdot

al = Lead Vehicle acceleration

T = delay time (before Following Vehicle starts to decelerate after Lead Vehicle starts to decelerate (at t = 0)

R = range (measured by the radar) between Lead and Following Vehicle

Rdot = relative range rate (measured by the radar) between Lead and Following Vehicle

Rca = collision avoidance range

Figure 11.8 Definition of Threat Assessment Algorithm Terms

The collision avoidance range, Rca is the closest possible range that a driver can make a decision to stop, using the normal equations of motion, and still avoid a collision for parameters Vf, Vl, al, af and T. These parameters may be measured, assumed or a combination of measured or assumed values.

Rca = f(Vf, Vl, al, af,T)

where

Vf = is a measurement from vehicle sensors

Vl = Vf + R_rate

af = g(a + bVf)

g = f(Road_Surface)

al = -0.2 g for ar > -0.4g

al = af_m + ar for ar < -0.4g

T = f(Distraction)

The alert onset range Ro is determined as follows.

Ro = Rca + (Vf - Vl)(n-1)t

where

n = number of alert levels

t = time between alert level changes

However, when Vf - Vl <  1.12 m/s,

Ro = Vf  Th

where

Th = the desired time headway

The first expression for Ro is used for the case when the following vehicle is closing on the lead vehicle (algorithm 1). The second expression for Ro is used for the case when the following vehicle is "tail-gating" the lead vehicle at the same speed (algorithm 2). Algorithm 2 is automatically selected when Vf - Vl is less than 1.12 m/s.

The Alert Level, AL, is a number between 0 and 1 that is output to the Driver-Vehicle Interface. AL is an indicator to the driver of the potential for a rear-end collision, and is intended to drive a gradient display.

ALi = 0, for (R > Ro) or (Vl > Vf)

formula graphicfor Rc ³ R ³ Rca

ALi = 1, for R < Rca

The above concepts form the basis of the GM R&D threat assessment algorithm.

Target Projected to be in Host Vehicle Path

When Target Selection determines that a vehicle is changing lanes and will be in the host vehicle’s path in the future, Threat Assessment must use the projected range of the lead vehicle to calculate the Alert Level. Figure 11.9 below shows the geometry and definition of terms for a lead vehicle changing lanes into the following vehicle’s path.

Figure 11.9 Geometry and Definition of Terms for the PIHP Vehicle

Figure 11.9 Geometry and Definition of Terms for the PIHP Vehicle

Target Selection provides the offset X and offset rate Xdot to the threat assessment algorithm as seen in Figure 11.10.

Target Selection provides
R, Rdot, X and Xdot
for PIHP tracks

Figure 11.10 Offset X and Offset Rate Xdot

Figure 11.10 Offset X and Offset Rate Xdot

The time for path crossing, tc is determined from X and Xdot as shown in Figure 11.11. From tc and other known lead and following vehicle data, the projected range Rp is calculated. Rp is used in place of R in the threat assessment algorithm.

Figure 11.11 Determination of tc and Rp

Figure 11.11 Determination of tc and Rp


Alert Characterization

The following two scenarios illustrate how the alert algorithm would perform. Algorithm parameters have not yet been optimized. This will wait until the CW Simulation is available. Table 11.10 shows various vehicle parameters vs. time.

In Scenario 1, the following and lead vehicles are traveling at constant speeds of 70 and 60 mph respectfully. It is assumed that the following vehicle does not brake. Algorithm 1 is always in effect because Vf – Vl is always above 1.12 m/s. The last three columns of Table 11.11 shows the algorithm used, the brake status and the alert level vs. time. Figures 11.12 and 11.13 below show graphically the information in Table 11.11.

Table 11.11 Scenario 1

Table 11.11 Scenario 1

 

Figure 11.12 Scenario 1 Shown Graphically

Figure 11.12 Scenario 1 Shown Graphically

 

Figure 11.13 Scenario 1 Output Alert Level

Figure 11.13 Scenario 1 Output Alert Level

In Scenario 2, the following and lead vehicles are initially traveling at constant speeds of 70 and 60 mph respectfully. But as soon as the Alert Level exceeds 0.3, the following vehicle brakes until Vf = Vl. Algorithm 2 is in effect as soon as Vf – Vl is below 1.12 m/s. The last three columns of Table 11.12 shows the algorithm used, the brake status and the alert level vs. time. Figures 11.14 and 11.15 below show graphically the information in Table 11.12.

Table 11.12 Scenario 2

Table 11.12 Scenario 2

 

Figure 11.14 Scenario 2 Shown Graphically

Figure 11.14 Scenario 2 Shown Graphically

 

Figure 11.15 Scenario 2 Output Alert Level

Figure 11.15 Scenario 2 Output Alert Level

Plans through December 2000

  1. Optimize choice of Algorithm Parameters by analysis, simulation, and in-vehicle tests.

  2. Develop MOE’s for judging alternate Threat Assessment Algorithms.

  3. Start in-vehicle testing.

Figure 11.16 Task C3B and 5B Schedule

Figure 11.16 Task C3B & 5B Schedule


[TITLE PAGE]      [TABLE OF CONTENTS]
[1 Executive Summary]     [2 Introduction]     [3 System Integration]     [4 Forward Radar Sensor]
[5 Forward Vision Sensor]     [6 Brake Control System]     [7 Throttle Control System]
[8 Driver-Vehicle Interface]      [9 Data Fusion]     [10 Tracking & Identification]     [11 CW Function]   
 [12 ACC Function]     [13 Fleet Vehicle Build]      [14 Field Operational Test]
[Appendix A]     [Acronyms]