Automotive Collision Avoidance System Field Operational Test Program
FIRST ANNUAL REPORT

13 FLEET VEHICLE BUILD (Task D)

13.1 GM Engineering Development Vehicle

Objectives

The objective of General Motors Engineering Development Vehicle (GM EDV) is to develop, design, implement and investigate a subset of technologies that will be available on the deployment vehicles to be used in the ACAS/FOT Program. These technologies will be evaluated on this vehicle and will go through a down selection process with other technologies being investigated by the partners in the program. The basic technologies being focused on at this time on this vehicle are:

    1. Threat assessment
    2. GPS/Map based path prediction
    3. Evaluating the performance of the Assistware System
    4. Human factors

These technologies are elaborated in different sections of the report and will also be summarized later in this section.

Approach

The GM EDV is a 2000 model year Buick LeSabre that has gone through a significant modification to accommodate all the required instrumentation to investigate the intended technologies. Our approach in building this vehicle consisted of three major steps.

  1. Defining the architecture - This important step consisted of analyzing various architectures and configurations, and finally determining the best approach for this task. Important factors in this determination were:
    1. simplicity and ease of implementation
    2. compatibility with our partnersí architectures
    3. ease of debugging the system
    4. ease of collecting data
  2. Implementing the architecture in the laboratory - However well the test vehicle is designed and built, it is still a very cumbersome and inconvenient environment to debug a system. For this reason, the first step taken in this task was to implement the architecture in the laboratory. The configuration that was intended for the vehicle was implemented on the bench with exactly the same computers, communications scheme, and add-on sensors. However, integrating the vehicle sensors on the bench system is not possible in a laboratory environment.

Work Accomplished

The following has been accomplished on the GM Engineering Vehicle (EDV).

System Hardware

The system hardware was debugged on the bench and made operational. Initially, rudimentary software for the functions performed by each module was integrated with the communications software, to make sure the communications software and processor hardware were working properly. Then, the operation of sensors was verified, although the data provided is not meaningful in this environment.

Before instrumenting the vehicle, necessary electrical and mechanical infrastructure was built to support the system. Electrical upgrades consist of installing a high output alternator in addition to wiring, power and signal, terminals, fuses and various relays. Mechanical upgrades consist of various brackets for computers and sensors, wire and cable routing, modifications to various parts of the vehicle to install subsystems/devices.

The instrumentation was installed in various parts of the vehicle. The grille and the engine compartment contain the radar sensor. The passenger compartment contains the yaw rate sensor, accelerometer, and compass, which are underneath the console. A high head down display (HHDD) is immediately in front of the driver embedded in the dashboard. A speaker for audio feedback is under the instrument panel and is driven by an amplifier in the trunk. Haptic feedback, which consists of a seat vibrator, is embedded into the driverís seat in the lumbar area. The engineering terminal is in the back seat immediately behind the front passenger. This consists of a liquid crystal display and keyboard. A single display and keyboard will support multiple computers in the vehicle. An electronic switch box is installed in the opening between the trunk and the passenger compartment. By pushing the selector switch on this box, it will connect the terminal to the next computer in round-robin fashion.

The trunk is where the majority of the computers and devices are installed. A number of computers with a dedicated floppy disk drive for program loading are permanently installed. A panel with all the signals serves the purpose of a breakout box for observing the sensor signals. The Assistware system, differential global positioning system (DGPS), Class 2 bus to serial converter, and a soundboard with amplifier are all laid out on a baseboard in the trunk. In addition, there is a data acquisition system, which resides in the trunk but will be used on demand in conjunction with a laptop, when needed.

The exterior of the vehicle is used for antennas. The antenna for the compass is hidden in the headliner. The antenna for the DGPS of the Assistware system and the road geometry processor are mounted on the trunk lid. A second DGPS antenna for data truthing in certain tests will be temporarily mounted on the trunk lid.

EDV Architecture

The architecture and block diagram of the GM EDV is shown in Figure 13.1. This architecture is being implemented and built into the vehicle.

Figure 13.1 Architecture of GM Engineering Development Vehicle

Figure 13.1 Architecture of GM Engineering Development Vehicle

The backbone of the system is a CAN bus for communicating between various subsystems in the vehicle. The bus is operating at 500 Kbaud rate and uses an 11-bit identification code for messages. One end of the bus is terminated at the radar, which is at an extreme location physically. The other end is terminated at the Sensor and Driver I/O Processor.

There are a number of processors that share the tasks to be accomplished. Sensor and Driver I/O Processor is the interface between the vehicle, the driver and the system. It is interfaced to in-vehicle production sensors and devices. This is accomplished via two separate paths. First is the Class 2 bus; any sensor information of use to the GM EDV on this bus is monitored and captured. Then interface electronics convert Class 2 messages to RS232 format. Any sensor or device parameter not available on Class 2 bus is directly interfaced. This information is gathered through either discrete digital inputs or an analog to digital converter. Non-production sensors are installed on the vehicle. These are the differential global positioning system (DGPS), compass, longitudinal/lateral accelerometer, steering wheel position sensor, yaw rate sensor. The driver inputs are captured through the steering wheel buttons. The Driver Vehicle Interface (DVI) Unit, consists of a High Head Down Display (HHDD), a soundboard, and seat vibrator.

The Road Geometry Processor is used to determine the road geometry ahead of the vehicle based on DGPS data and maps. It receives the DGPS data periodically through the Sensor Processor and the CAN bus. The maps are permanently stored on the hard disk media in this processor. It generates a data record which defines the path of the road ahead, and this information is placed on the CAN bus to be picked up by the Main Processor.

The Main Processor performs many functions: data fusion, path prediction, target selection, and threat assessment. It receives the data from the radar via the CAN bus, which contains target tracks and additional pertinent information, related to detected targets. It receives vehicle sensor data and road geometry processor output for data fusion to predict the vehicle path. Based on the radar targets and predicted path, it selects the most threatening target. The threat assessment algorithm(s) are performed on this target based on the kinematics of the vehicle, which is monitored by the sensor processor and the target, which is determined from target information.

The radar is directly interfaced to the CAN bus. At power up it requires an initialization message which will be sent automatically by the Delphi Delco Path Prediction Unit. This initialization message configures the radar main processor to transmit the requested data periodically, at a 10 Hz rate.

The Delco Path Prediction Unit, as the name implies, is a stand-alone box which predicts the vehicle path based on vehicle dynamics sensors. In addition, it initializes the radar to the proper mode.

Assistware is a forward vision system that has two functions. First, it has a forward-looking camera and a vision processor to determine the lane marker positions and the attitude of the vehicle within the lane, specifically, offset from the centerline, and the heading. Second, it has a GPS/map module which is capable of building maps as the vehicle is driven around.

The Driver Vehicle Interface (DVI) Unit consists of several devices that alert the driver. A High Head Down Display (HHDD) is directly in front of the driver on the dashboard and, displays various graphics and icons as well as text data. The speaker generates various tones to get the attention of the driver under certain conditions. A seat shaker is the haptic output, which is another mode for alerting the driver.

All processors are connected to a switch box which enables them to share a common monitor and keyboard. The monitor and keyboard are mounted on the back seat for the engineer to control the overall system. Not shown in the block diagram are floppy disk drives for each processor. These features enable easy debugging in the field and downloading of software to the system.

Software Development

An initial version of all the software components of the Engineering Development Vehicle has been designed and coded, and tested in the lab. Currently it is in the process of being installed in the Engineering Development Vehicle for testing and data logging. The software components are:

  1. Program Loader - from solid state non-volatile memory
  2. Real Time Multi-Threading Functions
    1. Interrupt service routines
    2. Resource locking
    3. Time slicing
    4. Pre-emption
    5. Timer services
    6. Intra processor communication functions
    7. Functions to copy data structures between program modules.
    8. CAN bus message definitions and functions.
  3. Asynchronous Serial Communication with External Sensors
    1. GPS
    2. Yaw rate sensor
    3. Compass
    4. Accelerometer
    5. Class 2 gateway for vehicle OEM data
    6. Audio output device.
  4. Map Road Geometry - Extracts forward road geometry from map database.
  5. Data Fusion - Combines instantaneous yaw rate with predicted Map Road Geometry
  6. Target Selection - Selects a target from the Radar target tracks based on host vehicle path and radar track data.
  7. Threat Assessment - Uses vehicle and radar data to compute alert level based on the most threatening target in the host vehicle path.
  8. Driver-Vehicle Interface - Presents the alert level to the driver in visual, audio and haptic form.

Plans through December 2000

  1. Complete the vehicle build
  2. Collect data for individual components / subsystems
  3. Develop and integrate algorithms and software.
  4. Perform system level tests and collect data
  5. Evaluate the system
  6. Enhance functionality, especially time latency of the algorithms
13.2 Prototype Vehicle

Objectives

The objective of building the Prototype Vehicle is to integrate all the technologies developed by the partners in the Program as a precursor to the Pilot Vehicle and finally to the Deployment Vehicles. This vehicle will have the full functionality as required to support the FOT.

Approach

The Prototype vehicle will also be a development vehicle in the sense that all the subsystems that have been verified in a number development vehicles will be integrated. This is not a straightforward task, and will require significant collaboration among the partners to complete.

The approach is similar to that undertaken in the GM EDV, however bench development in the laboratory will be limited because this vehicle has Adaptive Cruise Control (ACC). The emphasis will be on integration rather than development of individual subsystems. In addition, this vehicle will contain a full data acquisition system.

The software system is designed such that most of the software components of the Prototype Vehicle will have been installed and tested on the Engineering Development Vehicle. The exceptions are:

  1. Road geometry from the Vision System
  2. Road geometry from Radar Scene Tracking
  3. Driver-Vehicle Interface with the HUD

Work Accomplished

The architecture and block diagram of the Prototype Vehicle is shown in Figure 13.1. This architecture will be implemented and built into the Prototype Vehicle.

As of June 2000, the following has been accomplished on the Prototype Vehicle:

  1. Obtain the vehicle
  2. Finalize bill of materials
  3. Order components / subsystems
  4. Modify the brake system (first phase)

This architecture is an extension of the GM EDV. The major difference is the addition of the Adaptive Cruise Control, which involves throttle and brake control. The Driver Vehicle Interface is different, mainly in the use of Head-up Display. In addition, the functional mapping of tasks to hardware is unlike the EDV because partners are delivering some of the functions already implemented in hardware modules as black boxes.

Plans through December 2000

  1. Modify the vehicle with mechanical and electrical infrastructure.
  2. Complete the brake control system (second and final phase).
  3. Install add-on sensors.
  4. Install GM computers and subsystems.

Figure 13.2 Task D Schedule, Page 1

Figure 13.2 Task D Schedule, Page 1

 

Figure 13.2 Task D Schedule, Page 2

Figure 13.3 Task D Schedule, Page 2


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