### Future work

PATH plans to utilize the data collected through the verification tests
to develop sensor fusion approaches and improve the tracking and warning
algorithms in order to achieve better measurement/estimation and system
performance.

###   {#section .unnumbered}

# Transit CWS Simulator {#transit-cws-simulator .unnumbered}

As professional bus operators experience potential collision situations
very rarely, it can be difficult to gather enough data to evaluate a
systems performance. It is however, possible through the use of a bus
simulator to present large numbers of drivers with potential collision
situations in a much shorter period of time than drivers would normally
encounter in daily driving. Such potential collision scenarios can be
recreations of actual accidents or a composite of hazardous factors.
Another advantage of a simulator is that it is possible to have a pool
of drivers all experience identical situations to see how drivers'
behaviors to the same incident differs. Lastly, a simulator allows
drivers to be put in potentially hazardous situations without any risk
to life.

We are planning to use the FAAC simulator at SamTrans to conduct further
study into the collision warning system. It will be possible to research
areas such as:

-   brake reaction times -- such information could be used to refine
    collision warning sensitivity parameters

-   warning sounds -- to determine whether drivers react faster to
    visual or audio cues of hazards and to determine optimum warning
    sounds

-   to investigate the effects of false and nuisance warnings on
    operators trust in the system

-   to determine if drivers' visual scanning patterns change with the
    addition of the system

-   to optimize display techniques

## **The SamTrans simulator** 

The SamTrans Simulator is a FAAC simulator and is made up of the
following components:

-   A simulated Gillig bus driver's workstation, which includes all the
    normal controls, and seat as the Gillig buses that are in
    operational use by SamTrans

-   Five 70 inch rear-projection visual displays to provide the driver
    with the "out the window" forward and side view.

-   Two 42 inch plasma video displays to provide rear views, these are
    seen by the driver through use of the mirrors

-   An overall 315 degree field-of-view

-   An Instructor/operator station that is used to control the overall
    set-up

-   An auxiliary driving station

The set-up of the simulator can be seen in the figures below:

![](media/image1.jpeg){width="4.884722222222222in"
height="3.6638888888888888in"}

Figure 1 Simulator set-up from the back

![](media/image2.jpeg){width="4.884722222222222in"
height="3.6638888888888888in"}

Figure 2 Trainer/Experimenter workstation

![](media/image3.jpeg){width="4.629166666666666in"
height="3.4715277777777778in"}

Figure 3 Driver Seat with forward view

![](media/image4.jpeg){width="4.629166666666666in"
height="3.4715277777777778in"}

Figure 4 Simulated view of the interior of the bus

Using the existing FAAC simulator of SamTrans buses, researchers at PATH
have begun the initial development of a system to integrate the
collision warning system into the simulator and to provide a method to
collect driver behavior data (such as throttle position, steering wheel
angle etc.) that could be analyzed to determine the consequences of
implementing different warning systems. A brief outline of the method is
presented in the next section.

## PATH CWS/FAAC Simulator Integration

Currently, the PATH CWS operates only on physical buses using actual
sensors (LIDAR/RADAR). It is desired to integrate the CWS with the
simulator in order to quickly evaluate collision warning performance.
The FAAC simulator computer at the SamTrans site broadcasts over a
closed Ethernet network the state (i.e. position, velocity, heading,
etc.) of the bus and other vehicles depicted in the virtual reality
scenario (see Figure 5).

![](media/image5.wmf){width="5.997916666666667in"
height="3.154166666666667in"}

Figure 5 PATH simulator software architecture

Data is transmitted at 30 Hz and is read by a computer system running
the CWS algorithm. Since this algorithm requires inputs from actual
LIDAR/RADARs, a program has been developed that models the LIDAR/RADAR
detections using virtual beams projected into the scene. If a frontal
target is detected, this information is sent to the CWS algorithm for
determination of the threat level. The LIDAR/RADAR model process
provides inputs to the CWS algorithm in the same form as the actual
sensors mounted on the buses. This alleviates the need to modify the CWS
algorithm used on the actual buses and allows a transparent code
interchange between the simulator and buses. If it is determined that a
warning should be issued, the CWS process writes the threat level to a
digital I/O driver that controls two DVI displays described below.

Inside the booth where the driver views the virtual scene, two visual
devices or "light bars" for collision warning will be used, one of which
is shown in Figure 6.

![](media/image6.jpeg){width="2.588888888888889in" height="3.925in"}

Figure 6 DVI light bar.

One light bar is mounted on the left-hand "A" pillar and a second
mounted on a center windshield mock-up pillar or strut. Both are wired
directly to and controlled by the CWS computer. Each has a number of
vertically stacked rectangular light segments on top and a two
triangular shaped lights on the bottom. The rectangular light segments
correspond to frontal and frontal corner hazards, while the triangular
lights refer to side hazards. For this study, only frontal hazards will
be considered.

The light bars illuminates amber to indicate a less severe threat while
red and ultimately, flashing red indicate a more severe or imminent
threat. Based on the CWS algorithm, as a hazardous situation becomes
more imminent, more light segments will illuminate, starting at the top
and working downward. Thus, collision imminence (i.e. threat of a
collision) is reflected in both the number of lights illuminated as well
as the color of the lights.

## Quantitative Evaluation and Testing of FCWS

In order to validate the Transit Bus FCWS performance extensive tests
were undertaken in a known environment similar to urban and suburban
driving conditions. The testing was conducted for two main purposes: (a)
to preliminarily evaluate the performance of the FCWS algorithm
including sensor detection, estimation and fusion for multiple target
tracking and threat assessment based on those tracking algorithms
developed at California PATH; (b) to test the measurement and estimation
error characteristics based on vehicle on-board sensors in an known
environment. The test data can be used for system tuning and further
development purposes. A test of a FCWS was also conducted by CAMP
project as reported in \[1\]. However the testing conducted by CAMP was
Human Factors related to test a specific maneuver (driver last minute
braking) and was conducted using drivers from different age groups as is
reported in \[2\] The CAMP project was mainly for purposes of defining
warning threshold criteria as opposed to a test of the technical
characteristics of the system.

In any urban and suburban driving environment, objects or hazards in bus
forward path can be divided into two categories: moving objects and
static objects. The test environment described in this report was
created purposely and thus known in the following senses: Moving object
-- its velocity and position with respect to an inertial coordinate
system are synchronized and recorded in real-time together with those of
the bus -- the subject vehicle; Static object -- its position is also
recorded. If the subject vehicle moves in a specified manner from a
known initial position, then its motion history is known at any time. In
this way, a known inter-relationship between the subject vehicle and the
environment (moving target vehicles and static object) is created. Those
true values are thus used to compare with the corresponding
detected/estimated values based on remote sensors.

The test was restricted to vehicle moving along a straight road instead
of on curved road. However, similar tests can be conducted for any other
environment in future development, for example on a curved road, or
up/down hill sections. Our test site was at Crows Landing, an abandoned
NASA airfield, which provides multiple straight lanes (runways) without
extra disturbances.

This section will describe the test procedures and data collection
methods as well as provide some preliminary data analysis from the
testing.

###  Test Objectives

(1) To test sensor ***measurement error*** and ***time delay***, mainly
    from LIDAR and RADAR for target position and/or speed detection in a
    known environment;

(2) To test the ***estimation/prediction error*** and ***processing time
    delay*** in the algorithm. The algorithm takes sensor measurements
    as input and target position, speed, and acceleration as output.
    Those two factors are the most critical factors for threat
    assessment of warning issuance;

(3) Other on- vehicle sensor ***measurement errors*** and ***time
    delays*** including speedometer, yaw and yaw rate from the Gyro;
    (The relationship between steering angle and yaw rate is already
    known.) It is noted that, although the test is on a straight road,
    minor yaw movement would greatly affect the on-board sensor
    detection accuracy.

(4) ***Reliability and robustness***: Target missing rate in raw
    measurement and in real-time processing such as tracking. In
    general, there are two places in the system which could lead to a
    target being missed: the sensors themselves do not detect the target
    at all (This happens to both LIDAR and RADAR) and the algorithm
    fails to recognize it correctly from the sensor outputs. The target
    might be missed or its position might be miscalculated/estimated due
    to tracking, filtering and/or fusion algorithms problems.

The advantage of using a known environment is that it can provide a
known reference which cannot be achieved based solely on current
recorded data from the vehicle because we do not know if those data
provide true measurement and if not, what are the characteristics of the
errors. It can be seen that those tests are not just for evaluation,
they also provide a quantitative test of sensor characteristics. The
measurement error obtained can be used for future ICWS algorithm
development/improvement.

### Considerations for Designing the Tests

(a) The bus starts at the same point for each run. Thus the longitudinal
    position of the bus at any time is known if the speed was calibrated
    with the help of fifth wheel (true ground speed) and string pot (to
    be described later; See appendix for photos). To calibrate this, a
    car with string pot connection is run in front of the bus as a
    moving target. The ground run-distance can be calibrated using the
    fifth wheel of the car. The fifth wheel has sensors to count its
    number of teeth in unit time (converted to speed) and thus to
    estimate the covered ground true distance under the assumption that
    there is no tire slip. This assumption is reasonable partly because
    the road is dry asphalt and partly because the fifth wheel is
    passively dragged.

(b) The car in front of the bus has a string connection also to ensure
    that it starts at a known fixed point. To avoid damage to the string
    pot, another 6.38\[m\] of string is used as an off-set extension.

(c) Obstacles should be put far enough away for the Bus to accelerate to
    required distance. In our test, the objects were over 400\[m\] away.

(d) For each run, the relative positions -- both lateral and
    longitudinal -- of the obstacles with respect to the bus lane are
    known and recorded.

### Hardware and Software Setup

These include

-   A Lincoln Town car was used as the target vehicle. The Lincoln Town
    car was installed with an engineering computer running real-time
    QNX-4; A SamTrans Bus was the subject vehicle, which was installed
    with a engineering computer PC-104 running QNX-4.

![](media/image7.jpeg){width="4.745138888888889in"
height="3.379861111111111in"}

Figure 7 Fifth wheel to measure true ground speed and string pot (Top of
the bar)

-   A Fifth wheel (Figure 7) was mounted on the Lincoln to measure
    vehicle ground distance free of any tire slip