VII California Team Meeting - PowerPoint PPT Presentation


PPT – VII California Team Meeting PowerPoint presentation | free to view - id: c22cd-NjFlM


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

VII California Team Meeting


VII California Team Meeting – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 53
Provided by: Misener
Tags: vii | california | meeting | team | ube


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: VII California Team Meeting

VII California Team Meeting
  • November 2, 2006
  • Metropolitan Transportation Commission

  • Emerging Research Results
  • Fused Detection
  • Curve Overspeed
  • RSE Status
  • Intersection Sniffer
  • Backhaul - T1, 3G, WiMax
  • WiFi
  • APTA Demo and Beyond
  • ITS America Demo

Emerging Research Results
Fused Traffic Detection for Arterials
  • Fuse traffic detection data
  • Loop detector data (count, occupancy)
  • Traffic signal status data (phase duration, phase
    interval, pedestrian calls)
  • VII probe vehicle data (speed, travel time,
  • Other data (e.g. toll tag)
  • Measure arterial performance
  • Travel time
  • Queue length
  • Intersection delay
  • Number of vehicle stops

Existing Data Fusion Approach
  • Artificial neural network (ANN)
  • Pro capable of giving correct result in the
    presence of noisy or missing data
  • Con ANN is not a systematical approach, so the
    results rely on model training
  • Score ranking for different sources and pick up
    the best
  • Primarily rely on loop detector data and use
    probe vehicle data as enhancements
  • Statistic approach (Dempster-Shafer evidence

Work Plan
  • Model development
  • Development of models to pre-process raw data
  • Data fusion
  • Approach I VII probe data for model calibration

VII probe data
Calculated travel time
Loop detector data
Model calibration
Predicted travel time
Predicted travel time
Signal status data
Other data
Calculated travel time
Work Plan (cont.)
  • Approach II ANN
  • Model evaluation
  • Simulation analysis
  • Field data analysis

Loop detector data
Predicted travel time
Signal status data
VII probe data
Calculated travel time
Predicted travel time
Other Data
Calculated travel time
Simulation Analysis Plan
  • Get familiar with VISSIM
  • Simulation environment
  • Network construction
  • Simulation functions
  • Programming interface
  • Component Object Model (COM)
  • Data collection module
  • Signal control module

Simulation Analysis Plan
  • Data collection
  • Loop detector data
  • Signal status data
  • VII probe vehicle data
  • Other data
  • Coding the pre-process models using API
  • Evaluation of pre-process models
  • Coding and evaluation of two data fusion

Progress To Date
  • Model development based on loop and signal status
  • Constructing simulation network in VISSIM (El
    Camino Real in Palo Alto)
  • Warm-up on simulation API
  • Simulation parameters control
  • Automatic vehicle travel time capture
  • Average travel time statistics for selective
  • Simple display interface
  • Adjustment of probe vehicle penetration rate

Progress To Date
Curve Overspeed Warning
Review of Curve Over-Speed Warning Research
  • Map data extraction for developing application
  • Dynamic road curvature estimation using digital
    map data.
  • OBU sensor configuration and sensor data fusion.
  • Warning algorithm design.

  • Progress
  • Conventional Spline approach is not favorable for
    our application due to accuracy and robustness
  • We have come up with a new approach -
    Circle-Center Searching algorithm to address the
    two problems.
  • New approach has been tested on three types of
  • Arc
  • Circle
  • S-Curve
  • Specify on-board sensors (sent to Toyota ITC and
  • On-Going Work
  • Setting up the 1st OBU at PATH
  • Extract more map data to validate our new
    curvature estimation algorithm
  • Conduct preliminary field tests for warning
    algorithm development with Toyota and VW

Why is Spline approach unfavorable?
Circle-Center Searching Algorithm
  • Concept
  • Geometrically, vehicles trajectory is consisted
    of moving circles.
  • Road can be modeled by combination of circles
  • Method
  • Treat road as circles
  • Pre-estimate radius and circle center location
  • Determine center location, radius, and curve type
  • Adaptively estimates of radius and curvature
  • Reiterate if required
  • Advantage
  • Simple computation
  • Accurate
  • Robust

Spline Approach vs. Circle-Center Searching
(Part of Bayview Ave).
Circle-Center Searching Approach (New)
Our new approach is able to (1) achieve more
accurate and stable curvature estimates (2)
locate the center of turning radius and (3)
detect the change of curvature.
Example 1 Arc with Curvature Change Curve on
Bayview Ave.
Verified by Google Earth and test drive.
Example 2 Circle On-Ramp from Marsh Rd. to SB101
Verified by Google Earth
Example 3 S-Curve Off-Ramp from SB101 to Marsh
On-Going Work
  • Extract more map data of highway ramps to
    validate our new curvature estimation algorithm.
  • Conduct preliminary field tests for warning
    algorithm development.
  • Refine vehicle dynamics analysis and include more
    complex road attributes.
  • One GPS test at PATH
  • Setup a RSU at PATH for preliminary tests.

10 1 RSUs
  • 5th and El Camino Real in Atherton
  • Site was surveyed by Daimler-Chrysler, Caltrans,
    and PATH few weeks ago
  • New RSU design (Technocom) using WIFI instead of
  • RSU sits inside a weather proof enclosure outside
    the cabinet attached to the vertical signal pole
  • WRM antenna on the mast arm
  • Backhaul ????
  • Final design must be approved by Caltrans before
    installation (by both Mr. Price and Mr. Chiu)
  • Possibly in direct line of site to one of WiMax
    antennas set up for Caltrain (by Intel)

(No Transcript)
(No Transcript)
VII in California
  • Procurement
  • Cost Minimization (Borrow?, Steal?, Donation?)
  • Charged to the existing VII contract
  • Coordination
  • D4 and the rest of the gang
  • Installation (5th and El Camino Real)
  • Field inspection
  • Final Installation

Development ActivitiesSniffer Broadcast
Signal Phase and Intersection Message Set
  • Signal sniffer hardware and intersection message
    set broadcast software development
  • APTA
  • PATH_at_20
  • Broadcast software
  • originally developed using messages sent over
    Ethernet from the Econolite controller
  • Adapted to use signal phase information from
  • NTCIP and AB3418 protocols
  • Sniffer
  • Future changes require message formatting code to
    be well-separated from the details of phase
  • e.g., separating dynamic signal phase tracking
    information from static geographical information.

Signal Sniffer Block Diagram
See next slide for whats in this block
The GREEN signal for each approach is being
sensed by the sniffer circuits that we have
installed so far.
PATH Signal Phase Tracking and Broadcast Software
Block Diagram
Alternative software modules provide uniform
interface to phase tracker.
Separate module formats message and controls
broadcast frequency.
Tracks count-down based on timing plan and
dynamic signal phase inputs
Digital I/O from sniffer circuit
Phase Tracking Module
170 or 2070 Serial Port
Configuration files with timing plan and
geographic (approach and stop line) information
Currently broadcast as UDP message over Denso WRM
Intersection Message Broadcast tested with
sniffer at two locations
  • Page Mill/El Camino
  • actuated/coordinated
  • Richmond Field Station
  • fixed timing

Sniffer testing so far
  • Performance
  • Reliable, with minimal delay in reporting signal
    state changes
  • Broadcasts accurate countdown for yellow period,
    as planned.
  • At Page Mill/El Camino actuated coordinated
    intersection, best effort broadcasts based on
    timing plan for red and green periods shows some
    ending a few seconds earlier than predicted, some
    lasting a few seconds longer.

Issues raised during sniffer testing at RFS
  • Broadcasts of 10 messages per second caused the
    application to show increasing delays, while
    broadcasts at 5 messages per second were fine
  • Could be due to interference from other traffic
    at sending RSU
  • Could be due to overload from on-board
    applications on Windows
  • Requires further investigation
  • Observed clock jitter
  • On the order of hundreds of milliseconds over the
    course of a 45 second phase was observed between
    the PC104 doing the phase tracking and the 2070
    signal controller
  • clock corrections important, through GPS or other

Intersection Message Broadcast Work in Progress
  • Intersection Message Set send/receive testing
    software made available to partners this week
  • 2070 with Caltrans Traffic Signal Control Program
    (TSCP) delivered to PATH last week for AB3418
    protocol work
  • Need to determine by testing with serial port to
    Linux PC104 how fast status can be reported
  • Need to discuss contents of LongStatus8 message
    with car company partners to see if any fields
    ought to be added to the intersection message set
  • Need to investigate hardware to forward serial
    port information over wireless IP to Technocom
  • NTCIP code that runs on QNX and communicate with
    Siemens 2070 software needs to be ported to Linux
    and compared directly with sniffer performance

Backhaul T1
We have requested T1 installations at 2 remaining
sites. One is through SpeakEasy and one with ATT.
  • Marsh/US 101 (Menlo Park)
  • Route 85/US 101 (Mountain View)

Lessons Learned The cabinet location/addresses
are nearly impossible to use for determining the
existing circuits that lead into the cabinets.
Backhaul - 3G
9 Verizon Raven-E Modems have been deployed.
The AirCard 875 is about to be delivered and is
supposed to provide up to 3.6 Mbps download.
Backhaul - WiMAX
Vince was able to review the candidate sites that
you sent.  There are a few likely candidates.  He
is actually in the area all week so plans on
doing a site survey of these sites to determine
feasibility.  I will let you know what he comes
back with
WiFi for VII CA?
  • 1 SC-101-397 101 Santa Clara South Airport
  • 2 SC-101-522 101 Santa Clara North Oregon/Embarcad
  • 3 SM-101-112 101 San Mateo North Hillsdale
  • 4 SC-101-332 101 Santa Clara North Tully
  • 5 SM-101-187 101 San Mateo South SFO Terminal
  • 6 SC-280-156 280 Santa Clara North El Monte
  • 7 SC-280-18 280 Santa Clara North 10th Street
  • 8 SM-101-262 101 San Mateo North Harney Way
  • Two Tracks
  • Eight Dash (Circum Nav) WiFi Fixed Access Points
  • Build Two Additional WiFi RSE Near San Antonio /

Initial WiFi RSE Design
  • Next Steps
  • Coordinate Backhaul
  • Schedule D4 Review
  • Build / Test
  • Schedule Installation _at_ Two TBD Sites
  • Questions
  • Would OEMs Develop Applications and Use?
  • Overcome by Events? (Dash WiFi RSU)

APTA Demo and Beyond
VII Transit Demo
  • October 9th Fuel Problem
  • VII Functions Developed
  • Travel time and incident updates
  • Sniffer demo at El Camino and Pagemill
  • Caltrain schedule display near Caltrain station
  • information transmitted via wireless
    internet into bus

APTA Demo and Beyond
  • Probe/travel time application worked in demos
  • However, was limited to predefined OD pair
  • No GPS, so vehicle and server assume travel is
    between predefined RSU origin and destination
  • But, we can encode GPS in beacon message
  • For now, data comes from google maps
  • App works for any RSU OD pair (or sequence)
  • Generates travel time message for the origin RSU
  • Can run demos without extra preparation
  • Also works if car does have GPS

Probe Details
  • Sample C code in the c-api download
  • probe-vehicle.c
  • Can use viicatl executable
  • probe-vehicle and probe-server modes
  • Probe server is at
  • path.berkeley.edu10080
  • Vehicle code selects probe server by ipaddr
  • Suggestion for new device status (in snapshot)
  • field name GPS status
  • field value number of satellites (no GPS gt 0)

Temporary Signage Messages
  • We now have a telnet interface
  • Allows you to add signage messages interactively
  • Easy to read text format
  • Quick-and-dirty alternative to writing a signage
    generator using the VII-CA binary format
  • You can specify
  • Metadata rsu ID, message ID, expiration
  • Data text, sounds, driving time, destination,
  • Message is at RSU within 1 minute

Sample data entry
  • event_type 38
  • event_subtype 0
  • longitude 0.0
  • latitude 0.0
  • heading 0.0
  • distance 0.0
  • start_time 315 AM, October 25, 2006
  • end_time Thurs, Oct 26, 2006, 1800 UTC
  • link_speed 65
  • truck_speed 55
  • speed_limit_road_name US-101
  • destination_name San Jose
  • driving_time 0
  • text Your message here!
  • sounds foo.wav,bar.wav,baz.wav

Temporary Signage Details
  • Telnet server is at
  • path.berkeley.edu10081
  • Not the same as the PATH signage server
  • Contact us for password
  • Tell us your IP address (for firewall)
  • Documentation is printed at start of session
  • Each partner group has its own namespace
  • No conflicts between partners
  • But signage is visible to all users

ITSA and VII California
  • VII Pavilion has accompanying demos
  • VII California has reserved a space
  • Demo concept
  • Travel time with mobile RSE / in-vehicle signage
  • TBD vehicle platform for OBE
  • TBD probe and data source concept
  • TBD whether to implement RSE on Caltrans ROW
  • Issues
  • Need to scout location
  • Someone gets to travel to Palm Springs!
  • Palm Springs in the Summer (4 6 June 07)
  • Hot for people, hot for equipment
  • Distance and environment means travel for week(s)
    x people
  • Weekly coordination telecons have begun (Tues, 9
    10 am) and need staffing
  • Questions
  • If / who / what / how to do this demo?