SmartCars and SmartRoads:
Emergency Braking Notification System:
Applying Technology of Wireless Sensor Networks to Automobiles
BY
RICARDO JOSEPH ESTEVEZ
B.S., University of Colorado at Colorado Springs, 2002
A thesis submitted to the Graduate Faculty of the University of Colorado at Colorado Springs
in partial fulfillment of the
requirements for the degree of
Master of Science
Department of Computer Science
2006
This thesis for Master of Science degree by
Ricardo Joseph Estevez
has been approved for the
department of Computer Science
by
| |
|Dr. C. Edward Chow, Chair |
| |
|Dr. Terrance Boult |
| |
|Dr. Sudhanshu K. Semwal |
| |
|Date |
Estevez, Ricardo Joseph (M.S., Computer Science)
Emergency Braking Notification System: Applying Technology of Wireless Sensor Networks to Automobiles
Thesis directed by Professor Dr. C. Edward Chow
This thesis records the research, design, and implementation of a passive safety system prototype that integrates wireless sensor network technology for data sharing between automobiles. The reader will be presented with a technology review and the architecture of a working prototype that exposes the on board diagnostic, or OBD, sensor data for dissemination into a wireless sensor network. The wireless sensor network has been designed to share the lead vehicle’s speed for a trailing vehicle to receive, interpret and issue a passive warning to the driver. This architecture is a foundation for a safety system capable of providing the driver of the trailing vehicle a notification of the lead automobile’s change in speed independent of taillight illumination. A five-minute road test of the prototype provided feasibility of the architecture.
The prototype consisted of two major systems: one for the lead vehicle and another for the trailing vehicle. A custom program for the lead vehicle system requested and received live vehicle speed diagnostics from an integrated circuit board that connected the OBD port on the vehicle to the host PC. The host PC, serving as a bridge to the wireless sensor network, successfully forwarded the vehicle speed to the attached MICA2 mote via the RS232 serial interface. The custom program installed on this mote successfully transmitted the lead vehicle’s speed over the radio to communicate wirelessly to the trailing vehicle. At this point, the trailing vehicle system processed the lead vehicle speed using another custom program installed on the MICA2 mote being carried by the trailing vehicle. This program had the responsibility of interpreting the lead vehicle’s speed and performing a required brake distance calculation to determine if a notification should be sent to the driver. If the calculated required brake distance was greater than the distance between the two vehicles, the driver was notified with the blinking of the red LED on the MICA2 mote. The brake distance calculation required assumptions on vehicle speed, distance, and reaction time to be made for data in the trailing vehicle.
CONTENTS
CHAPTER
I. Introduction 1
II. REVIEW OF THE TECHNOLOGY 3
COMPUTER NETWORKS 3
Wireless Sensor Network Technology 6
TinyOS and nesC 11
Public Transportation Applying Technology 17
Intelligent Transportation System 24
Traffic Statistics 29
Similar Safety Systems 31
III. Physics and mathematics for prototype 37
OBJECTS IN MOTION 37
Brake Distance Formula 40
Applying the Brake Distance Formula 44
IV. prototype implementation and results 46
HOW CAN DATA BE RETRIEVED FROM A CAR’S ON-BOARD COMPUTER? 47
How can the open-source OBD programs be modified for use in this system? 51
What is the maximum distance that a sent radio message can be received? 53
How does communication from PC to sender-mote occur? 54
How is data transmitted from sender-mote to receiver-mote? 56
How is the driver warned of the braking-level? 58
Road test of prototype 59
Custom Programs 63
V. Conclusion 65
TUNING PARAMETERS 66
Expansion of Prototype 66
Final Remarks 67
VI. References 68
TABLES
TABLE
1. Mote Power Consumption 8
2. Mote platform serial communication speed 16
3. 2005 Colorado and national fatality statistic 30
4. 2004 national rear-end statistic 30
5. Safety systems can reduce crashes 31
6. Speed and Velocity 38
7. Time, velocity, and displacement measurements 39
8. Physical properties and assumptions 41
9. Mathematical data for collision-avoidance problem 41
FIGURES
FIGURE
1. Store-and-forward subnet 5
2. OSI Reference Model 6
3. MPR400CB (MICA2) Block Diagram and Photo 9
4. MIB500 Programming Board 11
5. Example Configuration 12
6. Example Module 13
7. TinyOS int specification 14
8. Loop detectors, CCTV, and electronic signs 18
9. Video-based traffic detection by Autoscope 20
10. CDOT Traffic Operator View using Autoscope technology 22
11. Real-time traffic data for TREX travelers 23
12. Website displays electronic road signs 28
13. Michigan red-light runner CAS 34
14. Distance-Time Graph for Objects A – D 39
15. MPH to FPS Conversion 43
16. Prototype Architecture for LeadCar and TrailingCar 47
17. 2006 Subaru as Lead Vehicle 48
18. OBD Port 48
19. ElmScan OBD Reader 49
20. Host PC 50
21. OBD reader software 50
22. SmartCarComm custom program output from OBD 52
23. Initial Road Test using SmartCarComm 53
24. MICA2 mote in vehicle 54
25. MICA2 on MIB500 for Mote-PC Serial Communication 56
26. Lead vehicle hardware configuration 57
27. Trailing vehicle hardware configuration 58
28. Complete Prototype Test Road Test 60
29. 2003 Subaru Outback Trailing Vehicle 61
30. MPH-Time Graph of Highway Test 62
31. Highlight of LED illumination thresholds 62
32. LeadCarC Component Diagram 64
33. TrailingCarC Component Diagram 64
34. Linx Technology 433 MHz Antenna Upgrade 67
35.
CHAPTER 1
INTRODUCTION
Just as computers have entered every nook-and-cranny of homes and workplace, so has the network. The author of this paper believes that the next frontier of networking is the domain of public transportation. Advanced safety systems, both passive and active, can be built that make decisions based on critical vehicle data that travels a wireless network interconnecting all vehicles on the road. These safety systems can be built, and should be built, based on the premise that critical vehicle data already exists on vehicles but the data is not shared. A new level of safety systems can be developed if this data is shared in real-time. This thesis provides literature research and analysis, simulation, and feasibility of algorithms for a passive safety system built upon an architecture of sharing data among vehicles.
A lightweight yet data centric networking technology known as wireless sensor networks (WSN) serves as an excellent candidate for enabling the transmission of vehicle data and interconnecting vehicles. WSN is already providing researchers with remote monitoring capabilities (Ricadela 2005). For example, wireless sensors can monitor the environment and gather measurements such as temperature, light, and seismic readings. These sensing devices, called motes, can self-organize to form a wireless network enabling the radio transmission of their measurements to a central processing unit for aggregation, analysis, and decision-making. In addition, WSN have been used to perform habitat monitoring at Great Duck Island in Maine (Anderson 2002). In another example, implementing WSN allows first responders, i.e. firefighters, to perform risk analysis on a building structure and to track personnel once deployed into a distressed building (Doolin and Sitar 2006) (Chow and Godavari 2003).
The application area of wireless sensor networks is virtually everywhere in the world around us. Without surprise, WSN is a popular topic in the automotive industry. For the government, the data acquired from the wireless sensor networks could pinpoint hazards in the road related to road decay, traffic, and weather conditions. For insurance companies, the data could be used to determine the cause of an accident. And for the consumer, the data could be used to create safety or convenience systems. In this research, advanced safety systems are the focus.
The passive collision avoidance safety system presented in this paper enables a trailing car the ability to determine an emergency or non-emergency braking situation by alerting the driver independent of taillight illumination on the lead car. This is possible because the lead car’s change in vehicle speed has been shared over a wireless network connecting these cars. The working prototype exposes the OBD sensor data for dissemination into a wireless sensor network so that speed change notifications can be transmitted for receiving automobiles to interpret and, if necessary, issue a passive warning, i.e. indicator light, to the driver. This system provides the driver of the trailing vehicle a notification of the lead automobile’s change in speed, namely deceleration independent of brake light illumination. It can be argued that brake lights alone do not provide any gradient of deceleration.
Through simulation and prototype construction, this thesis research will answer the following design and implementation questions regarding the Wireless Sensor Network Emergency Braking Notification System.
1. How can data from a car’s on-board computer be captured?
2. How can the open-source OBD programs be modified for use in this safety system?
3.
4. What is the maximum distance that a sent radio message can be received?
5. How does communication from PC to sender-mote occur?
6. How is data transmitted from sender-mote to receiver-mote?
7. How is the driver warned of the braking-level (slow-down, caution, no hazards)?
The details of the prototype construction that provide answers to these questions will be presented in Chapter 4 after the literature survey.
CHAPTER 2
REVIEW OF THE TECHNOLOGY
In this chapter, the reader is presented an overview of the technology of computer networks and their emergence into the domain of public transportation.
Computer Networks
Without the network, computers would be isolated and the dissemination of information limited. Overcoming this island of computing has led to the continuous linkage of computers to networks and the network’s ubiquitous integration into our daily lives. This section provides an overview of computer networks as described by Tanenbaum in his book, A Computer Networks (Tanenbaum 2003).
The most famous network, which is actually a collection of interconnected networks or internetwork, is the Internet. The Internet, which is the backbone of the most popular distributed system known as the World Wide Web, has closed the geographic gap among people and businesses. It serves as a medium for researching, entertainment, business transactions, and communication (Leiner 1997), and the Internet is the primary reason why many people buy computers.
Types of Networks
A computer network provides a computational need with a large number of separate but interconnected computers (Linux Technology). To be interconnected means to be able to exchange information over some connection such as copper wire, fiber optics, microwave, infrared, and communication satellites. The observation is that the connection medium is both wired and wireless.
Transmission technology and scale are two identifying characteristics of all computer networks. There are two types of transmissions: broadcast and point-to-point. In a broadcast network there is single communication channel to which computer are connected, a packet is sent by any computer and received by all the others on the network. Upon receiving a packet, the machines check if they are the intended recipients. If this condition is true, the machine will process the packet. Otherwise it will ignore the packet. In a point-to-point network, there are multiple communication channels between machines so multiple path routes are possible for packets. A machine on the travel path on this network may not be the intended recipient but, instead, just an intermediate hop for the packet on the way its destination. The second characteristic, scale, is the distance between processors on a computer network. Typically broadcast networks are used for smaller network applications over a specific geographic region. And point-to-point networks are used for larger networks.
The migration of cable TV networks to provide consumers with access to the Internet led to the creation of Metropolitan Area Networks (MAN). MANs are larger than Local Area Networks (LAN) but smaller than Wide Area Networks (WAN). A WAN connects LANs together creating an internetwork.
Network Communication
There are several ways to determine when computers can communication. A static allocation divides time into discrete intervals and uses a round-robin scheduling algorithm allowing each computer to broadcast when its time slot arrives. Recall that the scheduler of this algorithm will maintain a list of computers ready to communicate (Tanenbaum 1992). At any point in time, one computer is communicating for its slotted time, also called its quanta. And when the quantum ends, if the computer has not finished communicating, then it is preempted and placed at the end of the list of computers ready to communicate. This process repeats for the next computer. The tradeoffs in this algorithm are wasted CPU time if a computer has little or nothing to communicate. An algorithm that uses centralized control utilizes a single entity to determine which computer can communicate. In contrast, decentralized control can be used to enable each computer to determine its own time to communicate; this algorithm is used in Ethernet, which is a bus-based broadcast network with decentralized control.
Subnets
Digging deeper into networks reveal subnets. A subnet is the collection of routers and communication lines whose task is to carry messages from host to host connected to the subnet. Subnets are also used for network addressing. The routers decide how packets will move through the subnet. When a packet arrives at an intermediate router it is stored until the output communication line is free, then the packet is forwarded. This algorithm is called store-and-forward or packet-switched. The following figure depicts two computers: the send host and receive host, communication lines, packets, and routers A-D. Note in this example, how router A decides to send to router B not D, and router B decides to send to C not D. The router hop for these packets is A-B-C.
|[pic] |
Figure 1 – Store-and-forward subnet
Services and Protocols
In order for these systems to communicate, services and protocols must be understood. A service is a set of operations that a layer provides to the layer above it. A protocol is a set of rules that describe how messages are exchanges within a layer. The Open Systems Interconnection (OSI) reference model defines how systems can communicate with a set of services, interfaces, and protocols. The OSI model is the popular model for describing how communication takes place between heterogeneous networks.
|Application |
|Presentation |
|Session |
|Transport |
|Network |
|Datalink |
|Physical |
Figure 2 – OSI Reference Model
This is a brief review of computer networks. It is remarkable how a government-funded technology from the Cold War era has matured and entered into the public domain and changed the global economy and how humans interact forever. Detailed information of protocols and an examination of each layer in the OSI reference model can be found in textbooks such as those cited as references for this paper.
Wireless Sensor Network Technology
The promising technology of wireless sensor networks aims to integrate the world in ways that are only possible because of the ever-shrinking size of computing hardware. The wireless sensor network is composed of small, low-powered computers called motes. Motes have the ability to interface and control the attached sensors that are commonly mounted on a sensor board. Crossbow Technology Inc. provides a myriad of hardware to support the WSN technology. Here we introduce the features of the Crossbow MPR4x0 motes (Mote Processor Radio), or commonly known as the MICA2, since they are used in this prototype to facilitate radio communication between the lead and trailing vehicles. The following specifications have been derived from the Crossbow user manual (Crossbow MPR-MIB Users Manual).
MICA2
Crossbow supplies motes as minimal hardware containing a CPU, radio, and a 51-pin connector for sensor boards that allow measurements to be taken such as light, temperature, barometric, acceleration, acoustic, magnetic, and GPS readings for dissemination into the WSN (Crossbow MTS/MDA Sensor Board Users Manual). The data collected is commonly sent to a base station for aggregation so that observations and decisions can be made.
The specialized characteristics of motes, namely their size and power limitations, require efficient hardware, software and networking protocols. The hardware on the MICA2 mote provided by Crossbow uses an Atmel ATmega128L processor. This processor is a low-power microcontroller with 128 kilobytes of onboard flash memory that stores the TinyOS (TOS) and the mote’s program to run. A TOS program can be loaded on the mote to run the sensor application and processing, and network and radio communications simultaneously. The measurements taken on the mote are stored on 512 kilobytes of flash memory.
The MICA2 mote truly runs on low power: 2 AA batteries provide 2000 milliamps-hour of power yet the mote components require only small amounts of this power for operation. The following table provides the power consumption for the mote components.
|Mote Component, Operation |Power Consumption |
| |mA – milliamps |
| |µA – microamps |
|Processor, Full Operation |8 mA |
|Processor, Sleep |8 µA |
|Radio, Receive |8 mA |
|Radio, Transmit |12 mA |
|Radio, Sleep |2 µA |
|Flash Memory, Write |15 mA |
|Flash Memory, Read |4 mA |
|Flash Memory, Sleep |2 µA |
|Sensor Board, Full Operation |5 mA |
|Sensor Board, Sleep |5 µA |
Table 1 - Mote Power Consumption
(Taken from the Crossbow MPR-MIB Users Manual)
If the mote is programmed to sleep when processing is not required the mote can greatly exceed the battery expected life and can run for one year. Recall that the on-board flash memory is non-volatile so even if the power supply is removed, the measurements collected by the mote are not lost. The following figures depict the MICA2 Mote block diagram and actual photo (Crossbow MPR-MIB Users Manual). The MICA2 mote is no bigger than its power supply with dimensions of 2.25 x 1.25 x .268 inches and weight .7 ounces, excluding batteries.
|[pic][pic] |
Figure 3 - MPR400CB (MICA2) Block Diagram and Photo
The block diagram above indicates three components that have not been mentioned: the antenna, flash memory, and LEDs. The MICA2 mote carries the CC1000 RF Transceiver chip for radio communication. The radio frequency used for this prototype is 433 MHz though the MICA2 mote supports 315 and 915 MHz in different configurations. The integrated radio can transmit 38,400 bits per second at a range of several hundred feet. The 433MHz-configured mote, model name MPR410, can span up to 4 channels of operation in this frequency band. Changing the frequency band is done programmatically. The Crossbow documentation states that the actual number of possible channels is higher if the adjacent channel spacing is narrow. But it is recommended to keep the spacing at least 500 kHz to avoid adjacent channel interference. The radio transmission power can also be adjusted programmatically. Related to radio communication is the selection of a proper antenna that provides the proper coverage for the environment the motes will be deployed. The user manual states, “The usual antenna chosen is a length of insulated wire one-quarter wavelength long for the frequency of interest. This type of antenna is often called a monopole antenna” (Crossbow MPR-MIB Users Manual).
Another component on the block diagram above is the Logger Flash. This is the 512 kilobytes of flash memory (AT45DB041) provided by Atmel used to store data and measurements (Amtel). TinyOS uses this chip as a micro file system and it is estimated to hold over 100,000 measurements. For the prototype, the memory is not used but further work of this prototype could integrate a sensor for distance or a sensor for GPS and storage of these measurements could be possible.
The final components to discuss are the three LEDs: yellow, green, and red. These LEDs will be used in the prototype. Red will notify the driver to slow down; yellow to yield; and green as normal conditions.
MIB500/MIB510
Another MICA2 feature used by this prototype is that this mote can serve as a base station when it is connected to a PC. For this prototype, the MIB500 board is used to port the critical vehicle data from the PC to the mote. Note that the MIB500 has been discontinued by Crossbow and it has been replaced by the MIB510.
The MIB500, pictured below (TinyOS Getting Started Guide, 2003), serves multiple purposes: the MICA mote product family can be affixed to this board to load the programs onto the board. Additionally, interfaces to the RS232 serial port are provided to permit communication between the mote and PC. The replacement to the MIB500 is the MIB510, which shares the same multi-purpose features. The primary difference between these programming boards is that programs are transmitted to the affixed mote via the parallel port on the MIB500, and the RS232 serial port on the MIB510. Also, there were many reported problems programming motes with the MIB500 such as “program failure, flash verification errors, and dead Motes…” (Crossbow MPR-MIB Users Manual). The root cause was either low programming voltage and/or UISP programs on the Host PC.
|[pic] |
Figure 4 - MIB500 Programming Board
Thus far, we have introduced the hardware involved in a wireless sensor network. These products are supplied from Crossbow Technologies Inc.; however, there are other manufacturers such as the Moteiv Corporation (Moteiv Corporation) that also provide similar hardware. The commonality between these companies is their support for the TinyOS.
TinyOS and nesC
TinyOS is an open-source operating system specifically designed for wireless sensor networks. Its architecture is component-based which will work as-is or customized. The TinyOS library includes network protocols, distributed services, sensor drivers, and data acquisition tools (UCBerkley 2004). The TinyOS system, libraries, and applications are written in the nesC programming language that is primarily intended for embedded systems such as sensor networks. The prototype safety system will require custom nesC programs to be loaded onto the motes. In order to correctly create a custom TinyOs program the fundamental nesC concepts are reviewed.
The programs loaded onto motes that support the TinyOS platform will run network embedded system C, which in short form is called nesC. This language is C-like and contains specific features for component and concurrency. A nesC application consists of one or more components wired to form an executable application. The components are built from well-defined bi-directional interfaces. This means that a component provider will implement commands for the component users. The component user is required to implement the required events as defined in the interface. The events serve as callback mechanisms. When components are declaring a specification, interfaces are stated. Here are the semantics of the nesC terminology.
• A component can provide and use interfaces.
• A component’s provided interface will provide a set of commands. A component that uses an interface can use these commands.
• A component’s provided interface will provide a set of events. A component that uses an interface’s commands must implement these events.
• A component’s signature is the set of interfaces it provides and uses.
When implementing a component, two types of components will be defined: configurations and modules. A configuration connects the components together; this means to connect the interfaces used by components to interfaces provided by other components. This is known as wiring. The example configuration is provided below.
|configuration MyApp { |
|} |
|implementation { |
|components CompA, CompB, CompC; |
| |
|CompC -> CompB; |
|CompB -> CompA; |
|} |
Figure 5 - Example Configuration
This configuration’s implementation is in the implementation brackets. In the configuration, the arrows (() bind interfaces to one another. On the left side of the arrow is the component that is using the interface of the component on the right side of the arrow, which is the interface provider. The second type of component is the module. A module provides the implementation of one or more interfaces it uses and/or provides. See the figure below for an example module.
|module MyComp { |
|uses interface IFA; |
|uses interface IFB; |
|uses interface IFC; |
|} |
|implementation { |
|} |
Figure 6 - Example Module
The module provides the application code. In the example, module MyComp uses three interfaces IFA, IFB, and IFC. These interfaces will provide a set of commands that will be used to define the behavior of the mote. Because nesC applications are component-based, reusability can be achieved. For example, a new nesC application can be simply created by providing a configuration file that wires two or more existing modules together.
Programming in TinyOS
Compiling a TinyOS program produces a single binary image. A mote only runs one TinyOS image at a time. This image defines the system components and custom components that are needed for this single application. To run the program, the TinyOS manages two threads of execution. The task handler thread of execution schedules a function, and this function will run to completion before the next function is invoked. Specifically, it is not preempted by other tasks. However, a hardware handler thread is running, so hardware interrupts may preempt a task that is running. This is acceptable because a sensor measurement may need to be taken and the TinyOS must be able to invoke a function to handle the hardware interrupt. Race conditions may occur if a hardware event handler accesses the same data of a task that was preempted. Fortunately, the nesC compiler has the capability to report potential race conditions.
Modules can declare state variables whose visibility is private. Worth noting is the TinyOS implementation for the integer scalar data type. TinyOS does not use int because it is platform specific. For example, on the MICA and Telos motes, int is 16 bits, while on the IntelMote2 an int is 32 bits. So TinyOS provides the following signed and unsigned integer specifications. Using these integer definitions, there will be no ambiguity for the bit size for an integer.
| |8 bits |16 bits |32 bits |64 bits |
|Signed |int8_t |int16_t |int32_t |int64_t |
|unsigned |uint8_t |uint16_t |uint32_t |uint64_t |
| |(0-255) | | | |
Figure 7 - TinyOS int specification
Consider a program that uses a uint8_t integer to increment a counter. Negative values would not exist because this integer is unsigned. Therefore, increments would change the counter value from 0(1(2(3… with an upper boundary of 28 or 255.
The relationship between interfaces, commands, and events can become a little confusing, so here we return to these nesC concepts. If a component uses an interface, it can call the commands of this interface so long as the events of this interface are implemented. Commands are used with the call keyword. Events are used with the signal keyword. The event is a callback mechanism to the component user when the component provider invokes the event statement. Because nesC is based on the C programming language, a standard C function may be defined to and used internally.
Inter-mote Communication
TinyOS provides components with interfaces that provide a course-grained interface to the radio communication hardware. These interfaces are implemented by specific hardware platforms, which range from manufacturer to manufacturer.
The message_t type is the TinyOS 2.0 message buffer. It can be sent and received by the radio. TinyOS 1.x used TOS_Msg. Improvements to the TinyOS 1.x message buffer provide better encapsulation by making the members of this struct private. Here are some of the important interfaces in the tos/interfaces directory.
• Packet.nc provides the basic accessors and mutators for the message_t abstract data type.
• Send.nc provides a message-sending interface. It has commands for sending the message and to cancel a pending message to be sent. There is an event to indicate the success of a message send.
• Receive.nc provides a message-receiving interface. There is an event that can be used when a message has been received.
• PacketAcknowledgements.nc provides a mechanism for enabling and disabling message acknowledgements.
• RadioTimeStamping.nc provides an interface for receiving time stamp information from the radio. This information is also embedded in the packet metadata.
The wireless mote communication requires multiplexing, which is the technique to combine many signals into a single transmission circuit of a channel. TinyOS provides the Active Message (AM) layer to multiplex access to the radio.
TinyOS provides a special network integer data type that takes care of endian type resolution. The issue arises when various hardware platforms are used when transferring data. The byte accessing is different because of the endian type. Recall, in big endian systems that the most significant byte is at the higher memory address, while in little endian systems, the most significant byte is at the lower memory address. This network type is used for the transmission of vehicle speed over the wireless sensor network. The implementation of the prototype has proved that this value can be preserved from a PC-based hardware platform to the MICA2 mote hardware.
Mote-PC Communication
The basic abstraction for mote-PC based communication is the packet source. A packet source is a communication medium that is used to transmit packets between the motes and PC. Serial ports, TCP sockets, and the SerialForwarder are various mechanisms that support mote-to-PC communication. The transfer of data from the PC to a mote connected on the wireless sensor network was critical to sharing the vehicle speed data from the lead vehicle for propagation onto the wireless sensor network. It is here that the mote installed on the trailing vehicle could receive the network data for interpretation by its embedded safety algorithm.
The packet source is defined with syntax serial@: where PORT depends on the hardware platform. For Windows and Cygwin platforms, COMN is used, and for Linux and UNIX machines, /dev/ttySN is used. SPEED is defined as a numeric value or using the mote platform. Example platform speeds are provided below. For the prototype, the packet source was defined as serial@PORT6:mica2.
|Platform |Speed (baud) |
|telos |115200 |
|micaz |57600 |
|mica2 |57600 |
Table 2 - Mote platform serial communication speed
The sending program on the PC can be written in either C or Java. Recall that this program will be sending data to an attached mote over the serial port. The attached mote is expecting information but the data must be wrapped into the packet structure that is defined in the nesC program. To allow the nesC program and the host PC program to be implemented using the same packet structure, TinyOS provides several features. The first are a set of Java and C libraries that implement the low-level serial communication details, in addition to the message interface generator (mig) process. The mig process is able to generate a Java or C implementation of the packet struct definition contained in the nesC program header file. The mig process was used to create a Java class representation of the car data packet that was to be populated with the vehicle speed and transmitted to the mote from the PC via the serial port interface.
The documentation of the TinyOS and nesC capabilities are important to provide the reader with detail on how the wireless sensor technology will serve as a strong foundation for supporting safety systems which depend on the ability to exchange and interpret vehicle data available on an inter-car wireless sensor network.
Public Transportation Applying Technology
Public transportation is a domain area that many researchers have been examining for the full-scale integration with wireless sensor networks. Here we examine the existing studies that are applying technology to the field of public transportation. The primary purpose for the inclusion of the following studies is to emphasize that the focus for transportation to include wireless sensor technology is for remote traffic monitoring rather than safety, which is the focus of this thesis.
Coil Loops
Our states’ departments of transportation have a traffic monitoring system utilizing a technology that is dated and expensive. However, expensive efforts are being made to upgrade. Here we examine a common traffic monitoring system as well as a system that uses cellular technology for wireless communication (Bonsor).
The states’ departments of transportation use underground loop detectors and intersection video cameras to monitor traffic. The loop detectors are underground and can detect a passing vehicle based upon the small changes in electrical voltage. A simple count can be done to approximate traffic volume. Measuring the time it takes for vehicles to pass between two loop detectors can approximate the speed of traffic. A simple count can be done to approximate volume. This information is then related to a central computer for traffic monitoring. Together, this system works with a human in the loop. Final dissemination of the traffic data can be placed onto electronic signs on the road. The problem is the cost of running this system. A DOT worker increases the cost of this system plus the effort to embed the loop detectors and large electronic signs. Below is a figure that show the common traffic detection and notification technology.
|[pic] [pic] [pic] |
Figure 8 - Loop detectors, CCTV, and electronic signs
Loop detector technology is expensive. In April 2001, the city of Colorado Springs, Colorado began replacing the underground loop detectors at 420 intersections (Kenny 2003). Since each intersection had an average of 24 loops, the entire system contained over 10,000 loops. Approximately, twenty percent of the loops fail, so 2000 loops would need to be fixed at the cost of $500. The mathematics reveals that yearly maintenance would cost $1,000,000 if loops continued to fail at a rate of 20 percent. After this realization, the city decided to replace the loops with video detection cameras. The camera installation cost per intersection averaged $13,000, which is actually more than the loop detectors. But the expectation of higher reliability and lower maintenance costs made the video detection cameras the better choice.
Cellular Technology
In 2001, a company named Cell-Loc was testing a vehicle tracking system for drivers with cellular phones. This was achieved using triangulation calculation that requires three listening posts. Each listening post detects the emitting radio signals, and then together the posts can determine the cell-phone position and thus the vehicle. In a test, the Cell-Loc system was used to track a single vehicle for 1.25 miles. This vehicle was also equipped with GPS as a control variable. At the end of the experiment, the paths were compared. The Cell-Loc was accurate within 330 feet 67 percent of the time and within 990 feet 95 percent of the time. Also, tracking cell phone within cars would enable more data points for traffic monitoring. Lastly, if vehicles were tagged, then additional data points would be collected as cars passed by a reading device. This advanced system would have a database where this information would be aggregated. A traffic monitoring system used in conjunction with Cell-Loc and tagged vehicles would allow cell-phone users to receive customized traffic reports. Additionally, this data could be provided on a Web site for trip planning.
The vehicle tracking experiment using the cell-phone provided data seemed to have a large error margin, 990 feet, which seems quite large when tracking vehicles. Still, this test has provided insight on the outcome of using cellular technology.
Video Detection System: Computer Vision
The transportation departments are also implementing newer above ground traffic detection systems. Autoscope, which uses advanced video technology to collect traffic data, is a popular candidate for above ground solutions.
Image Sensing Systems, Inc. has been the provider of video vehicle detection since 1984 (Imaging Sensing Systems 2006). Today, they provide Autoscope technology, a computer vision system to detect vehicles. Measurements such as traffic volume, speed, density, occupancy, and headway are collected for analysis at a traffic control center. Their system is aimed to replace or complement belowground loop detectors. As mentioned before, the loop detectors are an old, expensive technology that is not easily replaced or easily configured because they are in the ground. Video detection is aboveground and is more cost-effective because maintenance can be performed such as reconfiguration of detectors during road constructions. See picture below of an Autoscope camera.
|[pic] |
Figure 9 - Video-based traffic detection by Autoscope
Traffic volume can be calculated because vehicles can be counted and their speed determined with use of the camera. A real-world implementation in France proves the versatility of the Autoscope product. Here the product is used to detect traffic queues in a rural area of France where neither power lines nor communication lines exist. When the system detects a queue of vehicles, a radio signal is sent to a traffic control center where an operator is alarmed of the traffic situation. Next, alternate route messages would be broadcasted to avoid gridlock.
Autoscope provides a more economic alternative for traffic detection because it is installed aboveground which eases maintenance, and its support for IP-based communication enables reuse of standard transmission protocols. The Denver TREX project uses Autoscope for traffic monitoring along the I-25 and I-225 corridor.
Denver TREX Project
The Autoscope products are used for traffic management in Denver for the Transportation Expansion Project, commonly known as the T-REX Project (Anderson and Candey 2003). The $1.67 billion project is widening Denver’s interstate arteries I-25 and I-225 so that the Regional Transportation Department (RTD) Light Rail can run along side the highway carrying passengers from the suburbs into the city center for work and recreation.
One of Autoscope’s goals is to network their traffic sensors so that monitoring can be done remotely from a traffic-monitoring center (TMC) or virtually anywhere such as an Internet café. This is possible because the Autoscope video detection system supports IP-based communication. IP-based remote monitoring is achieved by using Ethernet-Serial adapters from Comtrol Corp and Digi International. The adapter provides a driver for a host computer to communicate to a remote serial port as if it is physically connected to the computer. This enables legacy traffic monitoring systems to be joined with new technologies—all supporting the remote monitoring capability.
There are over 300 Autoscope sensors, similar to the figure above, deployed throughout the I-25 and I-225 construction area. The sensors measure traffic to support the publishing of traffic information to the public for route planning. Twenty-five (25) percent of the deployed Autoscope sensors use solar power and the remaining use a fixed power source. The power requirement for each sensor is a solar array supplying 12-to-24 volts of alternating current (VDC) or 24 volts of alternating current (VAC) when connected to a power grid. All sensors use cellular communication to send data to the TMC. This communication is achieved by connecting each Autoscope sensor to the AirLink Raven II, which is a full-duplex cellular digital packet data (CDPD) modem. The transmission is provided by AT&T wireless. The CDPD modem provides a data rate up to 19.2 kbps. This is slow; however, the T-REX project wanted to stand up remote traffic monitoring without the cost of digging trenches for fixed line IP-based transmission. The latency in this system is compensated with custom software programs. At the TMC, each modem’s data is sent to a central repository. Different software programs can query the repository to aggregate this data to determine traffic volume, speed, slow and fast intersections. See the figure below for the TMC operator view using the Autoscope Network Browser. The TMC operator can examine traffic data such as volume and current traffic speeds.
[pic]
Figure 10 - CDOT Traffic Operator View using Autoscope technology
Real-time traffic information is also made available on the TREX project website. A simple visual system of red, yellow, and green colors indicates the level of congestions where red is heavily congested (T-Rex Project Website 2006). The following figure shows low levels of congestion on the I-25 corridor during a Sunday afternoon in Denver.
[pic]
Figure 11 - Real-time traffic data for TREX travelers
The TREX project’s support for traffic monitoring is comprehensive for both traffic operators and travelers. The technology used in Denver is more economical because installation was aboveground and the IP-based cellular transmission avoided high costs of installing cable alongside the construction site.
This section has reviewed the existing loop coil and closed circuit television technologies, which are still active on our roadways. These systems work but their maintenance costs are expensive. The attractive replacement for intersections is video cameras, which have advanced technology to detect traffic using an algorithm of computer vision. The cameras are more configurable and easily maintained because they are installed above the ground. The Denver TREX project installed over 300 cameras in preparation for the road construction to minimize the inconvenience to travelers by providing real-time traffic data and reports. Some of the cameras use solar energy for a power source and could also transmit its data using cellular communication.
Intelligent Transportation System
This thesis examines advanced safety systems that can be built upon a wireless network between cars. It is appropriate to examine how this relates to the federal Intelligent Transportation System program. In this section, an introduction to the ITS program, some of its key initiatives, and its role in Colorado are provided.
Overview
The Intelligent Transportation System (ITS) program is a federal initiative to improve the safety and economics of public transportation using advanced communication technologies (USDOT Intelligent Transportation System). The ITS program belongs to the United States Department of Transportation (USDOT). The focus is the development of two components: intelligent vehicles and intelligent infrastructures for the creation of an overall intelligent transportation system that integrates the two components. Between the two components, there are 16 types of supporting technologies that the ITS program defines. The distribution of the technologies is provided next.
Intelligent Infrastructure and Intelligent Vehicles
An intelligent infrastructure requires applications that provide arterial management, freeway management, transmit management, incident management, emergency management, electronic [toll] payment, traveler information, information management, crash prevention and safety, roadway operations and maintenance, road weather management, commercial vehicle operations, and intermodal freight. The details for each of these applications are outside the scope of this thesis but at a high level the focus is the aggregation of traffic data for analysis, management, and dissemination.
The intelligent vehicles component of the ITS require three safety systems: collision avoidance, collision notification, and driver assistance. Collision avoidance systems will use sensors to monitor the vehicle’s surrounding so that the driver can be alerted if a collision could occur. Some examples are forward collision warning and road departure warning systems. The ITS program has documented several interesting studies regarding the intelligent vehicles component and collision avoidance systems. These are federal studies (USDOT IVI 2002) known as Vehicle Infrastructure Integration (VII) and Integrated Vehicle Based Safety Systems (IVBSS).
The VII initiative concept of operations will use vehicle-vehicle and vehicle-road communication that would lower the rate of accidents resulting from roadway departures and at intersections. The ITS states that 21,000 of the 43,000 annual deaths occur because of roadway departure and intersection related incidents. The concept of operations would enable a vehicle to send and receive message to the devices on the roadway and intersections. This could prevent accidents and supply more data for traffic analysis.
The IVBSS initiative concept of operations will embed multiple sensors in vehicles to provide warnings of hazardous conditions to the driver. The IVBSS study investigates on the best way to communicate these warnings to the driver and test plans for prototype safety systems. The scenarios the IVBSS addresses are read-end, run-off-road, and lane change crashes. For rear-end collision avoidance, a proposed safety system will be able to detect objects in front of the vehicle and react by initiating vehicle brakes. The technologies that can be leveraged are GPS, forward looking radar, and cameras onboard the vehicle. For road departure collision avoidance, a proposed safety system will be able to detect road geometry in order to give warnings to the driver if the vehicle is deviating from the lane of travel. Finally, to avoid lane change and merge collisions, a proposed safety system that can detect the presence of adjacent vehicles could warn the driver during a lane change maneuver. Sensors that could detect vehicles are forward, rear, and side-looking radar and vision-based cameras. The challenge of the three avoidance systems is to avoid false alarms and driver confusion regarding the warnings from these systems.
The goal of the ITS program can be paraphrased as a guidance of functions and data flows, namely an architecture and standards, that are required to be implemented to be a contributor to the nationwide intelligent transportation system. The ITS program also provides a wealth of research and development efforts to develop safety and traffic detection prototypes. While some implementing technologies are defined by the ITS program, such as Dedicated Short Range Communication (DSRC), other technologies are being created independently. This permits the greatest flexibility for newer implementing technology so long as the solutions meet the requirements stated in the ITS architecture.
DSRC
The ITS program has established a radio communications standard (USDOT DSRC 2003) that can be used for specifically for vehicles. Dedicated Short Range Communications (DSRC) is a frequency band that has been allocated by the Federal Communications Commission (FCC) for high-speed communications vehicle-to-vehicle and vehicle-to-road. The range of transmission is 1000 meters. Usage of DSRC may provide numerous safety and traffic management systems such as “intersection collision avoidance…approaching emergency vehicle warning…[or] electronic parking payments” (USDOT DSRC 2003). DSRC is currently being used for electronic toll collection at a frequency of 915 MHz, however the FCC authorized a higher transmission rate in October 1999.
The new 5.9 GHz frequency band has less interference only sharing communications with military radars and satellite communications systems. Unlike the 915 MHz band, which shares communication channels with garage door openers and cordless telephones.
The DSRC communications standard has been established by the American Society for Testing and Materials (ASTM) in cooperation with the Institute of Electrical and Electronic Engineers (IEEE). These standards are documented fully in the specification documents titled ASTM E2158-01 (915 MHz) and ASTM E2213-02 (5.9 GHz). (To be noted, these ASTM standards are submitted to the FCC by ITS America for authorization to use the proposed frequency band.) The 5.9 GHz implementation extends IEEE 802.11a, which is the standard for wireless LANs. This will permit easier integration of DSRC applications into a wireless LAN environment.
The Michigan Department of Transportation (DOT) is testing the usage of DSRC to notify drivers of approaching emergency vehicles or construction zones. This project is called DIRECT, which is an acronym for Driver Information Radio using Experimental Communication Technologies. The warning system requires that vehicles are equipped with a DSRC device that can transmit and receive messages from other DSRC devices. Notification of drivers would occur when an approaching emergency vehicle broadcasts its location and direction of travel. Drivers can also be notified for approaching construction zones or route planning however, emergency broadcasts would take higher priority. The Intelligent Intersection Traffic Control Laboratory (IITCL) is also testing safety systems (Turner-Fairbank), which uses DSRC for collision avoidance at intersections. The IITCL is one of 24 laboratories at the Turner-Fairbank Highway Research Center (TFHRC), which is managed by the Federal highways Administration (FHWA) office.
It is a good idea for the ITS program to establish a reserved communications travel for vehicle communication because it will be guaranteed that the only radio traffic will be from DSRC systems.
Colorado Department of Transportation and ITS
At the national level, the ITS program provides an architecture, standards, and funds research studies on creating an intelligent public transportation system. Nationally, a system will be created as a direct result of each state implementing the ITS architecture. In Colorado, the implementation is well underway.
The Colorado Transportation Management System (CTMS) was the project of 2003 and included the deployment of dynamic message signs, closed circuit television, and system improvements on I-70 at the Hanging Lake Tunnel on I-70. Another project deployed the communication lines required to disseminate traffic data. Currently, the T-REX construction project is using technologies, i.e. Autoscope video detection, backed with the ITS architecture to provide traffic planning to DOT operators and travelers.
When Colorado travelers go to the web page to get update-to-date travel information on Colorado roadways, this is the work of the CTMC Advanced Traveler Information Unit (ATIU). The second unit of the CTMC is the Advanced Traffic Management System (ATMS).
The ATIU disseminates traffic data to the public about Colorado interstate and highway systems. Information is supplied by the ATMS, which uses data collected by Colorado State Patrol reports, closed circuit cameras located on roads, and traveling probe vehicles. The probe vehicles can communicate with an ATIU Public Information Officer (PIO) to provide embedded reporting of traffic data. The data is shared to the public using a Broadcast Fax System, which sends reports to more than 200 customers in less then 10 minutes. This report contains road and weather reports for more than 100 Colorado cities. In the winter, this report is issued 4 times daily and in the summer once daily. The public can also receive reports using the Voice Mailbox System Telephone Hotline. The telephone number is free and available statewide and permits the public to select a state or regional report of traffic, road, and construction information. The PIO also shares this information with the television and radio media so the reports can be broadcasted on these mediums. Finally, the website is supplied the same report data. Here the traveler can easily access traffic and road condition data from all across state. An interesting feature, shown below, is to the ability to read the messages that are currently posted on the electronic road signs.
|[pic] |[pic] |
Figure 12 - Website displays electronic road signs
The ATMS monitors the traffic data and responds to incidents on the Colorado roadways seven days a week and 365 days a year. The ATMS is also the source of the critical data that is sent to the ATIU for public notification. The AMTS gathers its data using a smorgasbord of sources such as Denver police, media reports, helicopter units, and commercial passenger carriers. The ATMS operators dispatch the Mile High Courtesy Patrol with the mission to provide immediate incident support. The Patrol is composed of 16 recovery vehicles that can help remove minor accidents and stalled vehicles quickly so that traffic delays are minimized. The Patrol even carries spare fuel to move a stalled car along. The technology used to collect the data includes the following: closed circuit television, inductive loops, weather sensors, dynamic message signs, and advanced software that detects incidents.
The Colorado Transportation Management Center employs major components of an intelligent infrastructure system, which is a system in the making. The two basic units of the CTMC are the Advanced Traffic Management System and the Advanced Traveler Information Unit. These units have the goal of collecting the traffic and road data, and sharing the data, respectively.
TRAFFIC STATISTICS
In this section, statistics for motor vehicle crashes provide evidence that accidents truly impact the health and well being of more people than just what is announced on the news. It is this author’s hope that newer safety systems based on the principle of sharing vehicle data such as demonstrated in the prototype can reduce the number of injuries and fatalities that occur during motor vehicle operation. In fact, the National Highway Traffic Safety Administration, NHTSA, has conducted studies that forecasts the positive effect newer safety systems would have on crash statistics. These are presented at the end of the section.
The 2005 statistics for fatalities in Colorado motor vehicle accidents (NCSA Co. Toll of Motor Vehicle Crashes 2005) are provided by the National Center for Statistics and Analysis (NCSA) of the NHTSA. Colorado accounts for 1.4 percent of the nation’s fatalities.
|2005 |Fatalities |
|Colorado |606 |
|US |43,443 |
Table 3 - 2005 Colorado and national fatality statistic
The following table is an excerpt from the 2004 Final Traffic Safety Facts Annual Report, which provides statistics on the number of rear-end crashes in the United States in 2004 (NCSA 2004). The number of fatal rear-end events was 2083 people, and over 500,000 people were injured.
[pic]Table 4 - 2004 national rear-end statistic
The trends in rear-end collisions that have been observed by the ITS Intelligent Vehicles Initiative (USDOT IVI 8 Major Problem Areas) are that rear-end collisions account for one in four crashes or over 1.5 million crashes a year. The NHTSA has estimated that driver warning systems would be effective in preventing nearly 50 percent of rear-end crashes or 759,000 crashes each year.
Lane change and merge collisions account for 1/25 crashes. Ninety percent are caused by lane changes and ten percent are caused by merges. A safety system that could detect neighboring cars positions could benefit 192,000 of the 200,000 lane change and merge collisions each year.
For vehicles that depart the road completely, a system that could warn the driver if the vehicle is leaving the lane or direction of travel could reduce the statistic that one in five crashes result from a roadway departure. NHTSA estimates that a safety system has the potential of preventing approximately 458,000 of the 1.2 million crashes each year. A summary chart of these statistics has been provided below.
| |Number of crashes |Number of crashes reduced with safety system |
| |without safety system | |
|Type of Collision |Numeric Value |Proportion Value |Numeric value |
|Rear-end |1.5 million |50% |759,000 |
|Lane change/Merge |.2 million |90% lane change |96% |192,000 |
|collisions | | | | |
| | |10% merges | | |
|Road departure |1.2 million |38% |458,000 |
Table 5 - Safety systems can reduce crashes
In summary, travel on our nation’s roadways can be very dangerous. The reality of this danger is indicated in the statistics provided in this section. Variables such as gender, age, automobile type leads to more statistics. Further examinations of these other statistics are left as a study outside of this paper.
Similar Safety Systems
This section presents several different safety systems that are the most similar in idea to the safety system provided in this thesis research. Studies by the universities and car manufacturer below share the common characteristic of inter-car communication and sharing data to create software systems that will benefit the traveler. The differences between each study and the study of this paper are provided at the end of each system review.
CarTel at MIT
The CarTel project (Balakrishnan and others) at the Massachusetts Institute of Technology believes that with hundreds of millions of vehicles on the road and over a billion people using cellular phones, “cars and humans may turn out to be the carriers of the world’s largest and most dynamic sensor networks in the coming years.” This project has designed and deployed a mobile distributed sensor computing system. The system has a three-tier architecture, thus creating a layer for the database, business logic, and client. Conceptually, the system works as follows: the client layer presents a thin-client portal where asynchronous queries can be sent to the mobile sensor nodes deployed on a vehicle. The network on which these queries travel is designed to be delay-tolerant since the sensor nodes create the mobile network. When the query reaches the mobile sensor node, it provides the query along with the parameters, such as response priority, so the data collected can travel back through the network with assigned priority and destination. Finally, the data returns and is inserted into a relational database where another client application can view statistics visually with map data. As innovative as the CarTel project is, it still lacks the investigation of safety systems that will benefit the automotive industry. Instead, the project focused usage for their system is traffic monitoring and route planning; preventive maintenance; road condition monitoring; or a proxy monitoring service for other wireless networks.
The CarTel project focused on efforts similar to environmental monitoring; here traffic monitoring. MIT’s solution does not use the TinyOS. Rather than creating the wheel twice, this thesis focuses exclusively on the application of the wireless sensor networks built upon mote hardware that support the many powerful features of the TinyOS. This allows efforts to be focused on creating innovative safety systems using existing technologies.
Sengupta at UCB
At the Department of Civil and Environmental Engineering, UC Berkeley professor Raja Sengupta is developing a car safety system that relies on GPS and WiFi technologies (Pescovitz 2006). The premise to use these technologies is that the decreasing cost will enable safety systems to be built more cheaply and the distribution will be widely accepted because of low installation costs.
Previous safety prototypes rely on expensive sensor-based system that use cameras and radars that costs thousands of dollars to implement, which is hardly economic for the consumer. Sengupta’s system shares the data gathered by a GPS-enable vehicle to neighboring vehicles. Data such as direction, location, and velocity can be used to detect and warn the driver of a possible collision. The driver is warned with a visual or audible alert.
This system faces some challenges such as error correction algorithms for lost data and scalability when speed and volume increases. The GPS download for data occurs every 100 milliseconds. This time needs to be added to the WiFi transmission time for the total time to deliver the message to nearby vehicles. Another concern is security to ensure that data transmitted of WiFi is a vehicle and not a hacker or malicious program that is disrupting the safety system. Lastly, this system relies on all cars carrying this system.
Sengupta’s prototype is similar conceptually to the prototype in this thesis. Sharing critical vehicle data is key to constructing intelligent warning systems. The prototype in this thesis could be bolstered to use GPS. If so, it will face the same latency for GPS downloads.
Honda
In Japan, Honda is already testing the integration of advanced safety systems into cars and roads (Woodyard 2005). Their prototype safety system features the capability to allow a car to send and receive signals from other cars and the road. Such signals could warn of road hazards; a red-light runner at a traffic light intersection; school zone warnings; and traffic data.
Motorola in Michigan
In Michigan, a collision avoidance safety system prototype is being tested using technologies supplied by Motorola (Dizikes 2006). This system requires sensors in cars and transponders on poles.
In a two-car scenario, the lead car slams on the brakes and an onboard computer system enabled with GPS and a short-range radio broadcasts a warning to the trailing car. The trailing car receives the warning and uses GPS readings to determine that the driver be notified with a chime and flashing red light.
In another test, the Michigan DOT has deployed transponders made by Azulstar on light poles at traffic light intersections. These transponders can broadcast its GPS position and traffic light state (red, yellow, green) for approaching vehicles to receive; in turn, the vehicle responds with its own known speed and location for the transponder to determine if a red-light running condition is imminent; if this condition is true than nearby vehicles are notified. See figure below.
|[pic] |
Figure 13 - Michigan red-light runner CAS
Similar to the premise in this thesis, the Motorola study realizes that the computer in cars today track critical vehicle data that can be shared in order to avoid accidents. This system is different in implementation because it relies heavily on GPS. This study has also shown that cellular communication is not fast enough to transmit data and the usage of the FCC DSRC radio frequency is preferred because it is optimized for high-speed short-range communications.
GM Vehicle-to-Vehicle System
Last year, General Motors demonstrated their collision avoidance system using the Cadillac STS sedan as their test vehicle (Olsen 2005). Their safety system relies on vehicle-to-vehicle wireless communication to determine potential collision conditions and provide a visual indicator and physical stimuli to alert the driver.
The GM safety system works using GPS and the DSRC protocol. Recall, the DSRC protocol is a direct result of the federal ITS program to establish a frequency band that supports high-speed communication for intelligent vehicles. The GPS antenna is mounted on top of the vehicle and receives satellite information on the positions of other vehicles. Another antenna uses DSRC to broadcasts its own data such as speed, braking, and turn-signal indicators. Any vehicle within a quarter-mile radius can receive the broadcast and perform calculations for usage in its safety algorithms. GM addresses the privacy issue by not including any personal information, such as Vehicle Identification Numbers, in the broadcast.
In order to determine collisions, GM has created a proprietary algorithm that is constantly calculating other vehicle’s positions and speeds in coordination with the host vehicle position and speed in order to provide warnings to the driver. The warnings provided to the driver are in the dashboard and changes from green, to yellow, and to red if the distance between vehicles are decreasing to a point of possible collision. GM also vibrates the driver seat when the red indicator is flashing.
The GM collision avoidance system is a passive and active warning system because it can override the driver’s input in order to stop the car in an emergency situation. This type of system concerns drivers in the event that the safety system makes the wrong conclusion or the driver is never able to regain control of the vehicle.
A passive warning system will be the more widely accepted because the risk is significantly less. GM, similar to this author, believes that sharing information between vehicles will eliminate the need for independent and expensive radar technology similar to those currently in use in some luxury cars’ adaptive cruise control. The smarter cruise control can adjust a vehicle’s cruising speed in response to slower traffic.
In conclusion, the reader should observe that studies and prototype safety systems are heavily underway. An active safety system raises many more concerns specifically if it falsely predicts a collision. A passive safety system will face the challenges of ergonomics; that is, visual or auditory warnings and placement on the dashboard.
CHAPTER 3
PHYSICS AND MATHEMATICS FOR PROTOTYPE
Basic laws of physics must be examined to properly understand the collision avoidance problem. In this chapter, simple concepts are reviewed to understand the mechanics involved in a rear-end collision that involves two vehicles. This analysis is necessary in order to build algorithms that safety systems will implement to provide drivers with smarter and advanced notification of an impeding accident.
Objects in Motion
The motion of objects can be described using mathematical quantities (Henderson), e.g. speed, velocity, and acceleration. These quantities are categorized into two categories: scalar and vector quantities. A scalar value is described with magnitude, while a vector value is described with magnitude and direction. So when a vehicle is traveling at 60 miles/hour, or converted, 96.56 kilometers/hour, several mathematic observations can be made. First of all, the moving vehicle has the property of speed. Speed is a scalar quantity, which refers to how fast an object is moving. An object that is not moving has zero speed. Assuming that the vehicle that is traveling at 60 mph is not on a dynamometer, it is most likely moving towards a destination. In other words, it has a direction such as West, which means that the vehicle now has the property of velocity. Velocity is a vector quantity, which refers to the rate at which as object changes its position. If this example vehicle doesn’t change it’s speed and direction for two hours, then it would have traveled a distance of 120 miles.
|Speed |Velocity |
|60 mph |60 mph, west |
Table 6 - Speed and Velocity
A vehicle’s speedometer is a reading of instantaneous speed. The opposite of instantaneous speed is average speed, which can be observed at the end of a road trip where it is likely that a vehicle’s speed has varied from moment to moment. The calculation is no more challenging than dividing the total distance traveled by travel time.
Acceleration
Any vehicle traveling through the city will undoubtedly encounter traffic. When the vehicle is speeding up or slowing down, its velocity is changing due to acceleration. Acceleration is a vector quantity, which refers to the rate at which an object changes its velocity. Recall that velocity is the rate at which an object changes its position. These values are not the same, but they are related. Acceleration is a vector quantity so it has direction. For a vehicle that is speeding up westward, its velocity and acceleration vectors are in the same direction westward. However, a vehicle that is heading west and is slowing down has a westward velocity vector and an opposite eastward acceleration vector. In other words, it is decelerating.
Here a few examples are provided. A vehicle traveling at a constant velocity 100 mph, west for a duration of time is indeed traveling westward fast; however for this time interval it has no acceleration. This is because its velocity is not changing. Two more scenarios of acceleration are presented as tables and graphs. The velocity units are feet/second west and the time units are seconds. See graph on next page.
|Time |Vel |
|Number of vehicles |2 |
|Braking ability |Equal for both vehicles |
|Weight |Equal for both vehicles |
|Grade |None, i.e. flat |
|Road conditions |Normal, i.e. dry |
|Heading |Equal for both vehicles |
Table 8 - Physical properties and assumptions
With these assumptions, the following mathematical data can be observed for a rear-end collision avoidance problem involving two vehicles:
|Data |Units |Variable |
|Lead vehicle velocity |Feet per second |lv_vel |
|Trailing vehicle velocity |Feet per second |tv_vel |
|(direction is the same as lead vehicle) | | |
|Lead vehicle acceleration |Feet per second |lv_acc |
|Trailing vehicle acceleration |Feet per second |tv_acc |
|Distance between two vehicles |Feet |d |
Table 9 - Mathematical data for collision-avoidance problem
Problem Scenario
Two vehicles of equal weight are traveling down the road with the same velocity and direction. The vehicle in front is formally called the lead vehicle; the following vehicle is called the trailing vehicle. The two vehicles have a distance between the edge of the trailing vehicle’s front bumper and the edge of the lead vehicle’s rear bumper. This distance is d.
At time, t0, the two vehicles have a distance of d between them. If the lead vehicle at time, t1, slows down, its velocity changes and its acceleration vector is in the opposite direction of its velocity vector. At this very moment, if the trailing vehicle does not change its velocity [which at t0 was the same as the lead vehicle], then it enters a state of potential collision with the lead vehicle. The distance between the two vehicles is becoming shorter by the second. Thus, the question is:
What is the braking distance required for the trailing vehicle to change and match its velocity to that of the lead vehicle?
Answering this question will provide the required braking distance that a vehicle needs in order to slow down and match the lead vehicle’s velocity. The Australian Academy of Science (Australian Academy of Science, June 2004) has provided analysis on a braking distance formula based on the aforementioned assumptions. This formula will be used for the prototype safety system in this thesis. Before presenting this formula, a few factors must be addressed.
Reaction Time
A portion of the required braking distance is not used because of the driver’s reaction time. This is the time between the driver’s recognition of a slowing lead vehicle and the initiation of the brakes. For example, a vehicle traveling at 60 mph is moving at 88 feet per second. The AAS has stated that 1.5 seconds is the reaction time of average drivers; while a distracted driver’s reaction time may take as long as 3 seconds. So using this reaction time, the vehicle traveling at 88 feet per second will travel 132 feet while the driver reacts to a possible collision condition. The vehicle has essentially traveled half the length of a football field before any brake initiation. The calculation is reviewed below.
|[pic] |
Figure 15 - MPH to FPS Conversion
If the slope and frictional resistance are equal, the factor that has the most influence on braking distance is the initial speed (Australian Academy of Science, June 2004). The braking distance formula is provided below.
[pic]
In the formula, [pic] is the final velocity, [pic] is the initial velocity, [pic] is the deceleration, and [pic] is distance traveled during deceleration. To apply this to the collision avoidance problem, the final velocity is the velocity of the lead vehicle and the initial velocity is that of the trailing vehicle.
To solve this equation for distance, it is rearranged to the following.
[pic]
Now that the distance formula has been stated formula, it should be applied to the scenario described previously involving the two vehicles with the equal velocities and some distance between them, say x. If both vehicles are traveling at 88 feet per second west (60 mph), and the lead vehicle changes its speed to 80.7 feet per second (55 mph), then the trailing vehicle needs to change its velocity to 55 mph to match the lead vehicle, otherwise it will overcome the distance x between them and incur a rear-end collision. The braking distance is calculated to be approximately 18.75 feet. This means that the trailing vehicle needs 18.75 feet or approximately .2 seconds to slow its velocity down to 80.7 feet per second. However, this does not account the reaction distance of 132 feet. Summing these values produce a total of 150.74 feet. The calculation is reviewed below.
[pic]
If the total braking distance required, 150.74 feet, is greater than the distance between the vehicles x, then the trailing vehicle is at risk of a rear-end collision if it cannot decelerate faster then the assumed deceleration value a from the formula. The formula provided in this example uses a deceleration rate of 33 feet per second which amounts to a deceleration of 20 mph every second. It is safe to argue that this deceleration rate is that of hard braking.
Deceleration and Braking Power
The assumed deceleration should be seen as a control value to the effectiveness of this emergency braking notification system. For simplicity, assumptions were stated that braking power was equal for all vehicles, but this is not realistic. This thesis proposes that automobiles carrying this safety system provide a value to this equation that represents the braking ability of their vehicle.
The application of the brake distance mathematics is presented in the next section.
Applying the Brake Distance Formula
This thesis presents a passive collision avoidance system formally called the Emergency Braking Notification System that implements the brake distance formula so that a comparison can be made between the trailing vehicle’s measured distance and the required brake distance under the conditions when the speed of the lead vehicle changes. Note that assumptions on frictional forces have been made in order to simply the problem. Continued studies would scale this prototype accordingly. With this said, there are three outcomes of the algorithm implemented in this prototype.
• Illuminate the red light if the required braking distance is greater than the actual distance between the vehicles, i.e. trailing vehicle is at an unsafe distance
• Illuminate the yellow light if the required braking distance is equal to the actual distance between the vehicles, i.e. trailing vehicle is at a distance that is neither safe nor unsafe.
• Illuminate the green light if the required braking distance is less than the actual distance between the vehicles, i.e. trailing vehicle is at a safe distance.
The next chapter documents the outcomes of the completed test cases that contributed to the successful prototype creation of a multi-part safety system that sends vehicle speed notification messages from the lead vehicle over the wireless network. The trailing vehicle then receives the lead vehicle speed messages and performs a continual brake distance calculation to determine if the observed distance between itself and the lead vehicle is safe or unsafe given the speed notification messages of the lead vehicle. Immediate visual feedback as stated above is given to the trailing vehicle driver.
CHAPTER 4
PROTOTYPE IMPLEMENTATION AND RESULTS
SUBSTANTIAL BACKGROUND WORK HAS BEEN PERFORMED AND DOCUMENTED IN THIS PAPER IN ORDER TO EXPOSE THE READER TO SEVERAL THINGS. FIRST, A TECHNICAL OVERVIEW OF COMPUTER NETWORKS, WIRELESS SENSOR TECHNOLOGY, AND THE CROSSBOW MOTE HARDWARE WAS NECESSARY TO ESTABLISH THE TECHNOLOGICAL FOUNDATION OF THIS THESIS RESEARCH AND THE CONSTRUCTED PROTOTYPE. THEN, STUDIES AND IMPLEMENTATIONS OF WIRELESS TECHNOLOGY IN THE FIELD OF PUBLIC TRANSPORTATION INDICATED THAT THE CONCENTRATION OF TECHNOLOGY USED IS FOR THE PURPOSE OF TRAFFIC MONITORING AND MANAGEMENT. SIMILAR RESEARCH AND DEVELOPMENT EFFORTS WERE PRESENTED TO THE READER FOR CONTRAST AND COMPARISON TO THE IDEAS AND WORK IN THIS THESIS. THE PRIMARY ROADBLOCK FOR THE DEPLOYMENT OF THESE ADVANCED SAFETY SYSTEMS IS THE HIGHER IMPLEMENTATION COSTS BECAUSE OF THE SOPHISTICATED SENSOR AND NETWORK TECHNOLOGY. THE READER SHOULD NOTE THAT THE PROTOTYPE FOR THIS THESIS HOPES TO PROVIDE A COST REDUCTION THROUGH UTILIZATION OF THE EXISTING OBD SENSOR SYSTEM CURRENTLY DEPLOYED IN A MAJORITY OF THE VEHICLES ON THE ROAD TODAY. LAST, THE READER IS GIVEN A PRIMER ON SIMPLE PHYSICS AND MECHANICS OF TWO OBJECTS IN MOTION. IN THIS STUDY, THE OBJECTS ARE TWO VEHICLES IN MOTION ON THE ROAD, TRAVELING AT RESIDENTIAL AND HIGHWAY SPEED LIMITS.
In this chapter, the answers to the design and implementation questions are provided. The architecture is presented first to provide a high-level view of the proposed prototype safety system. The answers documented below are the result of problem decomposition to solve how each interface in this architecture will be created.
|[pic] |
Figure 16 - Prototype Architecture for LeadCar and TrailingCar
How can data be retrieved from a car’s on-board computer?
The test automobile is a 2006 Subaru Outback [Subaru 2006]. It has a 2.5-liter horizontally opposed 4-cylinder engine that generates 175 horsepower at 6000 revolutions per minute. The torque is 169 lb-ft at 4400 revolutions per minute. This vehicle will serve as the lead vehicle; therefore the safety system will need to retrieve data from the cars on-board computer. This model year automobile supports the OBD-II standard. A photograph of the test vehicle and the OBD port is provided below.
|[pic] |
Figure 17 - 2006 Subaru as Lead Vehicle
|[pic] |
Figure 18 - OBD Port
There are many hardware tools that can be connected to any car with the OBD standard; however, most of these devices cost several hundred dollars. This is due to the computer and monitor that these devices carry. For the system that needs to built for this prototype, a much simpler OBD tool was needed and one that could be interact with a custom program to retrieve measurements. The LLC will enable a laptop to collect live measurements. The ScanTool hardware costs $144.75 after taxes and it is shown below.
|[pic] |
Figure 19 - ElmScan OBD Reader
There are two interfaces for communication using the OBD reader. On one end is the RS-232 serial port, which attaches to the OBD port shown above. On the other end is a USB port, which attaches to the any computer with a USB port. This OBD reader is based on the ELM327 integrated circuit, which is the underlying hardware facilitating as the bridge between the RS232 port on a PC and the OBD port on a vehicle (ELM327 Users Manual). This hardware provides the capabilities of receiving commands from a PC-based program and passing them to the attached OBD computer. When the OBD computer sends a response, the ELM327 forwards this response to the PC-based program for whatever usage it desires. This capability is used to send requests for vehicle speed to the lead vehicle. The custom host program developed in this prototype establishes the connection to the ELM327 hardware and sends requests over the RS232 port. Note that this OBD reader has a built-in RS232-to-USB converter.
For this prototype the RS232 port is on a HP laptop computer, model name Pavilion zt3000. The computer runs Microsoft Windows XP with the Intel Centrino chipset with 1.00 GB of RAM. The laptop is shown below. Worth noting was the integration of the OBD reader to an Apple 12-inch PowerBook running Microsoft Windows XP within a Virtual PC. The decision to use the HP laptop was to simplify the configuration of the prototype environment. Additionally, the HP laptop had a parallel port, which was necessary to upload the custom mote programs.
|[pic] |
Figure 20 - Host PC
The Scantool OBD reader came with a versatile open-source program called . This program confirmed that the OBD reader was capable of retrieving critical vehicle data from the OBD computer onto a laptop computer. This prototype was dependent on the extraction of this data. Below is a screen capture of the readings that could be collected with the program.
|[pic] |
Figure 21 - OBD reader software
How can the open-source OBD programs be modified for use in this safety system?
To communicate with the ELM327 hardware, the custom program running on the HP laptop, SmartCarComm.java, was implemented to configure a connection to communicate at 9600 baud with 8 data bits, no parity bit, and 1 stop bit. This custom Java program was built using a serial communication library built designed for Windows machines (Resner, 2000). This library allowed easier configuration for serial communication on a Windows machine. The reader should note that there were many struggles with establishing the m serial communication libraries. Actually, the m library is no longer supported by the engineer’s at Sun and instead refers to the for continued support ().
Initially, I hoped to reverse-engineer the open source code provided with the OBD reader to understand the serial communication and port the program for usage in this prototype. Unfortunately, the open source program would not compile, so I had to take another avenue and explore serial communication using existing C or Java API. The custom Java class that I created is named SmartCarComm. It sends a String value, 010D, followed by the byte value 0x0D to the ELM327 IC. These values are interpreted by the IC as a request for live diagnostics (01) for the vehicle sensor for vehicle speed (0D). The byte value 0x0D is the hexadecimal representation of a carriage return, which is mandatory for all messages to be sent to the ELM327. The value to get back is a multi-byte ASCII and hexadecimal response from the IC. See the screen capture of the SmartCarComm program at execution time.
[pic]
Figure 22 – SmartCarComm custom program output from OBD
The reader can observe the sequence of characters reading 41 0D 42. This is an encoded string meaning response for live data (41) from the vehicle speed sensor (0D), and finally the hexadecimal value of 42, which converted is the integer 66. The ELM327 provides vehicle speeds in units of kilometers per hour. A simple division of 1.609 yields a vehicle speed of approximately 41 miles per hour.
Polling of this data seemed to be consistent and free of error at intervals of 500 milliseconds. Setting the interval to 250 seconds appeared to be too quick for either the ELM327 to process or for the OBD computer because I did not receive responses at these intervals. To prove that the SmartCarComm program can read live vehicle data, an extended road test was visualized. Data from this test is provided in the graph below. The road test was for 2 minutes or 120 milliseconds. The shaded area depicts an emergency stop situation that was recorded by the custom OBD reader. It is for these situations that an advanced collision avoidance system needs to be able to detect. This prototype uses the custom OBD reader, SmartCarComm, to capture this data. The next step is to transfer this data onto the wireless sensor network.
[pic]
Figure 23 - Initial Road Test using SmartCarComm
What is the maximum distance that a sent radio message can be received?
The MICA mote family supports both the CC2420 and CC1000 radio hardware, which communicate over different frequency bands. The details on this hardware have been presented previously during the technology review.
For an unobstructed distance test, I programmed two MICA2 motes with a simple introductory radio communication program that sends a counter value from one mote to another. With this program, the receiving mote will continue to illuminate its LEDs to represent an increasing binary count. The first set of tests was conducted inside but disappointingly the distance was less then 20 feet line of sight. To remedy the situation, I replaced the batteries and straightened the wire antennas and retested. The outcome for this follow up test did not yield different results. This contradicted the expected distance of several hundred feet. However, this was indoors; outdoors the results were much better providing a distance of nearly 50 feet. While this was not the expected several hundred feet, at least the outcome was more favorable.
For an obstruction distance test, I reused the simple program from the unobstructed test in order to measure the maximum distance for which this program will work with an obstruction. When embedded in a vehicle, there are many layers of obstruction, including glass, plastic, and metal in addition to any interference caused by the electrical and mechanical nature of the engine. The motes communicated successfully in and around the car with the vehicle’s engine on and off. The distance remained consistent measuring around 50 feet. Below is a picture of a communication test where the mote was placed on a small ledge next to the speedometer. There was no observed interference from the vehicle.
|[pic] |
Figure 24 - MICA2 mote in vehicle
How does communication from PC to sender-mote occur?
For this test case, I used a simple serial communication program to confirm the successful send and receive of a message between a PC and a connected mote. This program consisted of a Java program that runs on a host PC that create an integer counter and sends the value to the serial port. On the other end of the serial port is a mote mounted onto the MIB500 programming board. This mote has a program installed to listen for incoming messages from the serial port. If the message was received successfully, the motes LED indicators would blink and produce a binary count from 0 to 7.
The next step was to create a custom program based on this simple mote-to-PC test program above to carry vehicle data from the host computer to the attached mote. For this, I created a Java class named Bridge. This class uses the TinyOS Java API to facilitate communication between a PC and attached mote. Data is wrapped into a message that matches the specification of the message structure as defined by the nesC program header file. The message is called CarMsg, which has been implemented to carry a payload of an unsigned 32-bit integer to represent the vehicle speed. The TinyOS message interface generator, or MIG, tool introspects the message structure defined in the nesC program header file to generate an equivalent Java implementation. This enables the nesC program and the host PC program to know of the message format independent of programming language. To confirm successful transmission of vehicle speed, I sent a fixed integer representative of the vehicle speed from the host computer. On the receiving end, I performed a simple boolean equals comparison to prove that the mote could receive this exact vehicle speed from the serial port. If this condition was true, then I illuminated one of the mote’s LEDs. The figure below shows a MICA2 mote mounted onto the MIB500 programmer board, which is attached to the host PC via a Serial-USB cable.
The custom TinyOS program is called LeadCarC.nc. It contains the logic that enables it to listen to incoming messages from the serial port. These incoming messages are of type CarMsg and the payload of the message is the vehicle speed that was collected by the host PC. Once LeadCarC receives the vehicle speed, it then transmits an outgoing message over the radio for a receiving mote to receive. The receiving mote is programmed with another TinyOS program called TrailingCarC. This program listens for incoming radio messages and processes these messages. The details of the processing are explained next.
|[pic] |
Figure 25 - MICA2 on MIB500 for Mote-PC Serial Communication
How is data transmitted from sender-mote to receiver-mote?
The simple distance test where the two motes send a counter value between each other demonstrated the capability of sending radio messages between motes. For this prototype, the messages to be sent are of type CarMsg, which has been defined in the header files of the custom TinyOS programs.
At last all the crucial communication components have been identified. The data that originates on leading vehicles on board computer will be extracted using the ELM327 OBD scanner, which is receiving vehicle speed requests from my custom program called SmartCarComm which runs on the HP laptop that is inside the lead vehicle. The ELM327 will relay the measured vehicle speed from the leading car on board computer as a response to the SmartCarComm program. When the SmartCarComm program receives a response, it immediately wraps the response, which is the vehicle speed, into the CarMsg message to be sent to the serial port. Attached to the HP laptop is the MIB500 programmer board with a mounted MICA2 mote. This mote is running the LeadCarC program that is listening to incoming messages from the attached host computer and then relaying the message over its radio for the TrailingCarC mote program to receive. The vehicle speed is embedded in a message that will be carried wirelessly from the from the LeadCarC mote to the TrailingCarC mote.
To be clear, the LeadCarC program will be installed on the mote to be carried in the lead vehicle in this two-car system prototype. And the TrailingCarC program will be installed on the mote to be carried in the trailing vehicle.
The following figures depict the hardware configuration of the lead and trailing vehicles. In the lead vehicle is the host PC, ELM327IC (not shown), MIB500, and MICA2 mote. In the trailing vehicle, the prototype only requires a single MICA2 mote with the TrailingCarC program.
|[pic] |
Figure 26 - Lead vehicle hardware configuration
|[pic] |
Figure 27 - Trailing vehicle hardware configuration
How is the driver warned of the braking-level (slow-down, caution, no hazards)?
The driver of the trailing car will receive brake notification messages in the form of a green, yellow, or red LED light that will illuminate on the MICA2 mote. This mote is loaded with a custom TinyOS program named LeadCarC. Recall, that this program is waiting for vehicle speed data to arrive over the radio. The messages have originated with the lead car. Once the CarMsg packet is received, it is inspected and the vehicle speed is extracted for use in the embedded brake distance formula. Recall, that the brake distance formula will be used by the safety system in the trailing car to determine the brake distance that is required if the trailing car’s speed needs to be adjusted to match a slower speed of the lead car. If this distance is larger than the distance between the two vehicles, then the driver is in imminent danger of a rear-end collision, so a red light is illuminated on the MICA2 mote. If the required brake distance is smaller than the distance between the two vehicles, then the driver is in no danger, so a green light is illuminated on the MICA2 mote. Lastly, if the calculated brake distance and the distance between the two vehicles falls within a margin of 1 foot, then the driver is warned to yield, so a yellow light is illuminated on the MICA2 mote.
Road test of prototype
For the full test of this prototype, there were a few limitations, which were addressed with some data being fixed. One limitation was hardware. Only a single ELM327 hardware was purchased for this thesis study. At a cost $150 dollars only one was ordered to demonstrate the proof-of-concept. To provide the mote installed in the trailing vehicle with its own vehicle speed, this value was fixed at 60MPH or 88 feet per second. Another limitation was hardware to determine the actual distance between the two test vehicles. I was able to locate an affordable sonar sensor but the successful integration onto the MICA2 mote platform was uncertain. To provide the mote installed in the trailing vehicle with an observed distance between the two vehicles, this value was fixed as well. The last limitation was unexpected for the mote platform. The communication distance between the two motes was much lower than anticipated. I hoped for a distance of several hundred feet, instead the distance was less than one hundred feet, so I was uncertain whether the two motes would be able to communicate on the highway.
With these assumptions, the test was fixed for highway speeds and was hypothesized to work as follows. Recall, that this scenario was described previously. The lead and trailing vehicles would be traveling on the highway at 60MPH or 88 feet per second. The trailing vehicle was given a tight hard-coded distance of 17.75 feet. This could represent a tailgating situation, but in fact this is actually slight lower than the minimum distance required to brake if reaction time is omitted from the trailing vehicle’s computation. The restriction on the mote communication distance was going to require the trailing vehicle to be within range of the lead vehicle, so the hard-coded distance may have been somewhat accurate. When both vehicles are traveling at 60MPH, the green LED on the trailing vehicle should illuminate because the required brake distance is 0. This is true because there is no deceleration in the lead vehicle; therefore there are no conditions for collision based on vehicle speed. When the lead vehicle speed reduces its speed from 60MPH towards 55MPH, the brake distance calculation determines that there is a required brake distance of 18.75 feet, so the threshold off the required brake distance and the fixed brake distance between the two vehicles is broken and at this moment the red LED on the trailing vehicle should flash. The road test should show that the red LED continues to blink until the lead vehicle speed increases to a speed that the fixed distance of 17.75 feet is greater than the calculated brake distance. At this moment, the green LED should flash, thus indicating that there is no danger.
|[pic] |
Figure 28 - Complete Prototype Test Road Test
This test was conducted using two vehicles traveling north on C-470 between the Ken Caryl and Bowles exits. The lead vehicle, Subaru Legacy, carried the host PC, ELM327IC, MIB500, and MICA2 mote with the custom TinyOS program. The SmartCarComm program was initiated and immediately vehicle speed measurements were being recorded by the Lead Car system and broadcasted over the radio for reception into the Trailing Car system. The trailing vehicle, Subaru Outback, is pictured below.
[pic]
Figure 29 – 2003 Subaru Outback Trailing Vehicle
The MICA2 mote was placed within the driver’s view for confirmation of LED illumination. As expected, once the vehicle speed data was being propagated onto the wireless sensor network, the MICA2 mote began flashing its red LED. This was appropriate because the Lead Car was indicating that it had a vehicle speed of 0MPH! The assumed speed of 60MPH in the trailing vehicle would be in danger of a collision. Of course, the interesting test would be toggle of the red LED to green once the lead vehicle’s speed approached 60MPH. Recall, that the lead vehicle speed is actually being measured real-time and disseminated onto the wireless sensor network. Indeed, the LED changed from red to green soon after the lead car broke 55MPH. With the fixed values of the trailing car, the lead car’s measured real-time vehicle speed was toggling the illumination of the trailing vehicle’s MICA2 mote! A graph of the 5-minute or 300 second road highway is provided below. There were approximately 600 readings, which is good because measurements on vehicle speed were performed every ½ second. Worth noting, was the low error rate: only 3 errors were recorded during the 5-minute highway test. The horizontal green, yellow, and red lines indicate the thresholds for which the MICA2 mote in the trailing vehicle will illuminate its green, yellow, and red LEDs. The second chart is a magnification of the vehicle speeds that are in the threshold of the required braking distance as computed by the implemented brake distance formula that is programmed onto the MICA2 mote carried by the trailing vehicle.
[pic]
Figure 30 - MPH-Time Graph of Highway Test
[pic]
Figure 31 - Highlight of LED illumination thresholds
Custom Programs
Below is a summary of the custom programs that were created in support of developing a prototype of this safety system.
• LeadCarC.nc, TrailingCarC.nc – Custom TinyOS module component that will provide the implementation of how the mote will receive and transmit packets via radio communication. The LeadCar component contained the logic to listen for incoming data from the serial port and forwarding this data onto the wireless sensor network. The TrailingCar component contained the logic to listen for incoming data from the radio communication channel. The incoming data represented the speed of the lead vehicle. This data would be a parameter to the brake distance formula to determine the type of indication to provide the driver.
• LeadCarAppC.nc, TrailingCarAppC.nc – Custom TinyOS configuration component that will provide the wiring of the used component interfaces to the interface providers.
• LeadCar.h, TrailingCar.h – Custom header file that will contain the definition of the CarMsg struct. This struct represents the message or packet that will be serialized and transmitted over radio. The TinyOS mig process introspected this struct to create a Java class representation of the message, CarMsg. The CarMsg class contained methods to set the vehicle speed.
• SmartCarComm.java, Bridge.java – Custom Java programs that facilitate the transfer of OBD data from the car to the motes on the wireless sensor network. The SmartCarComm contained the logic for communicating to the ELM327 integrated circuit, which would then facilitate the message passing between itself and the OBD computer on the lead vehicle. Once the SmartCarComm class received the vehicle speed data, it used the Bridge class to send the data to the serial port. The Bridge class used the TinyOS API for serial communication between a PC and a mote to pass the vehicle speed data to the mote for propagation onto the wireless network.
Below are a few nesC documentation diagrams for the LeadCar and TrailingCar systems. Detailed nesC documentation and Java documentation are available as an additional reference outside of this document.
[pic]
Figure 32 - LeadCarC Component Diagram
[pic]
Figure 33 - TrailingCarC Component Diagram
CHAPTER 5
CONCLUSION
THE RIGOROUS RESEARCH AND PROTOTYPE DEVELOPMENT PRESENTED IN THIS THESIS PAPER HAS DOCUMENTED AN EFFORT TOWARD CREATING A SAFETY SYSTEM THAT WORKS ON THE PREMISE OF SHARING VEHICLE DATA. VITAL DIAGNOSTICS THAT ARE MONITORED ON NEARLY EVERY CAR TRAVELING TODAY’S ROADS SHOULD BE MADE AVAILABLE FOR THE INTERPRETATION AND SAFETY DECISION-MAKING OF NEW AGE SAFETY SYSTEMS. THE PROTOTYPE SAFETY SYSTEM DEVELOPED FOR THIS THESIS FALLS INTO THE CATEGORY OF A COLLISION AVOIDANCE SYSTEM. HERE IT IS FORMALLY CALLED THE WIRELESS SENSOR NETWORK EMERGENCY BRAKING NOTIFICATION SYSTEM (WSN-EBNS).
The WSN-EBNS has been successfully prototyped to provide a proof-of-concept that if vehicle data from a lead vehicle is shared wirelessly for a trailing vehicle to receive and interpret, a notification from the trailing vehicle can notify the driver of the lead vehicle deceleration independent of brake light illumination in the lead vehicle! The algorithm carried by the MICA2 mote in the trailing vehicle calculates the required brake distance using the following variables: lead vehicle speed, trailing vehicle speed, trailing vehicle deceleration capability. This value is compared to the observed distance between the two vehicles to determine the notification message to the driver.
The experiment involved two vehicles traveling at 88 feet per second. The distance threshold was broken when the lead vehicle decelerated to 80.7 feet per second. The calculation is given below. At the calculated 18.75 feet, the trailing vehicle determined that its fixed distance of 17.74 was less than the required braking distance, so the driver was warned to brake with the illumination of the red LED. Recall, that this logic and decision making is a custom TinyOS program installed on the MICA2 mote in the trailing vehicle.
[pic]
Tuning Parameters
There are several tuning parameters for this system and should be explored in a continued study of this prototype. The first is reaction time; I found averages from ½ second to 1½ second during my research. At 60MPH, this is a range of approximately 40 feet to 130 feet on the highway. Another tuning parameter could be deceleration, which amounts to the braking capacity of a vehicle. The brake distance formula implemented in this prototype assumed a deceleration of 33 feet per second, but this could vary from vehicle to vehicle depending on a number of factors including vehicle size, brake size, tire age, or even road conditions.
Expansion of Prototype
The next step of the WSN-EBNS prototype would be to acquire another ELM327 OBD reader so that the trailing vehicle can record its own vehicle speed. The antenna on the MICA2 mote seemed inadequate for distances greater than 50 feet. This could be a tunable variable in the mote hardware or a possible antenna upgrade. Currently the MICA2 mote has a simple antenna, which is an insulated wire one-quarter wavelength long. For the MPR410 433 MHz mote the whip antenna length is 6.8 inches. This simple antenna could be upgraded using antennas that are available from Linx Technologies (Linx Technology). An upgrade could be favorable for future enhancements to this prototype. The antenna that is provided in the MICA2 mote development kit is small, and did not provide communication at a few hundred feet as expected. For the 433MHz and 916 MHz motes, Linx Technologies provides a monopole antenna with two configurations to support these motes. The construction is more rugged than the single wire in this prototype. The part number is ANT-433-PW-QW, which requires a MMCX connector installed for compatibility with the mote board.
|[pic] |
Figure 34 - Linx Technology 433 MHz Antenna Upgrade
Final Remarks
State departments of transportations have spent millions of dollars integrating technology into our nation’s roadways. Their efforts are usually in direct support of Intelligent Transportation System (ITS) initiatives to gather and distribute traffic data so that car travel can be safer and more economical. Other ITS initiatives under heavy research and early development are exploring advanced safety systems that work on the same premise argued in this paper, which is the sharing of vehicle data and the networking of cars can lead to a new frontier of vehicle safety systems. This prototype has shown how wireless sensor networking and leveraging the OBD computer has the potential of providing a lightweight and low-cost solution for a collision avoidance system.
REFERENCES
1. Anderson, C. A. and D.G. Candey. “T-REX Comes to Life. Denver’s Monster of a Project.” Traffic Technology International Annual Review, 2003. (accessed November 2006).
2. Anderson, J. and others. “Wireless Sensor Networks for Habitat Monitoring.” WSNA 2002, September 2002. Atlanta, Georgia.
3. Atmel Corporation. “Atmel.” San Jose, California. (accessed October 2006).
4. Balakrishnan, H. and others. CarTel: A Mobile Sensor Computing System. Massachusetts Institute of Technology, Cambridge, Massachusetts, (accessed August 2006 ).
5. Brain, Marshall. “How Motes Work.” (accessed May 2006).
6. Bonsor, Kevin. “How Intelligent Highways Will Work.” How Stuff Works. (accessed November 2006).
7. Chow, C. E. and G. Godavari. “First Responders Sensor Network.” Department of Computer Science, University of Colorado at Colorado Springs, Colorado Springs, CO, Fall 2003. and (accessed May 2006).
8. Colorado Department of Transportation. “Intelligent Transportation Systems.” Denver, Colorado. (accessed November 2006).
9. Crossbow MoteWorks™ Platform, Crossbow Technology Inc. (accessed October 2006).
10. Crossbow Technology Inc. “Crossbow MPR-MIB Users Manual.” (accessed November 2006).
11. Crossbow Technology Inc. “Crossbow MTS/MDA Sensor Board Users Manual.” (accessed October 2006).
12. Dizikes, Peter. “Wireless Highway.” , March/April 2006. (accessed August 2006).
13. Doolin, D.M. and N. Sitar. “Wireless sensors for wildfire monitoring.” Civil and Environmental Engineering, University of California, Berkeley, CA, USA. (accessed November 2006).
14. ELM327 OBD to RS232 Interpreter Users Manual. “ELM327 OBD to RS232 Interpreter.” (accessed October 2006).
15. “Fatal Impact—The Physics of Speeding Cars”. Australian Academy of Science, June 2006. (accessed November 15, 2006).
16. Havinga , P. and G. Smit. “Collaborative Sensor Networks.” Department of Computer Science, University of Twente, Netherlands, (accessed November 2006).
17. Henderson, Tom. “ Speed and Velocity.” Glenbrook Schools, 2004 (accessed November 16, 2006).
18. Image Sensing Systems, Inc. “Autoscope,” 2006 (accessed November 2006).
19. Kenny, Robert L. “Replacing In-payment loops with Video Detection.” The official Newsletter of the ITE Colorado/Wyoming Section, September 2003.
20. Leiner, B. and others. “The past and future history of the Internet.” Communications of the ACM, February 1997.
21. Linx Technology. “Linx Technologies: Wireless Made Simple.” Oregon. (accessed November 2006).
22. Moteiv Corporation . “Moteiv.” San Francisco, California. (accessed October 2006).
23. . “Wireless Senor Networks: a Fragmented Market with Great Potential.” April 14, 2006 (accessed August 2006).
24. MSP410 Wireless Security System Specification Sheet. Document Part Number: 6020-0064-01 Rev B. Crossbow Technology Inc. (accessed November 2006).
25. MSP-SYS MSP Mote Developer’s System Specification Sheet. Document Part Number: 6020-0084-02 Rev A. Crossbow Technology Inc. (accessed November 2006).
26. National Institute of Standards and Technologies, Advanced Network Technologies Division. “Wireless Ad Hoc Sensor Networks.” (accessed October 2006).
27. National Center for Statistics and Analysis of the National Highway Traffic Safety Administration. “Colorado Toll of Motor Vehicle Crashes,” 2005 (accessed November 2006).
28. National Center for Statistics and Analysis. “Traffic Safety Facts 2004: A Compilation of Motor Vehicle Crash Data from the Fatality Analysis Reporting System and the General Estimates System,” 2005. (accessed November 2006).
29. Olsen, Stefanie. “Wireless: The New Backseat Driver?” CNET , January 2005. (accessed August 2006).
30. OMNeT++. “Discrete Event Simulation System.” (accessed November 2006).
31. Pescovitz, David. “Wireless on the Road to Safety.” Lab Notes. College of Engineering, University of California, Berkeley, March 2006. (accessed October 2006).
32. Resner, Ben. “Simple Serial.” (accessed November 2006).
33. Ricadela, A. “The Emerging World of Wireless Sensor Networks.” Information Week, January 20, 2005, (accessed October 2006).
34. Website, 1998 – 2006. . (accessed October 2006).
35. (accessed September 2006).
36. Subaru USA. (accessed September 2006).
37. Tanenbaum, A. Computer Networks. Upper Saddle River, New Jersey: Prentice Hall PTR, 2003.
38. Tanenbaum, A. Modern Operating Systems. Upper Saddle River, New Jersey: Prentice Hall Inc., 1992.
39. Telecommunications Networks Group, Technical University of Berlin, Germany. Energy Efficient Sensor Networks (EYES), (accessed August 2006 ).
40. TinyOS Getting Started Guide, April 2003. (accessed November 2006).
41. TREX Project Website. (accessed November 2006).
42. Turner-Fairbank Highway Research Center. “Intelligent Intersection Traffic Control Laboratory.” McLean, VA. (accessed October 2006).
43. UC Berkley. Tiny OS, 2004 (accessed August 2006).
44. U.S. Department of Transportation. “Dedicated Short Range Communications (DSRC).” ITS Standards Programs, April 2003. (accessed November 2006).
45. U.S. Department of Transportation. “Intelligent Transportation System.” (accessed November 2006).
46. U.S. Department of Transportation IVI and Mitretek Systems, Inc. “Intelligent Vehicle Initiative,” 2002. (accessed November 2006).
47. U.S. Department Of Transportation IVI - Mitretek Systems, Inc. “IVI – 8 Major Problem Areas,” May 13, 2002. (accessed November 2006).
48. Woodyard, C. “Cars Soon May ‘Talk’ to Roads, Each Other.” USA Today on the Web, November 2005. (accessed October 2006).
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- reading questions
- rochester institute of technology
- google translation of tyrel de poix
- thesis proposal for master of software engineering
- advanced metering infrastructure attack methodology
- manual for the nc bqa trainer gpvec
- the in famous beginners guide to daggerfall
- smartcars and smartroads
- dc phb section 6