1

Intersection Decision Support: A Cooperative Approach

Summary of California PATH / UC Berkeley IDS Approach

2

Outline

• Background• California Approach

– Work Plan– IDS Architecture

• Underpins California Concept of Operations

– Integrating the Driver• Aimed at IDS Alert System Design

– Alert System Design– Approach to Cooperative Systems

3

Background

4

Driver Decision Support Concept

• Emphasis on crossing-path collisions (both signalized and unsignalized)– 80% of intersection crashes (1998 GES)

• Concept and architecture accommodate other intersection crash types

• Find “best” combinations of vehicle and infrastructure responsibilities for diverse intersections

5

California Areas of Interest

• LTAP/OD conflicts at signals (permissive, not protected)

• LTAP/LD conflicts at urban stop signs• Development of broad system architecture

applicable to all intersection crash types, using information from infrastructure and/or vehicles

• Development of wireless communications to connect infrastructure and vehicles

• Pedestrian and bicyclist conflicts

6

California’s Primary Focus Area: LTAP/OD

• Features of California LTAP/OD Approach– Problem is gap decision in presence of oncoming

vehicles– For all traffic control devices: signal, stop sign, no

controls– High potential for initial infrastructure-based warning

application (“Driver Infrastructure Interface”, DII)• Takes advantage of left turn dynamics

– If designed correctly, DII for left turn driver is unambiguous• DII located at far side corner, where driver is likely to scan

– Cooperative (wireless) systems should enhance system

7

Definition: Left Turn Across Path / Opposite Direction (LTAP/OD)

8

Principal Expected Products

• Quantitative characterizations of intersection safety problems and turning behavior at intersections

• Recommended designs for infrastructure elements and systems (sensors and their locations, algorithms to use sensor outputs to alert drivers, and displays)

• Estimates of effectiveness of IDS in reducing intersection crashes

• Plans for public operational test(s) at selected intersections

9

California Approach

10

Schematic of California Approach

Design IDS Alert System

Characterize Intersection Driving• Roadside Observations• Driver Observations

Evaluate COTS Technologies

Develop Simulation Tool

Develop Wireless CommunicationSystem

Develop DII

Driving ExperimentsAt RFS Intersection

Implement RFSTest Intersection

11

Task List and Status (1 of 2)

• Completed Tasks:– A. Problem Assessment

• Deliverables: Problem Assessment Reports– M. Mid-term demonstration

• Deliverable: Year 1 Report (in process)• Current Tasks:

– B. Characterize Intersection Driving• Deliverables: Pilot Feasibility Study, Extended Observation

Study, Field Collection, Lag Acceptance Reports (early 05)– C. Wireless Communication Development

• Deliverables: Protocol Design Report (July 04), Communication Prototype and Performance Analysis Report (early 05)

– D. Driver-Infrastructure-Interface Usability• Deliverables: DII Usability Report (early 05), DII

Alternatives Report (early 05)– E. Develop Warning System

• Deliverable: Warning System (early 05)

12

Task List and Status (2 of 2)

• Current Tasks (Cont’d)– S1. Develop Simulation Tool

• Deliverables: Tool (Nov 04)

– S2. Evaluate COTS Technologies• Deliverables: COTS System Downselect (Sep 04),

Test Reports (Sep 04 – early 05)

• Future Tasks– F. Countermeasure Trade-off Analysis

• Deliverables: Sensor Fusion Report (Oct 04), Report to Compare Countermeasures (early 05)

– G. Pilot FOT Planning• Deliverable: Final Report with FOT Plan (early 05)

13

IDS Architecture

14

StateMap-based Architecture

Other

Conflict predictor

State Map Generator

Gap predictorStop predictor

Safety applications

State map

Car GPS

Loops

Lidar/Radar

Sensors

Comm.

15

Diverse IDS Implementations

Data Sources:

Information toDrivers:

Infrastructure Vehicle

LoopDetectors

VideoDetectors

Radar In-vehiclesensors

IDS Logic:-Analyze vehicle motions-Predict future gaps, conflicts or violations-Decide to issue alert

DynamicSign

SignalController

In-vehicledisplay

(wireless)

(wireless)

16

DII

2070 Controller

Loops (11)EVT-300 (2) DensoLIDAR (2)

Wireless Modem

Serial Serial

Digital HI/LO

Implementation at TFHRC(1 of 3)

Fixed (Infrastructure) Sensors

Ethernet

QNX6 Computer

(Sensor Fusion, Warning, and Tracking Algorithms)

Serial

Controller Cabinets

17

Implementation at TFHRC (2 of 2)

2070 contr.

Ethernet

QNX 6.0 computer(Sensor fusion, safety IDS algorithms)

Eth. card RS232

Sensors

I/O card

DII

Wireless 802.11aPCMCIA / PCI

card

infrastructure

vehicles

QNX 6.0 computer(State map visualizer)

Wireless 802.11aPCMCIA / PCI card

802.11a safety enhanced (more DSRC like)

18

PATH RFS Test Intersection

Traffic Controller Cabinet

60 Meters of 3M Microloops

Embedded Loop Detectors

Signal Poles

RadarPoles

19

Implementation at the PATH Intelligent Intersection

20

Elements of Cooperative System at the PATH Intelligent Intersection

• 40-ft Bus at PATH/RFS– DVI at driver console,

with identical display for passengers

– Wireless implementation of simultaneous DII and DVI

• In practice, need not be simultaneous – a tricky research item

– Demonstrated to Barbara Sisson Associate Administrator for Research, FTA

21

‘State Map’ of Intersection at ControllerWe know the status of every

communicating entity

SV Radar State

DII

Detected SV Speed (m/s)

SV Wireless Communication State

Detected POV D2I (m)

POV Radar State

Detected POV Speed (m/s)

POV Wireless Communication State

Total number of vehicles detected by SV and POV radars

In pavement loops

22

Integrating the Driver IDS Alert System

23

Perception - Difficulty Estimating Speed(Staplin, 1995)

10 50 100 150 200

30 mph

60 mph

132 m 4.96 s

80 m 3 s

184 m 6.91 s

158 m 5.93s

125 m 4.69 s

191 m 7.18 s

166 m 12.5s

104 m 7.8 s

228 m 17 s

161m 6s

108 m 4 s

214 m 8 s

100 m 7.5 s

51 m 3.8 s

149 m 11.2 s

150 m 11.7s

106 m 7.9 s

206 m 15.4 s

Age 20-53

Age 56-72

Age 75-91

24

Observations and Experiments (1 of 3)

• Three Driver Experiments

1. Downtown Berkeley (ongoing)• Microscopic: 0.075-sec resolution

• Over 400 intersection traverses

• Defining key waypoints

2. Experimental Intersection: D2I vs T2I

3. Experimental Intersection: How well does our warning system / nominal DII work?

25

Parameter Definitions

Crossing time

Turning time

Waiting time

26

Observations and Experiments (2 of 3)

• Characterizing Driver Behavior at Intersections

– Four sites• Two in Berkeley• Pinole• Burlingame (near SFO)• San Francisco

– Two approaches• Roadside • In-Vehicle

– At least three warning algorithm approaches

• Dynamic (Shladover)• “BMI-based”/Statistical

(Ragland)• Neural net (Misener)

– Transcends LTAP/OD

27

Observations and Experiments (3 of 3)Driver Infrastructure Interface (DII)

• Depth: “Looming Circle” DII further investigated– Our nominal DII

• Breadth: Based on CTCDC preparations and recommendations from committee, alternate DIIs to be considered

Looming Circle Looming Circle Looming Triangle Growing Arrow Looming Car

28

Instrumented Ford Taurus for Driving Data Collection

• Wireless connection from laptop to PC104 in traffic signal control cabinet

• Intended Field data collection and controlled tests at RFS

29

Output: Inputs to Alert System Design• Roadside observations (by radar and video):

– SV turning times– POV speed distribution– Accepted and rejected turning gaps– SV/POV speed change interactions– Behavior changes based on signal phase– Interactions with pedestrians

• Instrumented vehicle field tests:– Detailed SV speed-based information– Timing of turning decision

• Waypoints within turning movement (e.g., decision point, waiting time turning time)

– Influence of driver age and gender on turning behavior

30

IDS Alert System Design

31

Central Role of Alert System Design

Design IDS Alert System

Characterize Intersection Driving• Roadside Observations• Driver Observations

Evaluate COTS Technologies

Develop Simulation Tool

Develop Wireless CommunicationSystem

Develop DII

Driving ExperimentsAt RFS Intersection

Implement RFSTest Intersection

32

Alert System Requirements

• Very low false negatives – consistently alert to hazardous conditions

• Low false positives – avoid alerting under benign conditions

• Appropriate timing of alert onset• Do as well as possible with imperfect sensor

data• …while recognizing inherent limitations:

– Subjective judgments of gap suitability– Diversity of driving population preferences

33

Single LTAP/OD Encounter

SV

“Leading Buffer time” after POV1, ahead of SV

“Trailing Buffer time” after SV, ahead of POV2

POV1POV2SV

34

LTAP/OD Alert Design Goals

• When an SV may be planning to make a left turn (in LT pocket or left lane, if no pocket):– Provide alert for gaps in POV traffic shorter than

minimum “safe” threshold– Don’t alert if POV gap is longer than acceptable

threshold (avoid nuisance alerts)– Time the alert to be early enough for SV driver to

be able to make a comfortable “no turn” decision, but not so early that it could be perceived a nuisance.

• First define alert design assuming complete and accurate sensor data, then adjust for imperfect data

35

Nominal Alert Triggering Approach

• Develop for middle of green phase, then adjust for other conditions

• Anticipate when SV will enter dangerous region (in path of POVs), and how long it will need to clear that region

• Define acceptable time gap in approaching POV traffic after SV will clear intersection (“Trailing Buffer” time values based on field measurements and driver experiments, initial estimate ~ 3 s)

• Apply hysteresis in acceptable gap times to avoid chatter – Tgaplow and Tgaphigh, initially separated by 1 s (final value to depend on sensor and data fusion capabilities).

36

Alert Development Process

• Define alert criteria, considering “all” expected combinations of conditions– Based on information from observation studies

(roadside and in-vehicle)– Adjustments for diverse intersection conditions

• Test alert criteria in simulation under challenging conditions, then adjust as necessary– POV speed changes (dilemma zone decel. and

accel., decel. to turn)– Range of approach speeds– Range of relative arrival times of SV, POV

• Test sensor alternatives to compare to “perfect” sensor information

37

Sensor Coverage Alternatives

Standard loops at stop bar

Alt. 1

Single loop detector Double loop detector

Alt. 2

Radar coverage zone

Alt. 3

Alt. 4

Alt. 5

Double loop detector

Alt. 6

38

General Findings on Alert Design and Detection Needs

• Complex interactions between SV and POV speeds need to be evaluated in multiple cases

• Early enough detection of POV is essential (6 seconds before stop bar)

• Use of final four loops at SV stop bar is crucial for determining SV speed in difficult cases

• Alerts depend on accurate speed as well as presence information

• POV speed changes close to intersection are not as important as SV speed changes

39

Importance of Accurate Speed Measurements

• If assumed speed is below true speed, alerts will be late or missed completely

• The larger the speed difference (faster vehicles), the higher the likelihood of a problem– Also the most important cases for issuing

alerts (driver misperception of closing speed and severe consequences of crash)

• If assumed speed is above true speed, false alarms become more likely

• Variance of distribution of approaching speeds governs the importance of this

40

Alert System Design Challenges

• Address complexity of SV-POV interactions• Accommodate diversity of driver preferences

within one set of alert criteria• Customize to fit differing requirements of

diverse intersections• Implement with affordable sensor suite

– Tracking individual vehicle positions and speeds, with multiple POVs

– Covering center of intersection as well as approach legs

41

InfrastructureVehicle

IDS

Infrastructure based sensors

Traffic sign. contr.

Traffic sign. manag.

Traffic Signal

Inputs •Infrastructure state information (e.g. intersection type, signal state, etc);• Vehicles state information (e.g. speed, position, etc);

DII manager

Drivers

Signal controller

OutputDriver Interfaces

State Map Generator

Predictors

Future State Predictor

State map

Future State

Gap predictor Stop predictor Conflict predictor

In-vehicle sensors

In-vehicle display devices

42

Cooperative System Opportunities

• Data from vehicles to intersection to improve IDS operation:– Longer-range (earlier) information– Acceleration to improve threat estimate– More accurate approach speed information– Enhanced weather or road surface status

• Data from intersection to vehicles:– IDS alert status for in-vehicle display– Information about approaching vehicle

threats not visible to vehicle sensors– Enhanced weather or road surface status

44

Cooperative System Development Activities

• Define message sets needed for IDS applications, leaving flexibility for alternative implementations– Infrastructure-centered intelligence– Vehicle-centered intelligence– Lane – level accuracy maps

• Communication protocol design • Test wireless communication of these

message sets using 802.11a and DSRC test kits

• Fusion of intersection and vehicle sensor data

45

Communication Needs Summary

• Vehicle broadcast message set per current SAE work, 42 byte payload and 70 byte overhead

• Assume (order of magnitude) 100 ms update interval

• Range of 300 m for higher-speed rural and 150 m for lower-speed urban environments

• Jam density could approach 600 vehicles within intersection range

• Accommodating 600 vehicles within DSRC safety channel (3 -- 27 Mbps) requires coordination in MAC protocol