-   An AMETEK Rayelco Position Transducer (range between 0 -- 50ft), or
    ***String Pot*** (Figure 1), was used for measuring inter-vehicle
    distance. A String pot was installed on the rear end of the Lincoln,
    (then hooked to the Bus) including software. The data recorded from
    the string pot was converted to relative distance between the bus
    and the Lincoln. Speed and distance measurements on the Lincoln were
    calibrated before the test

-   On the Lincoln a Gyro was used to monitor the lateral movement of
    the target;

-   Data recording: For synchronization, the information passed over
    from the Lincoln were saved with the other data in the main computer
    of the subject vehicle.

-   Carton boxes covered with RADAR/LIDAR reflecting materials to
    enhance signal reception were used as static objects.

-   Wireless communication system: A FreeWave card was installed on both
    the Samtrans Bus and the Lincoln running under QNX-4 real-time
    operating system; The information passed from the Lincoln to the
    bus/ or from the bus to the Lincoln was:

    -   time stamp

    -   fifth wheel speed

    -   vehicle acceleration

    -   yaw rate from gyro scope

    -   string pot voltage (can be converted as inter-vehicle distance)

    -   Latitude (GPS)

    -   Longitude (GPS)

    -   UTC time (GPS)

    -   Altitude (GPS)

-   4 voice radios were used for coordinating operation between drivers,
    people responsible target disposition, recording, ground position
    measurement

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

Figure 1 Using string port to detect true inter-vehicle distance
on-the-fly

### Known Driving Environment 

The known driving environment can be designed to include ***static
objects Figure 2*** and Figure 3 ) and ***moving objects*** (Figure 4 ).
For static objects there is no need to pass anything. It is only used to
test the sensors measurement error and warning. These objects may be
designed to include road side parked vehicles, mail boxes, traffic signs
etc.. To present different objects, boxes with different size may be
chosen. To make the objects RADAR/LIDAR sensitive, the boxes were
wrapped with a reflecting cover.

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

Figure 2 View of the Static Objects from the Bus

A ***Moving object*** may include vehicles driving in different
directions, in adjacent lanes and front vehicle. The target vehicle and
the subject vehicles are connected with a

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

Figure 3 Detecting parked vehicles on both sides

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

Figure 4 Moving (front vehicle) and static objects

measurement string which can measure inter-vehicle distance in
real-time. Wireless communication can be used to synchronize the
measurements on those two vehicles. This set up is to test real-time
inter-vehicle distance measurement, estimation, prediction and
filtering;

Host vehicles always start from a known position. Based on the ground
position of the targets and the running distance of the bus at any time
instant, we know the relative position between the bus and the targets,
which is a critical point. All the measurements are with respect to a
ground coordinate system as defined in Figure 5 .

### Preliminary Test

A pre-test for the following items was conducted at SamTrans before the
formal test:

(a) Re-calibrate the SamTrans bus and ensure that all the on-board
    sensors and computers working properly;

(b) Verify that the sensors and wireless communication systems were
    properly installed, calibrated and working on the Lincoln;

(c) To use laptop computer connected with the subject bus to use "run"
    instead of "auto-run" for manual data-saving interrupt for matching
    the saved data with the test maneuver;

(d) To make sure all the data saving are correct on the subject bus;

![](media/image5.png){width="5.614583333333333in"
height="4.221527777777778in"}

Figure 5 A Ground Coordinate System

### Crows Landing Test 

#### Relative speed and inter-vehicle distance error and time delay test without string but with wireless communication 

This test can be used to figure out the relative speed error and
measurement time delay with low relative movement. Without string, such
movement can be made much larger and faster;

***Maneuver 1:*** Vehicle following. (Figure 6) Use a leading vehicle in
the front of the bus with FCWS to run at different constant speed:
5\[mph\], 10\[mph\], 27\[mph\], 40\[mph\], 55\[mph\] for some time. The
bus driver was asked to determine a safe and comfortable inter-vehicle
distance.

Leader vehicle approximate deceleration: 0.2\[$\frac{m}{s^{2}}$\],
0.8\[$\frac{m}{s^{2}}$\], 1.5\[$\frac{m}{s^{2}}$\]

Inter-vehicle distance: speed/relative-speed dependent on the vehicle
speed and driver's choice -- feel comfortable;

> ![](media/image6.png){width="5.99375in" height="4.495138888888889in"}

Figure 6 No string for vehicle following

####  Inter-vehicle distance error measurement (with string) and time delay test with variable speed and deceleration

***Maneuver 2:*** Vehicle following (Figure 7): Use a leading vehicle in
the front of the bus with FCWS to run at different constant speeds:
5\[mph\], 10\[mph\], 15\[mph\], 20\[mph\], 25\[mph\] for some time then
the lead vehicle decelerates at approximately: 0.2\[$\frac{m}{s^{2}}$\],
0.5\[$\frac{m}{s^{2}}$\], 0.8\[$\frac{m}{s^{2}}$\]

Inter-vehicle distance: speed/relative-speed dependent. Because the
total length of the string is 16 \[m\], an offset 6.38 \[m\] of the
string is used to avoid break due to over-stretching.

![](media/image7.png){width="5.99375in" height="4.495138888888889in"}

Figure 7 String Pot and wireless communication are used

#### Static object lateral distance measurement, prediction/estimation error test

***Maneuver 3:*** Carton boxes covered with RADAR reflectors at certain
heights are put in known places with respect to the center of the road
(Figure 2). The Lincoln (Error: Reference source not found) is parked on
the left or right side at certain distances with respect to the centre
of the road: 1.4\[m\], 2.0\[m\], 3.0\[m\] measured to edge of the
Lincoln; Drive the Bus straight ahead at different speeds: 5\[mph\],
15\[mph\], 27\[mph\], 35\[mph\]. The bus needs to run in the center of
the lane or at the edge of the lane; The Lincoln driver opened the left
door sometimes (Figure 9); Multiple cars and boxes used as objects to
make sure there is no overlap. Heavy objects are put inside the boxes so
they would stay in place.

![](media/image8.png){width="5.99375in" height="4.495138888888889in"}

Figure 8 Parked car testing scenario

![](media/image9.png){width="5.99375in" height="4.495138888888889in"}

Figure 9 Park car door open test scenario

***Maneuver 4:*** Two cars are running in left/right adjacent lanes but
a known lateral distance in the same and opposite direction at different
constant speeds: 10\[mph\], 30\[mph\]. The bus can run at slightly
different speeds (non-constant) so that there is some relative movement
when the vehicles run in the same direction (Figure 10)

![](media/image10.png){width="5.99375in" height="4.495138888888889in"}

Figure 10 Side Moving Target Direction

#### Cut-in test

***Maneuver 5:*** The Lincoln travels in the left/right adjacent lanes
but at a known lateral distance in the same direction at different
speeds: (10\[mph\], 20\[mph\], 35\[mph\]) for a while and then
accelerates to take over the bus and cut-in (Figure 11). The speed
variation of Lincoln is intentionally made. The bus driver is to decide
an appropriate inter-vehicle distance.

#### Gyro rate and RADAR/LIDAR dynamic angle measurement test

***Maneuver 6:*** Drive the bus straight at certain speed: 5, 15
\[mph\]; Once the bus arrives at a certain point, drive around and then
return in the same lane in the previous direction and pass the objects
again. In each run the objects will be viewed twice by the RADAR
sensors.

![](media/image11.png){width="5.99375in" height="4.495138888888889in"}

Figure 11 Cut-in and cut-out to test lateral movement detection

#### Low speed approaching/crashing to a static object

***Maneuver 7:*** Carton box (covered with foam block) with RADAR
reflectors at certain height are put in different places of the road and
drive the Bus towards the object at different speed: 25\[mph\],
15\[mph\], 10\[mph\], 5\[mph\] to see the reaction of the warning system
and driver's response (Fig. 114);

![](media/image12.png){width="5.99375in" height="4.495138888888889in"}

Figure 12 Crash Test; No string is used

### Data Analysis

As mentioned previously, the test data can be used for two objectives:
(a) To check LIDAR/RADAR measurement, estimation and target tracking;
(b) To tune those parameters. The data collected through these
experiments have shown that both of these objectives can be achieved.
The following presents examples of measurement and estimation using
LIDAR and RADAR compared with the independent measurement from the fifth
wheel and the string pot measurements.

1.  The following plots correspond to *Maneuver 2* (Figure 7) for target
    longitudinal measurement.

In Figure 13, Figure 14 & Figure 15, both target vehicle and SV speeds
are around 10\[mph\]. String pot is used to test LIDAR/RADAR
longitudinal measurement and estimation including distance and speed.
The fifth wheel speed and string length are considered truth
measurements after calibration. However, lateral position measurement is
also plotted.

![](media/image13.png){width="5.663888888888889in"
height="4.247916666666667in"}

Figure 13 LIDAR/RADAR target lateral position measurement and estimation
\[m\]

It can be seen from this figure that lateral measure of LIDAR is
slightly more consistent compared to RADAR.

![](media/image14.png){width="5.459722222222222in"
height="4.094444444444444in"}

Figure 14 String (true) distance vs. LIDAR/RADAR distance estimation
\[m\]

![](media/image15.png){width="5.209027777777778in" height="3.90625in"}

Figure 15 LIDAR/RADAR target speed estimation vs. fifth wheel \[m/s\]\
The above two figure shows that RADAR distance and speed measurement in
longitudinal direction could achieve better results.

##  {#section .unnumbered}

##  {#section-1 .unnumbered}

##  {#section-2 .unnumbered}

## Summary

Under this project, the SamTrans/FAAC simulator is being modified to
incorporate CWS functions, which will allow us to create specific
scenarios of interest to which large numbers of drivers can be exposed
to, providing us with a much more extensive data set than we could
obtain from in-service operation of two buses. The project team plans to
conduct experiments using the simulator at the later stage of this
project. From the simulator experiments, more extensive data sets will
be obtained which will be used to analyze driver behavior change due to
the introduction of ICWS and for further optimization of the warning
algorithms and DVI.

# Recommendations {#recommendations .unnumbered}

The research and development of the ICWS has made significant progress
toward deployment. However, due to the research nature, significant work
is still needed in order to achieve a fully commercializable integrated
collision warning system. The following outlines further development
needed before commercialization can take place.

## Develop ICWS Markets and Industrial Partnerships

Like any product, commercialization of ICWS requires both sizable market
demand and willing suppliers. The crash data analysis under the early
FCWS and SCWS studies have shown that transit collision warning system
can enhance transit safety. A recent cost benefit analysis conducted by
Volpe indicated that such safety systems can help the transit operators
to reduce operation cost. For a specific transit operator, the extent of
the cost saving will depend on level of deployment, which, transit
operators say, is very much decided by the unit cost after the
technologies meet their performance and technical requirements. The unit
cost in turn will depend on the market size. The study conducted by the
ICWS team indicated that ICWS can potentially benefit and be of interest
of other commercial fleet operators such as UPS, which operate in
similar environments. Under the current project, the ICWS team begins to
reach out to transit and other fleet operators. The team recommends that
this effort be continuously carried out until an initial market is
established. In parallel to the market development, it is essential to
work with industrial partners to commercialize the ICWS, starting from
the phase of field operational tests.

## Conduct Field Operational Tests

Under Phase One of FCWS and SCWS development, three revenue service
buses were instrumented with frontal collision warning systems and a
test vehicle was instrumented with a side collision warning system.
These developments have led to the current ICWS efforts in
instrumentation of two integrated collision warning systems onto a
SamTrans bus and a PAT bus. Field testing is currently underway.
Although the research team has carefully planned the field tests in
order to collect data from multiple drivers on selected routes, the
exposure to diverse driving behaviors, to different driving environments
and to hazardous conditions is very limited. It is the consensus of the
research team and interested transit agencies that a larger scale Field
Operational Test (FOT) needs to be performed in order to collect
adequate data for verifying the effectiveness of the ICWS and for fine
tuning the design parameters or making improvements. The ICWS research
team recommends that one or two fleets of 50-100 revenue transit
vehicles be equipped with a prototype transit ICWS on a variety of
routes and operating conditions for a duration that can justify
industry-wide acceptance.

## Human Factor Studies Using Samtrans Driving Simulator 

The field tests conducted under the current project provided useful
results for evaluation of the effectiveness of the CWS system from Human
Factors perspective. Because of small number of buses involved in the
field tests within this phase of the project, it is difficult to conduct
analysis of driver behavior changes for specific hazard scenarios. We
therefore propose to conduct human factors studies using the Samtrans
driving simulator to conduct further study of the integrated (forward
and side) collision warning system. The following studies have been
identified as research priorities.

-   To investigate if an integrated (forward + side) collision warning
    system (CWS) affects distracted and non-distracted Transit Bus
    Operators response in imminent collision warning situations.

-   To investigate if operators' visual scanning patterns change with
    the addition of the system. It would be useful to know if operators
    detect all warnings and whether the system causes the operator to
    become distracted. A similar issue was raised by Lee et al (2002)
    who, for a car collision warning study, determined that future
    research should investigate what happens if an operator is already
    braking when they receive a warning -- do they continue to brake at
    for example the same rate?

-   To further investigate what types of warnings bus operators view as
    nuisance warnings. Whilst some of the types of nuisance warnings
    have been identified in human factors ride-along, much variation has
    been seen both between and within operators' responses to each
    encountered scenario. Use of the simulator would enable different
    operators to be exposed to the same scenario repeated times which
    would help to further clarify what aspects about a scenario feed
    into an operators' consideration of whether the warning is a
    nuisance warning. This type of study could also be used to determine
    the effect of false and nuisance warnings on operators' trust in the
    system.

-   To determine optimal display techniques. This could include
    different visual display methods as well as audio warning sounds --
    to determine, whether operators react faster to visual or audio cues
    of hazards and to determine optimal warning sounds. Also of interest
    is where a visual display could be placed in a bus that does not
    have a center pillar. One solution, for this type of bus would be to
    place the display on the right pillar.

-   To further determine optimal integration strategies for the
    integrated collision warning system. In the present system there is
    no prioritizing of warnings. It would be valuable to know what the
    human factors implications would be of the following scenarios:
    giving the forward system priority at all times, giving the side
    system priority at all time, giving the most critical hazard
    priority or having no priority (current system).

## Finalize Performance Specifications 

Learning from field operational tests and simulator studies, the
performance specifications developed under the current ICWS research
program should be updated and finalized in order to meet the transit and
other fleet operators' needs. The ICWS Performance Specifications should
have separate sections for the following:

1.  Specifications related to frontal sensors and performance only

2.  Specifications related to side sensors and performance only

3.  Common specifications for frontal and side sensors and performance

This would allow transit agencies to purchase non integrated systems at
a lower price if they have a lot of side collisions or frontal
collisions only.

## Hardware and Software integration of ICWS

The philosophy of building the first advanced prototype was to achieve
functional integration and, at the same time, minimize the risk of
system integration by having separate duplicate systems and data
interfaces and to include comprehensive data collection capabilities.
The duplicate systems would prevent one system from taking down the
other system should a failure occur. It also minimized risk by making
sure that each partner had available what they needed to deploy a
system. The sensory data, additional engineering data and video streams
collected are for thorough data analysis. In order to perform the FOT, a
higher level of hardware and software integration needs to occur in
order to achieve the level approaching a commercial prototype.

### Eliminate Duplication of Hardware

The experience gained with each other's system can now be taken to the
next step of integrating the testing prototype by eliminating duplicate
hardware and combining algorithms. Duplications that could be eliminated
are:

1.  Creep Sensor Interface

2.  Gyros

3.  Separate electronic enclosures

4.  Dinex Interface

5.  Power supplies and power conditioning

6.  Power up and Power down logic

7.  GPS (May also be redundant with electronics for bus tracking and
    annunciation systems)

8.  Cell phone interface (could be eliminated completely)

9.  Reduce the number of processors (see next section)

10. Eliminate most of the video cameras and one digitizer (see eliminate
    video section)

11. Combine the data recording functions into one computer chassis (see
    next section)

12. If transit bus has stability control system, then bus state
    information may be available without additional gyros or creep
    sensor

13. Future drive by wire systems may include steering wheel encoders

Eliminating these duplications would increase the overall reliability of
the system due to less electronics. It would decrease the overall cost
of the system for the same reason.

### Combine / Eliminate Processors

The current ICWS contains five CPU's to handle the top level processing
tasks. This does not include the processors that are embedded in any of
the sensors. The CPU's in the advanced ICWS prototype include:

1.  FCWS Engineering computer

2.  Left SCWS Engineering computer

3.  Right SCWS Engineering computer

4.  FCWS Video and Data recording computer

5.  SCWS Video and Data recording computer

A minimal commercial prototype could eliminate both of the Video and
Data recording computers since they are not necessary to generate
warnings to the transit operator and as a minimum combine the left and
right SCWS Engineering computers. The current barrier to combining the
FCWS and SCWS Engineering computers is that each system runs different
warning algorithms and data processing thus increasing the CPU loading
above what one processor could currently handle (see future research for
more information).

### Eliminate Video

The elimination of collecting video information not only minimizes the
CPU and digitizing hardware on a commercial system, it would also
eliminate seven of the nine cameras installed as part of the advanced
ICWS prototype. The two remaining cameras are used for the curb
detection at the front of the bus (laser line striper) and curb
detection ahead of the bus (fusion of video with other sensors).

As part of the advanced ICWS prototype, the cameras and video / data
recording were necessary to allow the continuing development of
algorithms and analysis of system data.

One of the questions that would need to be answered is whether the
additional data recording could be used as a feature of the system, e.g.
to limit transit liability in collisions and helping to defend transit
operators against fraudulent claims and recording vandalism. It could
also be used for training purposes. This might be a feature for which
some transit companies would pay the additional cost. It should
certainly be part of an optional configuration, but may not be part of
the base package.

### Commercialize Laser Scanners

The most expensive components of the prototype ICWS system are the
LIDARs (laser scanners). In the ICWS prototype the sensors alone account
for over \$ 15,000. That does not include the additional cost to mount
them in retractable assemblies. To make the ICWS more economically
feasible, LIDAR sensors should be designed for this specific
application. Also, weaknesses of the current scanners significantly
increase the system false alarm rate.

The main issues associated with this design are:

1.  Overlapping fields of view.

2.  Size

3.  Reliable detection

4.  Resolution

5.  Range

6.  Update rate

7.  Expense

8.  Synchronization of scanners

9.  Eye safety

**Overlapping fields of view:** The current system uses three LIDARs.
There is a LIDAR mounted on the left side of the bus, the front of the
bus and the right side of the bus. The side LIDARs have 180 degree
FOV's. The front LIDAR has a narrow FOV and is used to see far ahead in
the lane. The LIDAR could be redesigned to mount on the left and right
side of the front bumper with 270 degree FOV's. This could eliminate one
LIDAR and provide better coverage than the current system in front of
the vehicle. Even if the front look ahead LIDAR could not be combined
with the side LIDAR, it could be replaced with a much less expensive
adaptive cruise control unit since the object tracking could be done
with the other LIDARs. However, this roughly doubles the worst-case
distance to cover the entire side of the bus. To get the same resolution
we have now at the back of the bus, we would need twice the angular
resolution.  It seems plausible that coverage of the back half of the
bus is not as important as in the front, but this would have to be
looked at in more depth.

**Size:** The LIDARs used on the side of the transit bus are over six
inches deep. Most transit buses are at the maximum width for roadway use
already. Although exceptions are made for safety devices, such as
mirrors, the addition of another foot of clearance needed makes the
vehicle harder to operate in the urban environment and potentially more
dangerous to pedestrians and other fixed objects and more prone to be
damaged. For this project, these LIDARs were mounted in retractable /
extendable assemblies. This adds cost, complexity, cpu loading and
additional maintenance issues to the system. These were operated using
the vehicle's air system. These assemblies were computer controlled in
order to implement a reflexive behavior for self preservation, present a
lower profile in tight situations and retract if it looks like it was
going to hit something in its path. Using a fixed mounted front bumper
system not only reduces the cpu loading but also the interfaces
necessary to extend and retract the LIDARs.

**Reliable detection:** Reliable object detection is crucial for proper
system operation. There are two types of detection failures we have
observed fairly frequently that significantly degrade system
performance: missing returns and ground returns.

With the SICK sensors, missing returns which occurs both due to weak
returns from low reflectivity objects and due to too-strong returns from
nearby high-reflectivity objects. We don\'t understand exactly why the
LIDAR fails to detect, and can only speculate on possible fixes. It
would help for the sensor to have a larger dynamic range and use a
different wavelength.

Ground returns occur when the scanner sees the ground, either because
the ground is not flat (a hill) or the bus tilts to the side (going
around a turn.) In the current system, ground returns are interpreted as
potential collisions, and are one of the largest causes of false alarms.
If the scanner had multiple beams spreading out vertically, or in some
other way could measure multiple points vertically on the same object,
this would greatly reduce false alarms from ground returns, because it
would be easy to determine whether the object is more or less flat on
the ground, or sticks up significantly. Multiple beams would also give
us more chances to detect any given object, so would reduce missing
returns as well.

**Resolution:** For the current side LIDARs one can set the angular
resolution to 0.25^o^, 0.5^o^, or 1^o^. The smaller resolutions have the
tradeoff of reduced update rate and interlacing. The 0.25^o^ resolution
has half the FOV. We are using the side LIDARs set to 1 degree azimuth
resolution and 1cm range resolution. The position uncertainty is
dominated by the azimuth resolution at ranges typically seen in the
collision warning system. This means that in some sense the sensor is
unbalanced for our purposes. The range resolution could be reduced
without compromising performance, or alternatively the azimuth
resolution could be increased to exploit the range resolution.

A characteristic of the SICK, and of many other possible similar
designs, is that the range accuracy is roughly independent of range,
whereas the position uncertainty due to azimuth resolution increases
linearly with range. In any such scanner, there is one range at which
the position error from range and azimuth is equal, where the scanner
can be considered balanced. For the SICK with 1 degree resolution, this
is approximately 2 meters (using a range accuracy of +/- 2cm to allow
for noise.) To be balanced at 8 meters (a more typical range in the
collision avoidance system), we would need to either increase the
angular resolution to 0.25 degrees or reduce the range accuracy to +/-
8cm.

If the range accuracy was specified as percentage of the range, then the
range error scales proportionately with the azimuth resolution
uncertainty, so the measurement accuracy would be balanced at all
ranges. The balanced RMS range accuracy as a percent of range is then
about 25*\*sin(angular resolution),* or 0.4% for one degree angular
resolution.

The azimuth resolution can be increased to 0.5 degrees by using an
interlaced mode where two consecutive scans are combined (reducing the
update rate to 37 Hz.) We don\'t use the 0.5 degree interlace mode
because it creates strong artifacts on moving objects, and also because
the total amount of data is not actually increased (due to the drop in
update rate.) With algorithmic improvements in the tracker, it should be
able to tolerate the interlace artifacts, and then there would be some
benefit to using interlace.

**Range:** The current side LIDARs are specified to be accurate to 50
meters and can see as far as 80 meters. As with range accuracy, maximum
range should also be balanced with azimuth resolution. As range becomes
large, the points become so far apart that any return becomes largely
useless. We require at least three points on an object to create a
track. Because of this, with 1 degree azimuth resolution, small objects
such as pedestrians cannot be tracked above about 20 meters. For side
collision warning, a reliable LIDAR range of 15 meters would be
adequate. See however, the discussion of detection reliability.

Though we have seen detection fail at ranges of only a few meters, we do
not suppose that the SICK is failing to meet it spec. The problem is
that real-world objects may have reflectivity that differs significantly
from the standard target used in the performance spec. A lower maximum
range would not harm system performance as long as it did not further
degrade detection reliability. The main conclusion here should be that
the scanner range specification is not a valid indication of the actual
detection range in the real world, and that although the SICK
specification looks in excess of requirements, the observed scanner
performance is one of the main limits on system performance.

**Update rate:** The current side LIDARs output 75 scans a second at 1
degree resolution. The scan update rate should be balanced against
maximum speed and size of objects which we want to track. If an object
moves too far between two scans, then it is difficult to create a track
from consecutive measurements. With the current tracker configuration,
we could tolerate an update rate as low as 25 scans per second and still
track objects moving at 20 meters/sec. At 10 scans/sec, the max speed
would be reduced to 8 meters/sec. A lower update rate could help with
cost reduction.

**Expense:** The current price of these LIDARs makes an advanced ICWS
prohibitively expensive for commercial applications. Designing a
commercially deployable sensor would require a certain amount of non
recurring expense; the recurring expense could be reduced significantly.

**Synchronization of scanners:** Currently the data from each scanner is
analyzed separately all the way up to the level of warning generation.
If the scanners are appropriately synchronized, the raw data can be
fused to achieve a virtual 360 degree scanner. This then allows a single
algorithm to compute front and side object detections and velocities,
with no discontinuities at the limits between two scanners.

**Eye Safety:** Some trade offs will have to be performed to ensure that
the laser scanner will be eye safe. This is less of a potential problem
with the current configuration of SICK laser scanners due to the
rotating mirror. However, it needs to be part of the design
specifications.

Essentially we are looking for a system with:

1.  A lower profile so it won\'t stick too far out of the side of the
    bus (Coke can size with remote electronics may be one way to go)

2.  About 270 degrees FOV

3.  Weather resistant, since it would have to operate in the rain and
    snow

4.  Update rate of at least 10 scans/sec, 25 scans/sec preferred.

5.  Non-interlaced azimuth resolution of 1.0 degree or better.

6.  Reliable detection of real-world objects (not standard targets) to a
    range of about 15 meters.

7.  RMS range error of 0.4% of measured range or 4cm, whichever is
    greater (for balanced performance with 1 degree azimuth resolution.)

8.  Although not required, system false alarms could be significantly
    reduced if the scanner had two or more scan beams spreading perhaps
    0.5 degrees above and below the horizontal scan plane.

9.  Be Eye-safe

All of these specifications have to be analyzed as to their effect on
the warning algorithm performance and system cost. This is more of an
engineering effort at this point and not research.

### Integrate a Rear Collision Warning System

A Rear Collision Warning System could be integrated within the same
framework as the FCWS and SCWS systems. For a minimal approach, the
warning to drivers approaching the rear of the bus at an unsafe speed
would not require transit operator involvement at all. A maximal
approach would place two additional 270 degree LIDARs on the rear
corners of the transit bus. The total of these two and the front two
would provide redundancy and total surround sensing of the transit bus.
This would make the algorithms more robust, especially for the side
object tracking. It would also allow objects moving from the rear of the
bus to the sides to be picked up more quickly and identified sooner.
Some work would need to be done to see if the DVI would be modified to
include rear objects. Although buses usually do not back up while in
revenue service, it does sometime happen, so it makes sense to supply as
a minimum a light to indicate an object is behind the bus.

### Training

Buses equipped with the ICWS such as the advanced prototypes could be
used not only for CWS functions, but could be used to provide training
of transit operators. Through the use of feedback from the cameras and
bus state information, instructors could provide feedback of how
operators performed on training courses or on the road. As a training
device, transit agencies may opt for more functionality and a higher
price tag.

## Areas for Future Research

Although the current phase CWS project has made significant progress for
an ICWS that can effectively provide drivers with warnings and alerts
under hazardous situations, some technical issues still remain and
deserve additional research. The project team has identified the
following research areas:

### Transit bus data

A considerable amount of data will have been collected by the end of the
ICWS project. In fact, the volume will be so great that many interesting
secondary analyses will not be feasible to conduct due to time and
resource limitations in the ICWS project. In this section we will
identify a few potentially interesting analyses that could be explored
at a later date. This is not an exhaustive list -- it is only a small
sampling of opportunities.

#### Inputs for operator training

Given the highly instrumented nature of the bus it is feasible to
identify opportunities for new or modified operator training. For
example, improved documentation of specified scenarios could be used to
guide mirror use training. Another example would explore whether it is
possible to induce safer pedestrian behavior as a result of door opening
or bus stop approach actions.

#### Inputs for public education

During the course of safety analyses it may become obvious that certain
behaviors by the driving public are extremely indicative of potential
harm, such as cutting in front of a bus and braking. Isolating and
breaking down such actions can identify and verify practices that may be
in need of public education.

#### Inputs for roadway infrastructure

Using the data set we will be able to identify and verify roadway
fixture geometries that produce difficult bus operations (e.g., road
geometry garbage cans placed too close to curb, parking spots too close
to corners, etc). These can be used to assist infrastructure
specifications and parking enforcement activities (e.g., ticket and tow
cars illegally parked near corners).

#### Verification of risky behavior predictors in the driving public

As a result of the sensor data we will be able to characterize how the
driving public behaves irrespective of the bus. From this we may be able
to identify and verify characteristics of vehicle motion that are
indicative of potential dangerous behavior. For example, a vehicle that
is tracked for 30 seconds may only exhibit dangerous behavior during the
last 5 seconds (e.g., tailgating). It may be possible to correlate
distinctive motions (e.g., rapid lane changes) or vehicle
characteristics (e.g., dented body panels) with confirmed risky
behavior. Certain unverified suspicions could be examined using real,
anonymous data.

### Unify the FCWS and SCWS Tracking and Warning Algorithms

Currently, the Advanced ICWS uses different object detection and
tracking algorithms and different warning algorithms for the forward
looking sensors and the side looking sensors. The development of a
common object detection, tracking, and warning algorithm using the 360
degree virtual sensor would greatly reduce the complexity of the
software, with all the benefits of reduced development time, increased
robustness, and less maintenance. It will probably also give the driver
a better intuition about the whole system, because the front and the
side behave in a more consistent way.

### Integrate ICWS with other electronic vehicle systems

The following systems offer an opportunity for standardization and cost
savings:

1.  Annunciation Systems -- This would provide dual usage of GPS based
    information.

2.  Bus Tracking Systems -- This could add dispatch capability. The cell
    phone interface could call home if an incident occurs

3.  Provide inputs to bus electronics standards J1939 -- As standards
    evolve, they should begin to accommodate the collision warning
    functions. Perhaps a separate safety bus should be defined.

### Improvements to the object tracking algorithms (DATMO)

Improvements to the warning algorithm heuristics and object models for
pedestrians, bicyclists and vehicles could be made. Areas for
improvement would be the ability to recognize parked cars and longer
distances from curb.

In the SCWS the warning algorithm can accommodate models for the bus and
the objects. Currently we have an enhanced model for bus behavior, but
only very simple models for pedestrian, cars, and fixed objects. There
is no separate model for other objects like bicyclists, motorcycles,
animals, and vegetation. Models for all objects can be developed or
enhanced. The warning algorithm can also make use of environmental
information like the position of the curb. Possible enhancements to the
system are:

1.  Increase the look ahead of the curb position and identifying parked
    cars alongside the road. 4: Knowledge - Knowledge about road and
    route could be used to eliminate false alarms triggered by road-side
    objects or out-of-lane objects.

2.  Use more sophisticated algorithms to improve the response time of
    the turn rate and acceleration estimates. These currently are only
    marginally useful.

3.  Improve the segmentation procedure so that it works better in highly
    cluttered environments (where objects are closer than 0.7 meters.)

4.  Assign classifications such as car, pedestrian, bicycle, wall, and
    ground return to tracks based on the change in shape and motion over
    time. This would allow us to predict motion more accurately by using
    appropriate distinct dynamic models, and could also reduce false
    alarms by detecting tracks that change in ways atypical of good
    tracks.

### Improvements to FCWS warning algorithm

Improvements to the FCWS warning algorithm would also be desirable in
order to enhance the performance of the CWS system. The improvements are
mainly in the following areas:

1.  Transition of vehicle models: It was found that nonholonomic model
    is good for moving targets in terms of estimating yaw-rate and
    moving direction. However at lower speed, due to short displacement
    in processing time, it is hard to detect moving direction. In this
    case free moving model is better. The transition of vehicle models
    from higher speed to lower speed and vice versa needs improved.

2.  Scenario parsing: This has been a topic since the beginning of the
    project. However it is not well resolved yet. It needs to consider
    the relationship among all objects and subject vehicle and
    infrastructure. Current algorithm only detects straight road in-lane
    objects, and cannot avoid false warnings due to lack of lane
    information and driver status.

3.  Driver model: Driver's field operational data were analyzed leading
    to the empirical threshold settings. However more complex driver
    model may help to tell whether driver is attentive. Collision
    warning is supposed to be issued only when driver is inattentive.

4.  Knowledge - Knowledge about road and route could be used to
    eliminate false alarms triggered by road-side objects or out-of-lane
    objects.

### Sensor Fusion

Each of the sensors that are currently available for obstacle detections
collision warning system has its advantages and disadvantages. For
example, LIDARs provide good range and azimuth measurements but do not
function properly under the bad weather conditions. RADARs on the other
hand, work with most of weather conditions but do not provide the level
of accuracy that LIDARs provide. Field testing also indicates that
additional information about road geometry and roadside furniture may
help to reduce false detections. It is likely more than one type of
sensors will be used in order to enhance the reliability of the system.
When sensor options are considered, sensor fusion can help to maximize
the benefits of these sensors. This is an research area that is
currently being investigated under the ICWS program and it likely will
require continuous investigation beyond this program.

### Develop an under the bus sensor

The current SCWS algorithms employ an inferred under bus logic which
looks for the disappearance of an object around the wheel wells of the
transit bus. As described more fully in the text concerning the warning
algorithms, a positive indication from a specific sensor would be a
better indication of the presence of something in front of the wheels.
The inferred method we are currently using is fooled by occlusions,
multiple moving objects in the same vicinity and the inability to
resolve people boarding the bus and someone slipping near the doorway
under the bus, since both objects disappear within the same vicinity.
The current algorithms detect too many false positives to be used as a
strong measure of a problem. If a sensor could be developed that gave
fewer false positives, then stronger operator interactions such as
getting out of the bus to verify could be implemented. As it stands, we
can only give an indication that there might be a problem.

A.  Acronym Definitions

  ------------------- ---------------------------------------------------
  **ACRONYM**         **DEFINITION**

  APTA                American Public Transportation Association

  ARQ                 Acceleration Required

  CALTRANS            California Department of Transportation

  CMU                 Carnegie Mellon University

  CWS                 Collision Warning System

  DATMO               Detection And Tracking of Moving Objects

  DTCMO               Detection, Tracking and Classification of Moving
                      Objects

  DVI                 Driver Vehicle Interface

  EODS                Enhanced Object Detection System

  FCWS                Frontal Collision Warning System

  FMI                 Foster Miller, Inc

  FTA                 Federal Transit Administration

  HF                  Human Factors

  IBEO                German Laser Scanner Company

  ICD                 Interface Control Document

  ICWS                Integrated Collision Warning System

  IRB                 Institutional Review Board

  IVN                 In Vehicle Network

  LED                 Light Emitting Diode

  PAT                 Port Authority of Allegheny County

  PATH                Partners for Advanced Transit and Highways

  PENNDOT             Pennsylvania Department of Transportation

  RAID                Redundant Array of Inexpensive Disks

  RI                  Robotics Institute

  SAMTRANS            San Mateo County Transit District

  SCWS                Side Collision Warning System

  SICK                German manufacturer of laser scanners

  SLAM                Simultaneous Localization and Mapping

  SV                  Subject Vehicle

  TTC                 Time to Collision

                      

                      

                      

                      
  ------------------- ---------------------------------------------------

B.  Related Documents

[Assessment of Technologies Supplementary Report]{.underline} April
2002, Christoph Mertz

[ICWS Driver-Vehicle Interface April 2003 Design
Specification]{.underline}, prepared by Aaron Steinfeld, Carnegie Mellon
University and Joanne Lins, UC Berkeley

[Integrated Collision Warning Systems Interface Control
Document]{.underline} dated August 2004 prepared by the California PATH
Program, University of California at Berkeley and the Robotics
Institute, Carnegie Mellon University

[Evaluation of Integrated Collision Warning System Proposal]{.underline}
prepared by the Robotics Institute, Carnegie Mellon University and the
California PATH Program, University of California at Berkeley. *In
collaboration with*

> California Department of Transportation (Caltrans)
>
> Gillig Co.
>
> Pennsylvania Department of Transportation
>
> Port Authority Transit (PAT)
>
> San Mateo Transit (Samtrans)

[Transit Bus Collision Warning Systems Integration Program
Proposal]{.underline} dated 5/23/01 prepared by:

> California PATH Program, University of California at Berkeley
>
> California Department of Transportation (Caltrans)
>
> Clever Devices, Inc
>
> Gillig Co.
>
> Pennsylvania Department of Transportation (PennDOT)
>
> Port Authority Transit (PAT)
>
> Robotics Institute, Carnegie Mellon University
>
> San Mateo Transit (Samtrans)

[Evaluation Report: Driver Experience with the Enhanced Object Detection
System for Transit Buses Final Report]{.underline} dated December 12,
2003, Battelle / TRI

[Transit Bus Frontal Collision Warning System Final Report]{.underline}
dated August 2003, Xiqin Wang, Joanne Lins, Ching-Yao Chan, Scott
Johnston, Kun Zhou, Aaron Steinfeld, Matt Hanson, and Wei-Bin Zhang

[Side Collision Warning System (SCWS) Performance
Specifications]{.underline} dated May 2, 2002 prepared by the Robotics
Institute, Carnegie Mellon University

[Transit Bus Collision Warning Systems Performance Specifications
Interface Requirements]{.underline} (Draft) dated October 25, 2002 by
the California PATH Program, University of California at Berkeley and
the Robotics Institute, Carnegie Mellon University

[Development and Validation of Functional Definitions and Evaluation
Procedures For Collision Warning/Avoidance Systems]{.underline} dated
August 1999, Kiefer, R. J., LeBlanc D. J. , Palmer M. D., Deering R. K.,
and Shulman M. A., NHTSA Technical Report

[Forward Collision Warning Requirement Projects: Refining the CAMP Crash
Alert Timing Approach by "Examining" Last Second Braking and Lane
Changing Maneuvers Under Various Kinematic Conditions]{.underline} dated
, Jan. 2003, Kiefer, R. J., Cassar, M. T., Flannagan C. A., LeBlanc D.
J. , Palmer M. D., Deering R. K., and Shulman M. A., NHTSA

C.  Published Papers

**Publications funded by this program**

*Eye-Safe Laser Line Striper for Outside Use,* C. Mertz, J. Kozar, J. R.
Miller and C. Thorpe

*Multiple Sensor Fusion for Detecting Location of Curbs, Walls, and
Barriers,* Romuald Aufreire, Christoph Mertz and Charles Thorpe

*A 2D Collision Warning Framework based on a Monte Carlo Approach.*
Christoph Mertz

*[Simultaneous Localization, Mapping and Moving Object
Tracking](http://www.ri.cmu.edu/pubs/pub_4664.html),* [C.
Wang](http://www.ri.cmu.edu/people/wang_chieh_chih.html) doctoral
dissertation, tech. report CMU-RI-TR-04-23, Robotics Institute, Carnegie
Mellon University, April, 2004

*Development of the Side Component of the Transit Integrated Collision
Warning System,* Aaron Steinfeld, David Duggins, Jay Gowdy, John Kozar,
Robert MacLachlan, Christoph Mertz, Arne Suppe, Charles Thorpe,
Chieh-Chih Wang

**Previous Publications**

*Dressed Human Modeling, Detection, and Parts Localization,* Thesis for
Liang Zhao (CMU-RI-TR-01-19) July 26, 2001

*Driving in Traffic: Short-Range Sensing for Urban Collision Avoidance,*
Chuck Thorpe, Dave Duggins, Jay Gowdy, Rob MacLachlan, Christoph Mertz,
Mel Siegel, Arne Suppe, Bob Wang, Teruko Yata

*Facts and Data Related To Bus Collisions Interim Report* April 11, 2002

*A New Focus for Side Collision Warning Systems for Transit Buses,* May
2000

*Side Collision Warning Systems for Transit Buses,* Christoph Mertz, Sue
McNeil, and Charles Thorpe

*Side Collision Warning Systems for Transit Buses: Functional Goals,*
CMU-RI-TR-01-11, David Duggins, Sue McNeil, Christoph Mertz, Chuck
Thorpe, Teruko Yata dated 5/14/01

*Simultaneous Localization and Mapping with Detection of Moving
Objects,* Chieh-Chih Wang and Chuck Thorpe

*State of the Art of Technology Part I: General Overview,* Christoph
Mertz dated April 15, 2002

*State of the Art of Technology Part II: Investigation of specific
sensors,* Christoph Mertz dated April 15, 2002

*Static Environment Recognition Using Omni-camera from a Moving
Vehicle,* Teruko Yata, Chuck Thorpe, and Frank Dellaert

*Stereo and Neural Network-Based Pedestrian Detection,* Liang Zhao and
Charles E. Thorpe, IEEE Transactions on Intelligent Transportation
Systems, Volume 1, No 3 September 2000

"*Studies of Accidents and Cost data for Transit Buses*", Kun Zhou,
Wei-Bin Zhang, Gary Glenn, Xiqin Wang, and Ching-Yao Chan, ITS World
Congress, Nagoya, Oct. 2004

"*Development of Requirement Specifications for Transit Frontal
Collision Warning System- Final Report*", Xiqin Wang, Joanne Chang,
Ching-Yao Chan, Scott Johnston, Kun Zhou, Aaron Steinfeld, Matt Hanson,
and Wei-Bin Zhang, PATH Technical Report, UCB-ITS-PRR-2004-14, May 2004

"*Development of Requirement Specifications for Transit Frontal
Collision Warning System*", Xiqin Wang, Joanne Lins, Ching-Yao Chan,
Scott Johnston, Kun Zhou, Aaron Steinfeld, Matt Hanson, Wei-Bin Zhang,
PATH Technical Report, UCB-ITS-PRR-2003-29, November, 2003

*\"A new maneuvering target tracking algorithm with input estimation\",*
Kun Zhou, Xiqin Wang, Masoyashi Tomizuka, Ching-Yao Chang, and Wei-Bin
Zhang, American Control Conference, Anchorage, Alaska, 2002

"*Integrated Multi-Sensor System:* *A Tool for Investigating Approaches
for Transit Frontal Collision Mitigation*", Xiqin Wang, Wei-Bin Zhang,
Scott Johnston, Dan Empey, and Chinyao Chan, ITS World Congress, Sydney,
Australia, 2001

*Functional Analysis of Frontal Collision Warning System*, M. El koursi,
E.Lemaire, Ching-Yao Chan, Wei-Bin Zhang, ITS World Congress, Sydney,
Australia, 2001

"*Studies of Accident Scenarios for Transit Bus Frontal Collisions*",
Ching-Yao Chan, Kun Zhou, Xi-Qin Wang and Wei-Bin Zhang, ITS America
Annual Meeting, Orlando, Florida, 2001

"Scenario Parsing in Transit Bus Operations For Experimental Frontal
Collision Warning Systems", *Ching-Yao Chan, Xi-Qin Wang, Wei-Bin
Zhang*, *IEEE Intelligent Vehicle Conference, Tokyo, Japan, 2001*

**"***Develop Performance Specifications for Frontal Collision Warning
System for Transit buses"*, Wei-Bin Zhang, et al. 7^th^ Intelligent
Transportation Systems World Congress Turin, Italy, November 6-11, 2000

"*Preliminary Safety Analysis of Frontal Collision Aoidance"*, El
Miloudi El Koursi, Chinyao Chan, Wei-Bin Zhang, 3^rd^ IEEE Inernational
Conference on Intelligent Transportation Systems, Dearborn, MI, Oct.
1-3, 2000

D.  Conversion Tables

<table style="width:100%;">
<colgroup>
<col style="width: 23%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 23%" />
<col style="width: 0%" />
<col style="width: 23%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 24%" />
</colgroup>
<thead>
<tr class="header">
<th colspan="5"><strong>ENGLISH TO METRIC</strong></th>
<th colspan="6"><strong>METRIC TO ENGLISH</strong></th>
</tr>
<tr class="odd">
<th colspan="5"><strong>LENGTH (APPROXIMATE)</strong></th>
<th colspan="6"><strong>LENGTH (APPROXIMATE)</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><strong>1 inch (in)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>2.5 centimeters (cm)</strong></td>
<td colspan="2"><strong>1 millimeter (mm)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>0.04 inch (in)</strong></td>
</tr>
<tr class="even">
<td><strong>1 foot (ft)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>30 centimeters (cm)</strong></td>
<td colspan="2"><strong>1 centimeter (cm)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>0.4 inch (in)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 yard (yd)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>0.9 meter (m)</strong></td>
<td colspan="2"><strong>1 meter (m)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>3.3 feet (ft)</strong></td>
</tr>
<tr class="even">
<td><strong>1 mile (mi)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>1.6 kilometers (km)</strong></td>
<td colspan="2"><strong>1 meter (m)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>1.1 yards (yd)</strong></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td colspan="2"></td>
<td colspan="2"><strong>1 kilometer (km)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>0.6 mile (mi)</strong></td>
</tr>
<tr class="even">
<td colspan="5"><strong>AREA (APPROXIMATE)</strong></td>
<td colspan="6"><strong>AREA (APPROXIMATE)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 square inch (sq in, in<sup>2</sup>)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>6.5 square centimeters
(cm<sup>2</sup>)</strong></td>
<td colspan="2"><strong>1 square centimeter
(cm<sup>2</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>0.16 square inch (sq in,
in<sup>2</sup>)</strong></td>
</tr>
<tr class="even">
<td><strong>1 square foot (sq ft, ft<sup>2</sup>)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>0.09 square meter (m<sup>2</sup>)</strong></td>
<td colspan="2"><strong>1 square meter (m<sup>2</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>1.2 square yards (sq yd,
yd<sup>2</sup>)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 square yard (sq yd, yd<sup>2</sup>)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>0.8 square meter (m<sup>2</sup>)</strong></td>
<td colspan="2"><strong>1 square kilometer
(km<sup>2</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>0.4 square mile (sq mi,
mi<sup>2</sup>)</strong></td>
</tr>
<tr class="even">
<td><strong>1 square mile (sq mi, mi<sup>2</sup>)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>2.6 square kilometers
(km<sup>2</sup>)</strong></td>
<td colspan="2"><strong>10,000 square meters
(m<sup>2</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td colspan="2"><strong>1 hectare (ha) = 2.5 acres</strong></td>
</tr>
<tr class="odd">
<td><strong>1 acre = 0.4 hectare (he)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>4,000 square meters
(m<sup>2</sup>)</strong></td>
<td colspan="2"></td>
<td colspan="3"></td>
<td colspan="2"></td>
</tr>
<tr class="even">
<td colspan="5"><strong>MASS - WEIGHT (APPROXIMATE)</strong></td>
<td colspan="6"><strong>MASS - WEIGHT (APPROXIMATE)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 ounce (oz)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>28 grams (gm)</strong></td>
<td colspan="2"><strong>1 gram (gm)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="3"><strong>0.036 ounce (oz)</strong></td>
</tr>
<tr class="even">
<td><strong>1 pound (lb)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>0.45 kilogram (kg)</strong></td>
<td colspan="2"><strong>1 kilogram (kg)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="3"><strong>2.2 pounds (lb)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 short ton = 2,000 pounds (lb)</strong></td>
<td><strong>=</strong></td>
<td colspan="2"><strong>0.9 tonne (t)</strong></td>
<td colspan="2"><strong>1 tonne (t)</strong></td>
<td colspan="2"><p><strong>=</strong></p>
<p><strong>=</strong></p></td>
<td colspan="3"><p><strong>1,000 kilograms (kg)</strong></p>
<p><strong>1.1 short tons</strong></p></td>
</tr>
<tr class="even">
<td colspan="5"><strong>VOLUME (APPROXIMATE)</strong></td>
<td colspan="6"><strong>VOLUME (APPROXIMATE)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 teaspoon (tsp)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>5 milliliters (ml)</strong></td>
<td colspan="2"><strong>1 milliliter (ml)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>0.03 fluid ounce (fl oz)</strong></td>
</tr>
<tr class="even">
<td><strong>1 tablespoon (tbsp)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>15 milliliters (ml)</strong></td>
<td colspan="2"><strong>1 liter (l)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>2.1 pints (pt)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 fluid ounce (fl oz)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>30 milliliters (ml)</strong></td>
<td colspan="2"><strong>1 liter (l)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>1.06 quarts (qt)</strong></td>
</tr>
<tr class="even">
<td><strong>1 cup (c)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>0.24 liter (l)</strong></td>
<td colspan="2"><strong>1 liter (l)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>0.26 gallon (gal)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 pint (pt)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>0.47 liter (l)</strong></td>
<td colspan="2"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>1 quart (qt)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>0.96 liter (l)</strong></td>
<td colspan="2"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>1 gallon (gal)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>3.8 liters (l)</strong></td>
<td colspan="2"></td>
<td colspan="3"></td>
<td></td>
</tr>
<tr class="even">
<td><strong>1 cubic foot (cu ft, ft<sup>3</sup>)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>0.03 cubic meter (m<sup>3</sup>)</strong></td>
<td colspan="2"><strong>1 cubic meter (m<sup>3</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>36 cubic feet (cu ft, ft<sup>3</sup>)</strong></td>
</tr>
<tr class="odd">
<td><strong>1 cubic yard (cu yd, yd<sup>3</sup>)</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>0.76 cubic meter (m<sup>3</sup>)</strong></td>
<td colspan="2"><strong>1 cubic meter (m<sup>3</sup>)</strong></td>
<td colspan="3"><strong>=</strong></td>
<td><strong>1.3 cubic yards (cu yd, yd<sup>3</sup>)</strong></td>
</tr>
<tr class="even">
<td colspan="5"><strong>TEMPERATURE (EXACT)</strong></td>
<td colspan="6"><strong>TEMPERATURE (EXACT)</strong></td>
</tr>
<tr class="odd">
<td><strong>[(x-32)(5/9)] °F</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>y °C</strong></td>
<td colspan="2"><strong>[(9/5) y + 32] °C</strong></td>
<td colspan="2"><strong>=</strong></td>
<td colspan="2"><strong>x °F</strong></td>
</tr>
</tbody>
</table>

![](media/image16.wmf)

![](media/image17.wmf) For more exact and or other conversion factors,
see NIST Miscellaneous Publication 286, Units of Weights and Measures.
Price \$2.50 SD Catalog No. C13 10286 **Updated 6/17/98**