senior design project 2007 - umass amherst › ece › pishro › finalreport.pdf · final report...
TRANSCRIPT
Senior Design Project 2007
DSRC Accident Warning System at Intersection
Final Report
Team Pishro-Nik and Ni
Members:
Richa Prasad . Raza Kanjee . Hui Zhu . Thai Nguyen
Professor Pishro-Nik Advisor, ECE
Professor Ni Advisor, CEE
May 24, 2007
Contents 1 PROBLEM STATEMENT
1.1 Background........................................................................................................ 1 1.2 The Design ........................................................................................................ 1 1.3 Deliverables...................................................................................................... 3
2 REQUIREMENT SPECIFICATIONS
2.1 Principle of Operation & System Block Diagram............................................... 6 2.2 Input................................................................................................................ 7 2.3 Output............................................................................................................. 7 2.4 Acceptability Test............................................................................................. 8 2.5 Product Cost .................................................................................................... 8
3 TECHNOLOGY SURVEY 3.1 Global Positioning System ................................................................................ 9 3.2 Transceiver ..................................................................................................... 18 3.3 Current State-of-Art Practice .......................................................................... 22 3.4 Project Specifications...................................................................................... 26
4 SYSTEM COMPONENTS
4.1 Latency Calculations ....................................................................................... 27 4.2 Traffic Light.................................................................................................... 34 4.3 Transceiver Communication .......................................................................... 36 4.4 GPS-Laptop Communication.......................................................................... 39 4.5 GPS Data Reception by RSE ........................................................................... 43 4.6 RSE Algorithm................................................................................................ 44 4.7 Testing & Debugging...................................................................................... 49
5 STATISTICAL ANALYSIS
5.1 Confidence of False Alarm.............................................................................. 54 5.2 Frequency of Alarm with Distance ................................................................. 54 5.3 GPS Inaccuracy............................................................................................... 56 5.4 Confidence of Transceiver Connection Range ............................................... 57
6 SUMMARY
6.1 Conclusion ..................................................................................................... 58 6.2 Future Work .................................................................................................. 58
7 BIBLIOGRAPHY................................................................................................. 59 8 APPENDIX
8.1 Roadside Equipment Code ............................................................................. 60 8.2 OnBoard Equipment Code ............................................................................ 89
1 PROBLEM STATEMENT 1.1 Background Vehicle collisions at intersections account for a large percentage of overall traffic accidents. Figure 1 shows three of the most common ways for collisions at intersections.
Figure 1: Common reasons for collisions at intersections
The situations illustrated in Figure 1 account for 65% of injury accidents and 70% of fatal accidents [1]. It is also true that for the past thirty years, the annual fatality rate due to traffic accidents in the United States has been over 40,000. We can prevent a large number of these accidents from occurring if we could provide drivers with warnings about potential collisions. For example, if a system could warn a car sitting at an intersection that another car is about to run the light, the driver waiting at the intersection would then not immediately start driving the minute the light turns green for him since he would be aware that there could be a potential collision with a car running the light. Our project concentrates on using technology to provide warnings to drivers about potential accidents and collisions at intersections. 1.2 The Design Vehicle Infrastructure Integration The Accident Warning System we plan on creating falls under a broader system called the Vehicle Infrastructure Integration (VII). This system enables real-time wireless communication between cars and between cars and static intelligent stations or units to help create an efficient and safe transportation system. VII is a massive system whose various applications and technologies are under research and testing in various parts of the world – especially in the United States and Europe. Figure 2 illustrates the many varied applications of VII.
1
Figure 2: Applications of VII
• Safety
Other than accident warning systems at intersections, the other ways to provide safety to drivers is to also provide them with path and speed suggestions. Pedestrian warning could be implemented alongside warnings of potential car collisions. Furthermore, on a straight road, when a car is attempting to overtake another car, then the VII system could help in completing the maneuver successfully and safely.
• Entertainment
There would no longer be a need to carry iPods or wait on popular radio stations for a particular favorite song. The driver could simply request a song to be played and the VII system would play that song. This could further be expanded if the driver wanted to play verbal trivia or some other games while driving.
• Tutor
The VII system could act as a tutor to amateur drivers in training to earn their license. The trainees could be provided suggestions and evaluations on how they are driving and what they could do to improve their driving.
• Traffic Management
This ties up with the safety aspect of VII. Data on the traffic situations at various parts of a highway or region of a state could be transmitted to a remote traffic station from where traffic management at a large scale could occur.
• Routing
This is an aspect of VII which is already in use currently. Planning routes to destinations will continue to be part of the VII experience.
• Weather
Each car will be equipped with weather sensing technology. Detailed information such as humidity, cloud cover, temperature, etc would be read by a car and transmitted to a weather station. This would allow weather stations to have real-time accurate data on weather conditions in even remote areas, thus providing weather stations with the capability of more accurate weather prediction.
These are only some of the applications of VII.
2
Dedicated Short Range Communication Dedicated Short Range Communication (DSRC) is a wireless communication protocol in the 5.9 GHz frequency band with a bandwidth of 75 MHz [2]. It refers to short to medium range wireless communications that offers data transfer in a vehicular ad-hoc network. The IEEE Standard for it is 802.11p. This standard is exclusively for transportation communication systems. 1.3 Deliverables Our project exclusively focuses on the Safety aspect of VII using DSRC. The goal of our project is illustrated by Figure 3.
Figure 3: Accident Warning System at Intersections There are two types of messages that can be sent from the OnBoard Equipment to the Roadside Equipment. They contain information on the speed and location of the car in which the transmitting OnBoard Equipment is located. 1. Status Messages
The Roadside Equipment receives these and simply logs them. No action is taken on these messages.
2. Event Messages
The Roadside Equipment needs to take action on the basis of these messages. From Figure 3, we notice two main components of the accident warning system: 1. Roadside Equipment (RSE)
This is a component of the system which acts as the central unit. It is in constant contact with the traffic light in order to determine when the light will turn red. Once it realizes that the light will turn red, it starts treating all messages from the OnBoard Equipment as Event Messages. Hence, it uses the speed and location information being transmitted to determine whether the car transmitting the message will run the red light, and if it will, then it needs to warn the other cars of this possibility.
3
2. OnBoard Equipment (OBE) This is a component of the system located within a car. It constantly calculates the speed and location of the car, and transmits this information to the Roadside Equipment. It also receives the warning signal from the Roadside Equipment telling it to activate the alarm system in order to warn the driver of whether a car will run the light.
We have further narrowed our goal by placing the following restrictions on our project: 1. Range of DSRC communication
The transceiver range is limited to about 250 meters. We have chosen 250 meters because of the following concerns: a. Closely located intersections
If there are closely located intersections, then we do not want the data and warnings being communicated to overlap. Hence, in order to prevent such a fiasco, we have chosen 250 meters of communication range since it limits the system of communication to one intersection.
b. Irrelevancy of warnings to cars far away from the intersection
If a car is far away from an intersection, then even though it receives the warning of another car running the light, that information is irrelevant to it since it is not in any danger of colliding with the speeding car.
Figure 4 illustrates how the Roadside Equipment and OnBoard Equipment are only aware of the traffic around a certain limited range around them.
Figure 4: Range of awareness of OBE and RSE
2. System of Communication
There will be no communication between cars. All communication will occur between the Roadside Equipment and the OnBoard Equipment. This aspect of the project is shown in Figure 5.
4
Figure 5: Only RSE-OBE Communication
Thus to summarize, the following are the goals of our project: 1. Accident Warning System of only whether a car will run the red light
This means that there will be no path and speed suggestion provided to the driver. There will also be no warning for pedestrians crossing the road. The project only deals with warning a driver if another car is about to run the red light.
2. Limitation to only one speeding car
Unlike a real-life scenario, there will only be one car approaching the intersection, and one other car receiving a warning of whether the approaching car will run the red light.
3. Real-Life demonstration
We hope to accomplish a real-life demonstration of the working project. 4. Technical Documentation
A comprehensive documentation will be completed and delivered to the advisors of this project.
5
2 REQUIREMENT SPECIFICATIONS 2.1 Principle of Operation & System Block Diagram The principle of operation is illustrated by the System Block Diagram depicted in Figure 6.
Figure 6: System Block Diagram
6
Speeding Car OnBoard Equipment consists of a GPS which constantly determines the location and speed of the car in which the unit is located. This information is logged by a laptop and sent to the transceiver, which sends it to the Roadside Equipment.
Roadside Equipment
The Roadside Equipment transceiver receives the speed and location information from the OnBoard Equipment. It verifies if the light is turning red anytime soon, and if it is then it calculates whether the speeding car will run the red light. If it will run the red light, then a warning signal is sent to the transceivers of all OnBoard Equipments.
Traffic Light
We are simulating the traffic light on a microcontroller. The microcontroller has an external clock which helps it keep track of the period of time the light should remain a certain color. It is directly connected to the Roadside Equipment laptop, to which it sends a control signal defining the point after which the Roadside Equipment needs to consider all messages from the OnBoard Equipment as Event Messages.
Warning Signal
If the speeding car will run the red light, then a warning message is sent from the Roadside Equipment transceiver to the transceivers on the OnBoard Equipments of the speeding car as well as the waiting car.
2.2 Input There are two inputs to the Accident Warning System. 1. GPS
This input contains information on the speed and location of the car in which the GPS is located. It is constantly sent to the Roadside Equipment.
2. Traffic Light
This input allows the Roadside Equipment to judge when to regard the speed and location information from the OnBoard Equipment as Event Messages.
2.3 Output There are two kinds of output from the Accident Warning System. 1. Warning Signal
A warning signal is sent from the Roadside Equipment transceiver to the OnBoard Equipment transceiver of the speeding and waiting cars in order to warn both cars that the speeding car is about to run the red light.
2. No Action
If the speeding car will not run the red light, then no action is taken by the Roadside Equipment and hence no warning signals are received by the OnBoard Equipments.
7
2.4 Acceptability Test The acceptability test is to ensure the successful execution of the real-life demonstration of an accident warning system involving a single speeding car. If the car is about to run the red light, then a warning should flash on the laptops of the speeding and waiting car. If it is not going to run the red light, then no action should be taken. 2.5 Product Cost
8
3 TECHNOLOGY SURVEY 3.1 Global Positional System
Overview The Global Positioning System, or GPS, can show you your exact position on Earth any time, anywhere, in any weather. The system consists of a constellation of 24 satellites that orbit 11,000 nautical miles above Earth’s surface and continuously send signals to ground stations that monitor and control GPS operations.
GPS satellite signals can be detected by GPS receivers, which calculate their locations anywhere on Earth within a meter by determining distances from at least three GPS satellites. No other navigation system has ever been so global or so accurate.
GPS, formally known as the Navstar Global Positioning System, was initiated in 1973 to reduce the proliferation of navigation aids. By creating a system that overcame the limitations of many existing navigation systems, GPS became attractive to a broad spectrum of users worldwide. GPS has been successful in virtually all navigation applications, and because its capabilities are accessible using small, inexpensive equipment, GPS is being utilized in a wide variety of applications across the globe.
Figure 7: Constellation of Satellites
The principle behind GPS is the measurement of distance (or “range”) between the satellites and the receiver. The satellites tell us exactly where they are in their orbits by broadcasting data the receiver uses to compute their positions. It works something like this: If we know our exact distance from a satellite in space, we know we are somewhere on the surface of an imaginary sphere with a radius equal to the distance to the satellite radius. If we know our exact distance from two satellites, we know that we are located somewhere on the line where the two spheres intersect. And, if we take a third and a fourth measurement from two more satellites, we can find our location. The GPS receiver processes the satellite range measurements and produces its position.
GPS uses a system of coordinates called WGS 84, which stands for World Geodetic System 1984. Likewise, GPS uses time from the United States Naval Observatory in Washington, D.C., to synchronize all the timing elements of the GPS system.
9
Figure 8: GPS Principles of Working
Figure 9: GPS Working Stepwise
The basic GPS service provides users with approximately 100-meter accuracy, 95% of the time, anywhere on or near the surface of the earth. To accomplish this, each of the 24 satellites emits signals to receivers that determine their location by computing the difference between the time that a signal is sent and the time it is received. GPS satellites carry atomic clocks that provide extremely accurate time. The time information is placed in the codes broadcast by the satellite so that a receiver can continuously determine the time the signal was broadcast. The signal contains data that a receiver uses to compute the locations of the satellites and to make other adjustments needed for accurate positioning. The receiver uses the time difference between the time of signal reception and the broadcast time to compute the distance, or range, from the receiver to the satellite. The receiver must account for propagation delays, or decreases in the signal's speed caused by the ionosphere and the troposphere. With information about the ranges to three satellites and the location of the satellite when the signal was sent, the receiver can compute its own three-dimensional position. An atomic clock synchronized to GPS is required in order to compute ranges from these three signals. However, by taking a measurement from a fourth satellite, the receiver avoids the need for an atomic clock. Thus, the receiver uses four satellites to compute latitude, longitude, altitude, and time.
10
Working Principles of GPS The GPS works in five logical steps:
• Trilateration • Measuring Distance • Precise Timing • Satellite Positioning • Error Correction
• Position is calculated from distance
measurements (ranges) to satellites. • Mathematically four satellite ranges are
needed to obtain exact position.
Figure 10: Step 1 – Trilateration of Three Satellites
• Distance to a satellite is determined by measuring how long a radio signal takes to reach us from that satellite.
• To make the measurement we assume that both the satellite and our receiver are generating the same pseudo-random codes at exactly the same time.
• By comparing how late the satellite's pseudo-random code appears compared to our receiver's code, we determine how long it took to reach us.
• Multiply that travel time by the speed of light and you've got distance.
Figure 11: Step 2 – Measuring Distance
11
• Accurate timing is the key to measuring
distance to satellites. • Satellites are accurate because they have
atomic clocks on board. • Receiver clocks don't have to be too accurate
because an extra satellite range measurement can remove errors.
Figure 12: Step 3 – Precise Timing
• To use the satellites as references for range measurements we need to know exactly where they are.
• GPS satellites are so high up their orbits are very predictable.
• Minor variations in their orbits are measured by the Department of Defense.
• The error information is sent to the satellites, to be transmitted along with the timing signals.
Figure 13: Satellite Location
12
Figure 14: Error Correction
In the real world there are lots of things that can happen to a GPS signal that will make its life less than mathematically perfect. Some of the prominent sources and solutions to errors are:
• As a GPS signal passes through the charged particles of the ionosphere and then through the water vapor in the troposphere it gets slowed down a bit. A way to get a handle on these atmosphere-induced errors is to compare the relative speeds of two different signals. This "dual frequency" measurement is very sophisticated and is only possible with advanced receivers.
• Trouble for the GPS signal doesn't end when it gets down to the ground. The signal may bounce off various local obstructions before it gets to our receiver. This is called multipath error and good receivers use sophisticated signal rejection techniques to minimize this problem.
• The atomic clocks they use are very, very precise but they're not perfect. Minute discrepancies can occur, and these translate into travel time measurement errors.
• The policy called "Selective Availability" or "SA" and the idea behind it was to make sure that no hostile force or terrorist group can use GPS to make accurate weapons. Basically the DoD introduced some "noise" into the satellite's clock data which, in turn, added noise (or inaccuracy) into position calculations. The DoD may have also been sending slightly erroneous orbital data to the satellites which they transmitted back to receivers on the ground as part of a status message. On May 1, 2000 the White House under President Clinton’s administration signed a Presidential Order to discontinue the intentional degradation of the GPS signals to the public beginning at midnight.
13
Civilian Accuracy Technology Prior to 1 May 2000 Global Positioning Systems accurate up to 100 meters (300 feet) due to “Selective Availability” feature enabled by he Department of Defense to prevent terrorist and rouge nations from using GPS as a targeting mechanism. The U.S. military was able to quickly develop and test their ability to selectively block accurate GPS transmissions in areas of conflict or where U.S. security was at risk. When the U.S. Air Force Space Command turned off SA last night, GPS became incredibly accurate for the entire planet. After President Clinton signed the Executive Order removing. This allowed GPS receivers to be accurate up to 10 meters (60 feet). Accuracy up to 10 meters is not enough for various civilian applications such as GIS, mapping, construction, mining and vehicle tracking. Hence, to overcome this inaccuracy in tracking, a couple of other techniques were used to bypass the limitations put fourth by the Department of Defense to make bring the accuracy up to 5 centimeters (2 inches). The following three technologies have been implemented by the Federal Aviation Administration, Department of Transportation and various other groups to improve the accuracy of GPS signals.
• Wide Area Augmentation System (WAAS) The Federal Aviation Administration (FAA) has designed a Satellite Based Augmentation Systems (SBAS) to improve the accuracy, integrity and availability of the Global Positioning System (GPS) required by civilian throughout the United States. The SBAS designed by the FAA is called the Wide Area Augmentation System (WAAS). Since a GPS unit already consists of a satellite receiver, correction signals were sent out on these frequencies than to use an entirely separate system and thereby double the probability of failure. Existing GPS satellites did not have any additional channels that could be used for this feature, so instead it was planned to add broadcasters to existing communications satellites. In addition to lowering implementation costs by "piggybacking" on a planned launch, this also allowed the signal to be broadcast from geostationary orbit, which meant a small number of satellites could cover all of North America. WAAS has twenty-five Wide-area Reference Stations positioned throughout the United States which compare the GPS signal with known (surveyed) coordinates. With WAAS implementation accuracy of the GPS increases to 3 meters (10 feet). Figure 15 shows how the accuracy of the GPS varies and its coverage throughout the United States.
Figure 15: WAAS Accuracy and Coverage
14
• Differential Global Positioning System (DGPS) Differential Global Positioning System or "DGPS" can yield measurements good to a sub meter level in moving applications and even better in stationary situations. Differential GPS involves the cooperation of two receivers, one that's stationary and another that's roaming around making position measurements. DGPS improves GPS accuracy by using a high-performance GPS receiver (reference station) at a known location. Since the reference station receiver or beacon knows its exact location, it can determine errors in the satellite signals. The error data for each tracked satellite is formatted into a correction message and transmitted to GPS users. These differential corrections are then applied to the GPS calculations, removing most of the satellite signal error and improving accuracy.
Figure 16: DGPS Working
Product Overview Market overview of the different types of GPS provided us with various options available to us. A brief overview of the products considered for the project and why were they rejected is provided in the table below.
Table 1: GPS Product Comparison Product Cost USD Accuracy (WAAS) Accuracy (DGPS) Reason Rejected
GlobalSat BU-353 79.00 5 meters NA Not Accurate Magellan AC12 Board 160.00 1 meter 0.8 meter Accepted Magellan DG14 Board 1500.00 1 meter 40 – 70 cm Expensive Trimble BD950 Board 2000.00 5 meters 1 meter Expensive
We chose the Magellan AC12 Board for our project because it was accurate enough for our project requirements and also within budget. Apart from being accurate the Magellan AC12 also had two bidirectional serial RS232 ports for communication with other peripheral devices.
15
United States Coast Guard Beacon Coverage NAVCEN operates the Coast Guard Maritime Differential GPS (DGPS) Service and the developing Nationwide DGPS Service, consisting of two control centers and over 60 remote broadcast sites. The Service broadcasts correction signals on marine radio beacon frequencies to improve the accuracy of and integrity to GPS-derived positions. The Magellan AC12 board can use the radio frequencies from the beacons to provide accuracies up to sub meter level. Coverage in the Amherst, MA area is provided by two beacons. One is located in Acushnet, MA and the other is located in Hudson Falls, NY. Figure 17 shows the coverage of the United States Coast Guard beacon signals in Massachusetts.
Figure 17: United States Coast Guard Coverage in Massachusetts
16
Figure 18: Position of Beacon Station Relative to Amherst MA
17
3.2 Transceiver Wireless Network IEEE Standard The IEEE 802.11 standard denotes a set of Wireless LAN standards. The 802.11 family includes six over-the-air modulation techniques that use all the same protocol. A brief summary of some of the standards and their characteristics is provided in Table 2 [3].
Protocol Release Date Operational Frequency Data Rate (Typical) Data Rate (Maximum) Indoor Range
802.11a 1999 5 GHz 25 Mbit/s 54 Mbit/s 30 m 802.11b 1999 2.4 GHz 6.5 Mbit/s 11 Mbit/s 50 m 802.11g 2003 2.4 GHz 25 Mbit/s 54 Mbit/s 30 m 802.11n 2007 2.4 GHz or 5 GHz 200 Mbit/s 540 Mbit/s 50 m 802.11p 2008 5.9 GHz 27 Mbit/s 54 Mbit/s ?
Table 2: Summary of 802.11 family The most popular standard is the 802.11b. 802.11a and 802.11g are the second most popular standards. The 802.11p and 802.11n standards are still under research and standardization process. The 802.11p is specifically for DSRC VII systems. IEEE 802.11p Standard Bandwidth
75 MHz (5.850 – 5.925 GHz)
Channels There are 7 non-overlapping 10 MHz channels. 2 of the channels can be combined to make one 20 MHz channel. This is illustrated in Figure 19 [2].
Figure 19: DSRC Channel scheme in United States
It is important that all safety messages are transmitted on one designated channel in order to ensure that all vehicles listen to the proper one for such messages.
18
Reserved Channel This is also called the “guard channel”. 5 MHz at the lower end of the spectrum are reserved for it.
Service Channels
Channels 172 and 184 are reserved for safety related applications. However, these two are not meant to be an option for regular safety communication. The remaining six channels (174, 175, 176, 180, 181 and 182) can be used for non-safety communication.
Control Channel
This channel is strictly for safety related communication and non-safety related communication is strictly limited in terms of transmission line and interval. This is illustrated in Table 3.
RSE Vehicle Maximum Data Transmission Duration 750 μs 580 μs
Minimum Interval Between Data Transmissions 100 ms 750 ms Table 3: Control Channel usage limits for non-safety transmission in USA
Power
Usually less than 2 W but up to 30 W for qualified public safety applications on the Control Channel.
Product Overview There are no commercially available 802.11p transceivers. The first are scheduled to appear in the market around 2012, according to Mr. Gary Pruitt from Arinc. Table 4 illustrates our technology survey for the Transceiver [4] [5] [6] [7].
Transceiver Company Characteristics Price Decision OTTO on Board MarkIV Range: 300 m
802.11p Data Rate: 27 Mbps
RS232 Serial Port
Not for Purchase Cannot be Bought
Q-Free RSE and OBE Q-Free Range: 20 m 802.11p
RS232 Interface USB Interface
- Too short Range
Tsunami QuickBridge Proxim Range: 100 m 802.11a/b/g
10/100Base-TXEthernet 54 Mbps (Max)
$2500.00 Too Expensive
Airbornedirect Serial Bridge Quatech Range: 100 m 802.11b/g
RS232 Interface Wireless AP
$236.00 Bought
Table 4: Overview of Transceiver Product Survey
19
Our key goals in the search of a transceiver were the following: 1. Range
The Accident Warning System is to work across a radius of 200 m around the ‘traffic light’. Hence, we need a transceiver which transmits and receives data over a range of about 250 m.
2. Interface
We are using laptops to act as the system which logs GPS data, calculates whether a car will run red light, and also as the system which receives the warning signal of a car running the red light and alerts the driver. The easiest and most convenient interface is the serial port. Hence, we looked for the RS232 port interface to be available in the transceiver.
We began our transceiver technology survey with the assumption that a commercially available 802.11p transceiver is available in the market. Upon researching and contacting the companies, MarkIV and Q-Free, we realized that our assumption was incorrect. Hence, we switched to finding an 802.11b transceiver which could work in lieu of the 802.11p transceiver. Once an 802.11p transceiver is available, then the 802.11b transceiver could simply be replaced. Our search for a suitable 802.11b transceiver brought us to the Proxim Tsunami QuickBridge. This product was perfect for a transceiver except for the fact that it was too expensive. The Quatech Airbornedirect Serial Bridge on the other hand, is as suitable as the Proxim Tsunami QuickBridge and is also within price range. Hence, we purchased the Airbornedirect Serial Bridge Development Kit. The Development Kit comes with the following components [4]:
1. AirborneTM Embedded Wireless Device Server 2. Evaluation Board (6” x 9”) 3. Access Point Router 4. Quick Start Guide 5. Power Supply 6. Serial Port Cable - DB9F to DB9M 7. ISP Cable - DB25M to DB25M 8. External Antenna 9. 9 Volt Battery 10. Software CD includes:
a. Evaluation utilities b. Kit user’s guide c. Module firmware d. Release notes
20
Figure 20: Airbornedirect Serial Bridge Development Kit
3.3 Current State-of-Art Practice Global Positioning System Currently commercial GPS receivers are capable of receiving Wide Area Augmentation Signals (WAAS) which gives these receivers an accuracy of around 3 meters depending on signal reception and environmental conditions. For some applications this is not an acceptable measure of accuracy. To overcome this obstacle the civilian sector has come up with the use of Differential Global Positioning System (DGPS) which was explained in detail earlier. There exist two different methods of DGPS implementation that vary on cost and accuracy. The first implementation uses the correctional signals from the beacons placed by the United States Coast guard, which can be accessed freely by any DGPS receiver. The only draw back in using this implementation is being in the area that has this coverage. This increases the accuracy of the GPS system to about 0.8 – 1 meter. A standalone GPS receiver is not enough to implement this solution as they are not equipped to receive the radio waves from the beacons. Two different hardware solutions are commercially available to implement a DGPS system.
• Magellan DG14 Board is equipped with both a GPS and a DGPS receiver, in other words, it can receive signals from both the GPS satellites and also from the United States Coast Guard beacons and provide correction ability. This board cost 1500 USD, which is a fairly expensive solution.
• Magellan AC12 Board can be attached to a DGPS Beacon receiver enabling it to receive both GPS satellite signals and the Coast Guard correction beacon signals. The AC12 Board cost 160 USD. A compatible and commercially available DGPS receiver is provided by NAVTEQ, the SBX-3 Board, which cost 425 USD with the DGPS antenna. This solution is relatively cheaper than the DG14 Board.
21
The second implementation makes use of local beacon stations installed and maintained by individuals. This implementation increases accuracy to a few centimeters. The AC12 Board can be used as a GPS receiver attached to transceiver can be used, along with a base station that has to be setup. The Magellan DG14 Board can be configured to act as a base station, but the correctional signals from the DG14 have to be transmitted to the receivers in the area. Two different types of transceiver solutions can be implemented that vary in cost and signal strength.
• Freeware provides low cost spread spectrum UHF receivers that can transmit correctional signals from the base station to the receivers. Using Freeware transceivers does not require a FCC license but they can only be used in direct line of sight setting due to signal characteristics. Hence, this implementation is not possible in urban settings.
• Pacific Crest is the other type of transceiver that can be used in setting with line of sight is not possible. This requires an FCC license and each transceiver costs 1200 USD. One transceiver will have to be installed on the base station and the other transceiver on the GPS receiver such as the AC12 Board.
Accident Warning System The state-of-the-art practice is currently being done by the PReVENT organization. This is a European project being conducted by a consortium of organizations ranging from car companies to electronics companies to universities. PReVENT is a much broader project than our accident warning system project. It deals with the following fields [1]: Safe Speed and Safe Following
• Co-operate seamlessly with the driver through the most suitable HMI channels, and suggest the proper velocity and headway for the given driving conditions.
• Automatic detection, locating and relevance check of hazards through traffic and
weather based on onboard sensors and a positioning system such as GPS.
• Testing a local, self-organized car-to-car communication system for establishing a decentralized communication network with both oncoming and following cars.
Lateral support and driver monitoring
• Examining a next generation adaptive lane-keeping support system, especially for use in situations where lane markings are missing, ambiguous or when the visibility is restricted.
• Studying a lateral and rear area monitoring application that enhances the driver’s
perception of collision risk in the lateral and rear area of the vehicle - especially when detection is very difficult due to limited visibility or critical overload on the driver’s attention.
22
• Testing a stand-alone lane-change assistance system with integrated blind spot detection that assists the driver in lane-change maneuvers while driving on multilane roads.
Intersection safety
• Speed recommendation to driver • Predicting the trajectories of the driver’s car and other nearby vehicles
• Testing a driving simulator allowing the development of active safety applications
with state-of-the-art and future technology.
• Investigation of an intersection infrastructure able to communicate bi-directionally with all vehicles passing the intersection. The traffic light is able to communicate the delay for the color change, and the vehicle is able to communicate an estimation of the friction coefficient in order to forward this information to other vehicles arriving at the intersection.
Function field vulnerable road users and collision mitigation
• Versatile 3D sensor technology for urban collision mitigation and protection (for pre-crash or blind spot surveillance applications),
• High performance sensor systems - including real-time object classification, capable
of reliably classifying pedestrians, bikes, motorcycles, cars and trucks
• Collision mitigation through the intervention of active structural components such as controllable bumpers, crash boxes, motor hoods, and safety belt pre-tensioners.
• Collision mitigation through autonomous or semi-autonomous braking, which
significantly reduces kinetic impact energy by mutual adaptation and suitable combination of sensors and actuators to achieve integrated, actuator-powered collision mitigation systems
• Collision mitigation in terms of pre-fire and pre-set applications, aiming to
improve the efficiency of reversible (belt-pre-tensioning) and non-reversible (airbags) restraint systems by providing additional set-up information to them
• Collision mitigation by prevention of truck acceleration from stationary, when
pedestrians or other VRUs are present in the blind spot area, in particular in front of the truck
We are of-course only concerned with the Intersection Safety aspect. As we mentioned earlier, the PReVENT Intersection Safety Project deals not only with an accident warning system but also with providing speed suggestions to drivers as well as path suggestions on the basis of trajectories calculated of other vehicles at the intersection. Traffic management also comes into play by traffic information at the intersection being analyzed and decisions being made upon them. Pedestrian warning is another aspect which is not present in our project.
23
We are using only a GPS to track a car’s speed and location. The PReVENT organization on the other hand uses a variety of technologies to accomplish the task of keeping intersection traffic information. Laser Sensor and Video Camera
These are within the vehicle and sense the road around for obstructions and moving vehicles. They also guide the vehicle in which they are located in terms of speed and path to be taken as the vehicle approaches the intersection. This is done by detecting lane markings and the white arrows indicating turning lanes. Figure 21 shows the area detected by the sensors.
Figure 21: Area of detection of on-board vehicle sensors
Figure 22 shows where the sensors are located in a vehicle.
Figure 22: Location of sensors in a vehicle
24
The sensors are also used to build a dynamic high-accuracy map of the intersection using static objects. This provides an accurate position of the vehicle on the intersection.
GPS
This provides the location of the host vehicle on the map. However, as a GPS is not very accurate in localizing exactly where the vehicle is located on the intersection, it is used alongside the on-board laser sensor and video camera in order to provide an accurate position of the vehicle.
Transceiver There are not any commercially available 802.11p transceivers in the market. Since OTTO on Board is the only 802.11p transceiver whose data sheet is available on the web – it is easily the state-of-art practice. The OTTO on Board has been developed by a consortium of companies including Arinc, MarkIV, Highway Electronics and Transcore to name a few. It is currently under test by the US Department of Transportation. A brief summary of the important features of the OTTO on Board are: 1. Range: 300 m 2. Data Rate: 27 Mbps 3. Interface: Serial Port Figure 23 shows the OTTO on Board transceiver logo.
Figure 23: OTTO on Board
25
3.4 Project Specification To summarize the Technology Survey section, our project specifications are shown in Table 5.
Transceiver GPS Company: Quatech Company: Garmin
IEEE Standard: 802.11b/g Range: 100 m
Accuracy: 5 m
Table 5: Project Specification
26
4 SYSTEM COMPONENTS Hardware Components:
• DPAC Airbornedirect Serial Bridge This is the OBE transceiver or the OnBoard Unit (OBU).
• Access Point/Router
We used a Linksys 802.11b/g router, but this can be replaced by any other router. The Linksys router had a range of up to 100 meters and acts as the RSU
• Laptop
As our project is to be built upon, laptops were used for software development. We used Dell Inspirion 6400 laptop for the OBE and an IBM ThinkPad for the RSE.
• Garmin GPS
Inaccuracy of 5 meters and updates itself every second. It is directly connected to the OBE laptop
Operating System:
• Windows 2000/XP Software Components:
• Visual Studio 2005 Road Calculations, GPS data parsing, reception and transfer were all carried out by C++ programs written in VS 2005. Installed on RSE and OBE laptops
• DPAC Airbornedirect Utility
This utility is installed on the RSE laptop. It allows us to fix the wireless settings such as the baud rate, etc of Airbornedirect Serial Bridge.
• DPAC Virtual Configuration Utility
This utility is installed on the RSE laptop. It allows us to specify to the router which wireless device it should connect to.
• Garmin GPS Spanner
GPS Spanner is a program which sets the virtual serial ports to receive data from the GPS as well as formally starts the GPS. This is installed on the OBE laptop.
4.1 Latency Calculations The scenario we are considering for an accident at an intersection is called Signalized Intersection, Straight Crossing Path. This means that the intersection consists of a traffic
27
light and we assume that the vehicle approaching the intersection plans on traveling straight; i.e. does not plan on making a turn. Background on SI/SCP Accidents For the purpose of a complete study on SI/SCP accidents, we performed a background literature search on the factors resulting in SI/SCP accidents [11]. Figure 24 provides background on the conditions under which SI/SCP crashes occur.
Snowy or Icy 2%
Wet Pavement 19%
Dry 79% No Adverse Weather
66%
Rain 12%
Snow/Sleet 12%
Daylight 72%
Dark, Lighted 22%
Dark, Unlighted
3%
Dawn/Dusk 3%
SI/SCP Crash Occurrence due to Pavement Condition
SI/SCP Crash Occurrence due to Ambient Weather Condition
SI/SCP Crash Occurrence due to Ambient Light Condition
Figure 24: Conditions under which SI/SCP Crashes occur
As we see from these charts, most of the accidents occur during normal conditions: dry pavement, no adverse weather conditions and daylight. Our system works for both normal and adverse conditions. Figure 25 shows the speed at which vehicles are traveling when the crash occurs.
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
0-5 6-10 11-15 16-20 21-25 26-30 31-35 36-40 41-45 46-50 51-55 56+ Travel Velocity (mph)
Figure 25: Travel Velocity of vehicle at time to crash Most of SI/SCP accidents seem to occur at velocities 35 mph or lower. This might be because of last minute rapid braking. Our system is very sensitive to rapid braking and issues alarms prior to when the braking occurs and if after braking it detects the vehicle is safe, the alarm stops. Figure 26 shows the most common reasons for the incidence of accidents.
28
Driver Inattention 36.4%
Failed to Obey Signal 23.2%
Tried to beat Signal 16.2%
Driver Intoxication 12.9%
Other 5.9%
Vision Obstructed 4.3% Vehicle Defect 1.9%
Figure 26: Reasons for SI/SCP Crashes Since the aim of our system is to alarm the driver on offense and the vehicles in the vicinity of the intersection of a possible collision, we directly address the issues of driver inattention, trying to beat the signal, and vision obstruction. These factors contribute to 57% of the accidents. Road Calculations There are four main to consider when judging whether a vehicle will run the red light.
1. Travel Speed 2. Time left before light turns red or remains red 3. Acceleration rate 4. Driver and machine reaction time delays
In order to address these factors, we need to consider some terminologies. Figure 27 shows the schematic of an intersection. Figure 27: Intersection Schematic • Clearance Zone (Dcz)
Clearance Zone is the distance from the stop line within which if a vehicle is present, it can easily and safely cross the intersection prior to the light turning red. This is an important first check in our system as it provides an initial status on the
29
vehicle and prevents us from performing several other checks before concluding that the vehicle is safe. This improves the efficiency of our program.
When we say that a vehicle has safely crossed the intersection, we mean that it has crossed the entire intersection as well as all of its length is completely after the stop line of the road to which the vehicle was crossing the intersection and moving towards. This distance has been shaded in Figure 27. We need the distance prior to the stop line in which a car needs to be present in order to be in clearance zone. Clearance Zone = Distance traveled in time before light turns red – Length of Car
– Width of Intersection Distance traveled in time before light turns red = Speed of vehicle x Time left for
light to turn red
If: vSV : speed of subject vehicle (SV) tA : time left for light to change state L : length of vehicle W: width of intersection Dcz = Clearance Zone
Dcz = vSVtA – L – W
Figure 28 shows the clearance zone at different speeds with different lengths of time left for the light to turn red.
0
50
100
150
200
250
300
5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
Speed (kph)
Dcz (
m)
Dcz30 Dcz25 Dcz20 Dcz15 Dcz10 Dcz5
Figure 28: Clearance zone at different speeds and different tA
‘Dcz30’ means there are 30 seconds left for the light to turn red. Similarly, ‘Dcz25’ means there are 25 seconds for the light to turn red, and so on. For example, if we take the speed of the car to be 55 kph and 5 seconds for the light to turn red, then we see from the graph that the vehicle needs to be within 60 meters of the stop line to be in the clearance zone.
30
If the light is currently green, then we want the vehicle to be close to the stop line and within the clearance zone in order for it to cross the intersection safely. If the light is currently red, we want the vehicle to be away from the stop line so hopefully by time it reaches the stop line, the light will have turned green. Thus, in this case, we want the vehicle to be outside the clearance zone.
• Dilemma Zone Dilemma Zone is the region in which if a car is present, then it cannot stop in time and neither can it cross the intersection safely before the light turns red. This region is present right before the clearance zone. One of the aims of traffic light design is to reduce the dilemma zone.
• Distance to Stop (Dstop)
Dstop is the distance required for the vehicle to come to a complete stop at its present deceleration rate. This distance is independent of the vehicle’s actual distance from the stop line.
Distance to Stop = Distance for car to stop + Extra distance traveled due to Human + Machine Delay
In order to calculate the distance for to stop, we use the fourth equation of motion:
v2 = u2 + 2as In our case: v = 0
Distance for car to stop = -v2SV/2a
Since the car is decelerating, a is negative. Thus:
Distance for car to stop = v2SV/2a
We assume:
Human Delay + Machine Delay = 2.0s Thus:
Dstop = v2SV/2a + 2vSV
If a vehicle is decelerating, Dstop in comparison with the vehicle’s actual distance from the stop line is an important check for whether a car will be able to stop in time.
We use these terms in judging whether a vehicle will run the red light. Before we introduce the system flowchart for the road calculation, there are some other terms we need to address:
• ts: time for subject vehicle to cross the stop line • tg: time left for light to turn green or remain green
31
• Dloc: actual distance of the vehicle from the stop line Now, let us assume that the light is green. Figure 29 shows the system flowchart.
Figure 29: System flowchart when light is currently green We see that despite the vehicle being in the clearance zone or the time for the vehicle to reach the stop line being after the light turns green, we keep checking if it remains in the clearance zone and if the time needed for the vehicle to reach the stop line remains greater than the time needed for the light to turn green. This is because drivers are unpredictable and we cannot guarantee that the vehicle will continue traveling at the same speed and acceleration rate. Figure 30 shows the system flowchart when the light is currently red.
32
Figure 30: System Flowchart for when light is currently red Upon comparison of figures 29 and 30, we notice that two checks have changed: 1) clearance zone. We rewrite the explanation for this here:
If the light is currently green, then we want the vehicle to be close to the stop line and within the clearance zone in order for it to cross the intersection safely. If the light is currently red, we want the vehicle to be away from the stop line so hopefully by time it reaches the stop line, the light will have turned green. Thus, in this case, we want the vehicle to be outside the clearance zone.
The second check which has changed is the comparison between time left for vehicle to reach the stop line versus the time left for the light to turn/remain green. Since the light is currently red in Figure 30, we want the vehicle to reach the stop line after the time left for the light to change state. While in Figure 29, when the light is currently green, we wanted the vehicle to reach the stop line prior to the time left for the light to change state. System Latencies The delay in transfer of data between each equipment is also of concern since all road calculations are performed real-time and any major delay would cause the failure of our system.
33
The transfer of data between all components physically wired together (RSE: RSE Laptop, RSU. OBE: GPS, OBE Laptop, OBU) suffers from no delay. The only delay possible is in the transmission of data wirelessly.
Baud Rate of our Wireless Connection = 2400 = 19200 bps
Size of Data being transmitted = 47 bytes = 376 bits
GPS update = every 1.0 second
Size sent = 376 bits per second
Ratio of Available bandwidth VS Used = 51:1 Since the size of data being sent is so relatively small to the available connection rate, we can safely assume that there is negligible delay between the transfer of GPS data from the OBE to the RSE.
4.2 Traffic Light The traffic light is virtually simulated through C++ on the RSE Laptop. The main components to consider when designing the traffic light were:
1. Length of One Cycle Traditionally, the length of one cycle is less than 200 seconds. We chose the length to be 180 seconds.
2. Length of Amber Light
When a light is about to turn red, there is a region before the stop line in which if a vehicle is present, then it cannot stop before the light turns red and neither can it cross the intersection safely. We used an analysis done by Gazis et. al, which can be seen in Figure 31.
34
Figure 31: Design amber times associated with various vehicle travel velocities
The formula associated with the graph is the following:
We took the average speed limit of 40 mph and chose 5 seconds for amber light length.
sv
svyDesignDelarDesignAmbe v
LWa
Vtt +++=
2
Figure 32 shows the timeline for one cycle of the traffic light.
85 s 5 s 90 s
90 s
Figure 32: Traffic Light Timeline for One Cycle In the context of the system, the traffic light is virtually simulated on the RSE laptop. It needs to provide a constant countdown to update the traffic light information on how many seconds are left for the light to change state. Figure 33 shows the virtual implementation of the traffic light.
35
…………………………GPS Data……………………… Traffic Light State Traffic Light Time
C++ Data Array
G G R
2 1 90
To: 5 cells
5 6
Figure 33: C++ Data Array consisting of GPS data in first 4 cells and traffic light data in last 2 cells The GPS is updated every second, and the RSE Laptop receives this information every second. Thus, all we need to set is the length of the countdown (90 seconds per state in our case) and which state to begin with. The traffic light state is represented in numbers. ‘1’ means that the light is currently green, while ‘2’ means the light is currently red. For example, if we want to start the traffic light countdown from 90 seconds to green, Figure 34 explains the system.
2 90 …………………………GPS Data………………………
Cell 5 Cell 6 1
Cell 2: Time
1 90 …………………………GPS Data………………………
Cell 5 Cell 6 + 1
Cell 2
1 - 1 …………………………GPS Data………………………
Cell 5 Cell 6 + 1
Cell 2
2 - 1 …………………………GPS Data………………………
Cell 5 Cell 6 + 1
Cell 2
Cell 6 = 1? Cell 5 = 2?
Figure 34: Traffic Light Flowchart
Yes
Yes
No
No
Cell 2 is the time data received from the GPS. It is the last two digits of the time – the seconds of the time. Thus, it starts at 00 and increments till 59 after which it reverts to 00 and continues looping.
4.3 Transceiver Communication We are using the Airbornedirect Serial Bridge as the OBU. As established earlier, the bridge has RS232 Serial Communication and is 802.11b/g compliant. Figure 35 shows the Airbornedirect Serial Bridge.
36
Figure 35: Airbornedirect Serial Bridge
Figure 36 shows the wireless connectivity arrangement for the system.
12 VDC
Ethernet
5 VDC
Serial
RSE OBE
Access Point
Bridge
802.11g
Figure 36: Wireless Connectivity Set-up of System The RSU – Access Point (AP) – is set-up by the following steps:
1. AP is accessed by entering its given IP Address in an Internet Browser. For the Linksys router we used, the IP Address was 192.168.1.1
2. Click on Wireless tab, then Wireless MAC Filter 3. Enable MAC Filter temporarily to view MAC Filter List 4. Search for Airbornedirect IP Address in AP’s Wireless Client MAC List (Figure 37)
Figure 37: RSU’s Wireless MAC List
5. DO NOT leave the MAC Filter enabled 6. Set COM 7 as Virtual Communication Port (Comport) in Virtual Configuration
Utility (VCOM) 7. Enter Airbornedirect IP Address in VCOM Comport 7 NMS Settings (Figure 38)
37
Figure 38: VCOM Comport 7 Set-Up
These steps are required because we need to specify which remote wireless device the RSU should connect to among all the wireless devices it is detecting. The OBE is set-up in the following steps:
1. Open Airbornedirect Utility program (AEU) 2. Under Network tab, select DHCP 3. Under Serial tab, change “TCP Session Inactivity Timeout” to 0 4. Under Serial tab, set Bit Rate, Data Bits, Parity and Flow Control
Dynamic Host Configuration Protocol (DHCP) allows for the device to automatically be assigned an IP Address upon network connection. This is contrary to the concept of Static IP Address where every time a device is booted, it has the same IP Address. DHCP is also enabled in the AP/router. We select TCP Session Inactivity Timeout to be 0 because we do not want the bridge to disconnect if it is not receiving any data. It should be connected or searching for connection continuously. The SSID needs to be the same in the AP as well as the AEU. Both are named DSRC currently. The current Baud Settings are:
• Bit Rate: 2400 • Data Bits: 8 • Parity: None • Flow Control: None
38
Figure 39: Current Baud Settings in AEU
These settings are used in the RSU and OBU C++ program for transferring data. If any changes are made to these settings, ensure that the C++ code is also changed accordingly. The settings specify the rate and type of control on the data being transmitted wirelessly. It is important that both the RSU and OBU have the same settings. 4.4 GPS-Laptop Communication GPS Spanner This program needs to be installed on the OBE laptop [12]. We set a virtual comport (up to the user) as the serial communication port receiving GPS data. We use this set comport in HyperTerminal to receive GPS data. Once the comport has been set, we need to always connect the GPS to the same USB port otherwise the spanner will not recognize the GPS. HyperTerminal HyperTerminal is a Windows session which allows remote devices to communicate with each other. In this case, let us assume that we set comport 1 as the serial port to receive GPS data. The following are the steps to view the GPS data on HyperTerminal:
1. Start :: Run :: Type hypertrm 2. Type GPS under Name. Click OK 3. Connect Using: COM1. Click OK 4. Bits per second: 2400 5. Data bits: 8 6. Parity: None 7. Stop bits: 1 8. Flow control: None. Click OK
We now see a string of GPS data on the HyperTerminal screen. The raw GPS data consists of a lot of pieces of information that are of no relevance to us. Figure 40 shows an extract of the raw GPS string.
39
Figure 40: Raw GPS String The only line we are interested in is the line starting with $GPRMC. In Figure 40, that line provides us with the following pieces of information:
• 200753 – Greenwich Meridian Time at the time when GPS was run • V – GPS is not connected to satellite. ‘A’ means connected to satellite • 4223.1073 – Latitude of current location in hours, minutes, seconds • N – direction of latitude • 07231.8678 – Longitude of current location in hours, minutes, seconds • W – direction of longitude • , - when speed is 0, ‘,’ is shown. This is the second comma after W
Thus, in order to extract only the relevant data, we wrote a GPS Parser C++ program. When we wrote the C++ program to directly extract GPS data from the serial port and parse it, either Visual Studio or the GPS software created a virtual buffer which caused delays in transfer of data. However, when we viewed the GPS data through HyperTerminal, there was no delay. Thus, we used HyperTerminal to capture all the output from the GPS into a text file named GPS_Read.txt. The text file was then opened using C++ to parse and transfer to the Airbornedirect Bridge (OBU), which then sent out the GPS data wirelessly to the AP (RSU). We instructed HyperTerminal to capture the GPS data onto a text file by:
1. Transfer menu :: Capture Text… 2. We specified the location to save the file in the folder consisting of the GPS Parser
VC++ Project, called GPS_Read Figure 41 shows the location of the GPS_Read.vcproj on my computer.
40
Figure 40: Location of GPS_Read VC++ Project
Thus, after Capture Text… I will put down the location as:
C:\Documents and Settings\Richa\My Documents\Visual Studio 2005\Projects\GPS_Read_Copy\GPS_Read\GPS_Read.txt
Note that I specifically put down GPS_Read.txt as the text file name. This is because the C++ program is set to use a text file with that name to read the GPS data. GPS_Read Program GPS_Read VC++ Project consists of 4 C++ source files and 1 header file. To execute the code:
1. Build menu :: Build Solution (F7) 2. Debug menu :: Start without Debugging (Ctrl+F5)
If an error occurs:
1. Project menu :: Properties 2. Configuration: All Configurations 3. Character Set: Use Multi-Byte Character Set
41
Figure 41: Set to Multi-Byte Character
If the error persists, make a new VC++ Empty Project and add all the source and header files into your newly created project. Once the code is executed, a DOS menu is seen as shown in Figure 42.
Figure 42: DOS OBU Menu
1. Open/Configure Airbornedirect Serial Port (OBU)
This is always the first selection made in this menu. It opens the serial port to the OBU. Select the serial port to which the OBU is connected to on the OBE Laptop. (This can be discovered by looking through the Device Manager)
42
2. Start Transmitter
Once the comport to the OBU is open, we select this option which then starts the transmitter. We also see a copy of what is being transmitted on our screen. The information is garbled but rest assured, the data transmitted to the RSU is only the relevant GPS information.
There are three text files located in the GPS_Read folder containing the VC++ Project.
1. GPS_Read.txt Contains the GPS data from HyperTerminal. File read by GPS_Read.vcproj
2. tester.txt
Contains position location of read cursor and character read from GPS_read.txt. This file is from debugging purposes
3. output.txt
Contains parsed GPS data which is also being sent to RSU and displayed on DOS screen through VC++
Perform the Capture Text… in HyperTerminal after you have run the GPS_Read program and set the serial port. This is because the three text files are deleted upon executing the program, and if HyperTerminal starts using the GPS_Read.txt then it would not get deleted which means that old data would be transmitted. In summary:
1. Start HyperTerminal to receive GPS data 2. Run GPS_Read.vcproj 3. Menu Item 1: Set Serial Port to Bridge 4. Capture Text… on HyperTerminal 5. Menu Item 2: Start transmitting GPS data
4.5 GPS Data Reception by RSE Build and Run the Road Side Unit.vcproj in the same manner as explained how to build and run GPS_Read.vcproj. If there are errors while running the program, then follow the same steps as explained in section 4.4. Upon executing the program, a DOS Menu appears as shown in Figure 43.
43
Figure 43: RSE Menu
Note that the menu starts from number 2. 2. Open/Configure Router Virtual Serial Port
If we had set the Router to serial port 7 in VCOM, then set to comport 7 3. Test GPS Data Transmission
Displays wirelessly received GPS data without any road calculations performed 4. Start Road Side Calculation
Begins road calculations and displays the calculations as performed real-time The details of serial port programming in C++ can be found in reference [13]. 4.6 RSE Algorithm The Road Calculation or RSE Algorithm is contained in the LatencyCalculation.cpp file. The algorithm is the implementation of the system flowcharts we saw in figures 29 and 30. An explanation of each function in LatencyCalculation.cpp:
• GPSRetrieve() Receives GPS data in a 5 cell array from DataAcquisitionTest.cpp. We want to have an array with two rows – one row consisting of latest data and the other row consisting of one second old data. This is for the purpose of calculating acceleration, which requires two sets of data. Figure 44 shows the 5 cell GPS array received at the start of the function.
Cell 4 Cell 3 Cell 2 Cell 1 Connection Time Latitude
Cell 5 …Traffic Light data… Speed Longitude
Figure 44: GPS Array – each row 2 Cells
44
Cell 1 contains information on whether the data being received is when the GPS is connected to the satellite. A connection means the value in Cell 1 is 1, otherwise it is 0. After creating the 2 x 7 GPS array with old and new GPS data, we tack on the last cells in each row consisting of traffic light information. The traffic light data is appended to the array in the manner explained in Section 4.2 As explained earlier in Section 4.2, the range for the time data is 00 to 59 after which it loops back to 00 and starts over. Thus, in cases where the new time is 00 and the old time was 59, and we are calculating the time difference between the two sets of data, we write a small code to compensate for this.
• CalcDloc()
This function calculates the distance in meters between two longitude and latitude coordinates given in degrees. For an explanation of the method, see [14].
• CalcDcz()
We set the length of the car to be 4.8 meters and the width of the intersection as 14.63 meters. These numbers are relevant to the testing site and vehicle used for our project. As explained in Section 4.1, we use the following formula for calculating the clearance zone:
Dcz = vSVtA – L – W
The velocity and time left for light to change state is retrieved from the GPS array.
• CheckAcc()
Acceleration = (Current velocity – Old velocity)/(Current time – Old time) This forms the check in our flowcharts in figure 29 and 30 to check if the vehicle is accelerating/cruising or decelerating.
• AccLess0()
If CheckAcc() shows that we are decelerating, we enter this function where we compare the distance required to stop at the vehicle’s current speed and deceleration rate (Dstop) versus the vehicle’s actual distance from the stop line (Dloc). The equation for calculating Dstop is restated here:
Dstop = v2SV/2a + 2vSV
The Dstop versus Dloc is a check of whether the system flow control should branch towards the final check prior to alarming the drivers in the vicinity of the intersection.
45
• Acc0OrMore() If CheckAcc() shows that we are accelerating/cruising, we enter this function where we calculate the deceleration rate that would be required at the vehicle’s present speed and distance from the stop line for it to come to a complete stop at the stop line. We use the fourth equation of motion:
v2 = u2 + 2as
In this case: v = 0
Predicted Deceleration = aPRED = -v2SV/2Dloc
The comfortable ranges vary depending on the distance of the vehicle from the stop line. For example, if a vehicle is very far away, say, at a distance greater than 30 meters, then the comfortable deceleration range would be 0 to 1.5 m/s2. If the vehicle is very close to the stop line, say within 20 meters, then any movement on the part of the vehicle would cause it to cross the stop line. Thus, there is no range for vehicles within the 20 meter distance of the stop line – the system simply alarms if it detects any movement of a vehicle in that distance range. The distance between 30 and 20 meters is tricky as a vehicle might be moving along very slowly but may require a deceleration rate greater than 1.5 m/s2, which is accomplished by sudden braking. Thus, for this distance, we put in a comfortable deceleration range of between 0 and 0.3 m/s2. There numbers are based on trial and error methods in the testing field.
• TimeGreen() This function compares the time for the vehicle to reach the stop line at its current speed and accelerate rate versus the time left for the light to change to green or remain green. This function is only accessed if: a) vehicle is decelerating and Dstop > Dloc, or b) vehicle is accelerating/cruising, and predicted deceleration rate is outside of comfortable range. Using fourth equation of motion:
v2 = v2SV + 2aDloc
v = (v2SV + 2aDloc)0.5
… v: velocity of vehicle when it has reached the stop line vSV: current velocity of subject vehicle a: acceleration rate calculated in CheckAcc() Dloc: distance from stop line calculated in CalcDloc() If we notice that v2 is negative, then we can conclude that the vehicle is probably decelerating currently, and it will be able to stop at a distance prior to Dloc: safe. If v2 is zero, then the vehicle is not moving. If the vehicle is accelerating, we use the first equation of motion:
46
v = u + at …v = calculated from fourth equation of motion u = vSV
t = tG = time to reach the stop line a = acceleration determined in CheckAcc()
tG = (v – vSV)/(a – 0.5) If the vehicle is cruising, we use the second equation of motion, as a = 0 in this case:
s = 0.5(v + u)t …s = Dloc v = calculated from fourth equation of motion u = vSV
t = tG = time to reach the stop line
tG = (2Dloc)/(v + vSV) This function performs the last check of whether the system should alarm. If it determines that the time for the vehicle to reach the stop line is earlier than the time left for the light to turn green or the time to reach the stop line is after the time left for the light to remain green, the system alarms.
• Alarm()
This function starts the alarm on the RSE and OBE. The alarm is not continuous in that it does not keep getting triggered if it is triggered once. Every time the full set of calculations is made and the system flow control reaches this function, the alarm is set. This is because our system does not compensate for sudden braking. It always assumes that the driver will brake smoothly. Thus, it might generate a premature alarm, and after the driver brakes rapidly, the alarm is not generated again.
• RSUlonglat()
This function sets the RSE longitude-latitude. Since, these pieces of data are fixed due to the RSE being fixed at the traffic light of the intersection, we can put in actual numbers (not variables) and set the longitude-latitude.
• latencyflowcontrol()
This function controls the branching shown in flowcharts in figures 29 and 30. A point of note is that if the vehicle is decelerating and Dstop > Dloc, the function only allows the system to alarm (enter Alarm()) when Dloc < 40 meters. This is to prevent any premature alarming. Another point to note is that all calculated and GPS array data is being saved in an excel file called output.xls. This file is for debugging purposes, and is found in the folder containing Road Side Unit.vcproj.
47
A final point of note is that when we retrieve GPS data by calling the GPSRetrieve() function, we have this call set in a while loop where the system keeps asking for new GPS data if it sees the connectivity to satellite is 0 (not connected)
• latencyflow() This function starts the latency calculations by setting the traffic countdown length per state and the traffic light state to start from. This gives us control in testing situations where we want the light to be a particular state when the vehicle reaches the stop line. If we set the traffic countdown length to be 40 seconds and starting state as red, then the total traffic light time would be 80 seconds: 40 seconds red, 40 seconds green, then it loops again. We also retrieve the first set of GPS data until we see the connectivity to satellite flag is 1, before passing the flow control to latencyflowcontrol().
4.8 Testing & Debugging Location Our testing site was the football stadium at the University of Massachusetts Amherst campus near University Drive. Figure 45 shows a satellite image of the site.
Figure 45: Satellite image of testing site at football stadium
48
Setup We chose a long stretch of road bordering the stadium (encircled in red in Figure 45), and placed the RSE at a three-way junction, while choosing the crosswalk at that junction as our stop line. Figure 46 shows the setup at the testing site.
Figure 46: System Setup at Test Site
RSE
OBE
System
Router (RSU)
RSE Laptop
OBE Laptop
Airbornedirect Serial Bride (OBU)
GPS
This set-up restricted us to the 100 meter range of the router as the connectivity when we approached from out-of-range to in-range was not very quick. This is due to our using an 802.11b/g transceiver which is not built for use in time-valued systems like these. Thus, as the RSE longitude and latitude can be fed into the road calculation code as a ‘hard number’; i.e. constant, we can have the RSE along with the OBE within the vehicle, since according to the road calculations, the system would always detect the RSE to be at the intersection. Thus, we could test the system from distances as large as we needed.
49
Tests
1. Clearance Zone Test This test was to check if the system correctly detected whether a vehicle is in the clearance zone. Thus, the part of the flowchart we tested is shown in Figure 47 (shows for light currently green).
Figure 47: Clearance Zone Check in Flowchart
As explained earlier, if the light is currently green, we want the vehicle to be inside the clearance zone; otherwise if the light is red, the vehicle should be outside the clearance zone. Table 6 shows one of the field test data for this test.
Table 6: Field Test Data for Clearance Test
We have replaced the To… data from 1 (to red. currently green) and 2 (to
2. Acceleration Test for a vehicle accelerating towards the intersection. Thus, if the
Speed (m/s) Traffic Light (s) To… Distance (m) Clearance Zone Distance (m) Alarm
13.5528
15.497
17.062
18.574
19.546
45
43
41
39
37
R
R
R
R
R
591.08
647.529
680.93
705.57
green. currently red) to R and G for easier understanding. As the light is currently green, we want the vehicle to be within the clearance zone, which it is throughout the test, thus no alarm was generated.
This test was light is red when the vehicle crosses the intersection, the alarm should be set-off. The portion of the flowchart under test is shown in Figure 48 (shows for light currently green).
704.386
118.992
89.761
57.571
24.42
14.44
0
0
0
0
0
In Dcz? a = + or 0? Calculate deceleration for v =0 at stop line
Comfortable range?
Time to reach stop line Warning ts < tg
Start Yes
Yes
No
No
No
Yes
Figure 48: Acceleration Test in Flowchart
50
Table 7 shows one of the field test data for this test.
We see from the data that we are always outside the clearance zone during
. Deceleration Test
on test is where a vehicle decelerates until it comes to a
Table 8 shows one of the field test data for this test.
Table 7: Field Test Data for Acceleration Test
green light and inside the clearance zone during red light, which is unwanted and branches the flow of control to check the acceleration rate of the vehicle. The predicted deceleration rate is within comfortable range till the speed reaches 19.222 m/s. At that point, the predicted deceleration range becomes -3.464 m/s2, which is greater than 1.5 m/s2. We then check the time for the vehicle to reach the stop line – 2.883 seconds, while the time left for the light to turn green 19 seconds. Thus, the alarm is set off. The predicted deceleration rate continues to be outside of comfortable range and the time to reach the stop line reduces at a rate faster than the countdown of the traffic light, therefore the alarm keeps being triggered.
3The deceleraticomplete stop at the stop line. Figure 49 shows the portion of the system flowchart being tested (shows for light currently green).
Figure 49: Deceleration Test Flowchart
Speed (m/s) Traffic Light (s) To Distance (m) Clearance (m) Alarm
15.335
17.062
18.0885
18.790
19.222
2
25
23
21
19
R
G
G
G
G
11.839
407.735
397.206
375.770
346.396
190.554
158.786
124.882
89.304
53.327
0
1
1
1
Time Stop (s) Predict acc (m/s2)
-0.617
-0.916
2.883
0.863
1.062
0
-1.31 0
-1.97 0
-3.464
310.705
274.366
-11.327 19.384
19.546
17
15
G 16.587
20.547 G -9.296
51
We are always inside the clearance zone during a green light, thus sending the
. System Test
begins at the vehicle a long distance away from the intersection. The
able 9 shows the field test data.
Table 8: Field Test Data for Deceleration Test
flow of control to check the vehicle’s acceleration rate. The first set of data seems to indicate the vehicle accelerated because the predicted deceleration column is filled. The distance of the vehicle at that point is greater than 30 meters so the comfortable deceleration range is 0 to 1.5 m/s2. Since the predicted deceleration rate is within the range, no alarm is set off. In the second set of data, we see that the vehicle has decelerated, and Dstop > Dloc as time to reach stop line (time stop) has been calculated. This time is 6.137 seconds while the time left for the traffic light to turn green is 33 seconds. Thus, the alarm is set-off. The vehicle continues to seen to break the red light, and thus, the alarm is set off repeatedly.
4This test vehicle accelerates, then decelerates until it comes to a stop at the intersection. Then it slowly creeps up and crosses the intersection. The test takes place under red light, and thus the alarm should finally be triggered. This test validates the entire system shown in Figure 30. T
17.8185
16.766
14.146
11.4471
8.96326
35
33
31
29
27
G
G
G
G
G
604.8186
528.199
419.722
313.135
223.178
107.641
75.030
46.65
23.342
8.936
0
1
1
1
1
6.137
4.512
2.602
0.613
Speed (m/s) Traffic Light (s) To Distance (m) Clearance (m) Time Stop (s) Predict acc (m/s2) Alarm
-1.475
52
Table 9: Field Test Data for System Test
We see that the vehicle is at rest at the beginning. Once it starts moving, the light is currently red, and it is outside the clearance zone which means it is safe. However, at the speed of 11.0691 m/s, it moves within the clearance zone, thus branching the flow of control to check the acceleration rate of the vehicle. We see that the car is accelerating until its speed reaches 16.1987 and during the entire time its predicted deceleration rate is within the comfortable range, thus not triggering the alarm. Once it starts decelerating, we see that the alarm is not triggered despite Dstop > Dloc because in order to prevent premature alarms, we have set the system to only alarm in the case of a decelerating vehicle, when it is within 40 meters of the stop line. When the vehicle enters the 40 meter range, we see that v2 (from Section 4.6) is negative, which means that the vehicle can stop before the stop line at its present deceleration rate. The vehicle comes to a complete stop with no alarm having been triggered off so far. But the vehicle starts accelerating again to cross the intersection during a red light and this time when detected that the vehicle is inside the clearance zone, and is moving, the alarm is triggered.
53
5 STATISTICAL ANALYSIS Our system always gives an alarm when it should. 5.1 Confidence of False Alarm The purpose of this test was to determine with 95% confidence the probability of a false alarm – an alarm when there should be none. We conducted 40 tests.
No. of tests = N = 40 Mean = 0.025
Standard Deviation = 0.156 Z* = 1.96
-0.0234 ≤ Sample Mean ≤ 0.0734 We usually take the tail ends of a normal distribution curve to be percentage leftover from confidence interval divided by 2; i.e. 2.5% on both ends for our 95% confidence case. Since the probability cannot be less than 0, we can ignore the left tail end. Thus, with 97.5% confidence, the probability of a premature/false alarm is less than 7.34%. Figure 50 shows the normal distribution with the shaded region being the confidence interval.
Figure 50: Normal Distribution of False Alarm
0.025 0.0734 0
2.5% 2.5%
The probability of false alarm is minute thus validating our system as very reliable. 5.2 Frequency of Alarm with Distance Figure 51 shows the histogram representing the frequency of alarm generated by the system with respect to the vehicle’s distance from the stop line.
54
0
50
100
150
200
250
300
350
0 10 20 30 40 50 60 70 80 90
Distance
Frequency
of
Ala
rm
Figure 51: Histogram of Alarm with Distance from Stop Line
cceleration and Cruising Behavior
he system starts alarming in the cases of acceleration and cruising tests the farthest from
ecelerating Behavior
he alarm for decelerating behavior is only seen after 40 meters because we have set in
hen the vehicle is 40 meters away, the first set of frequencies we see is for deceleration
s the vehicle approaches the stop line, we start seeing alarms triggered for vehicles
he histogram confirms the validity of our road calculations because it shows what we
Acceleration Cruising Deceleration (0-1 m/s2)Deceleration (1-2 m/s2) Decelera n (2-3 m/s2)tio
A Tthe stop line. We see the frequency increasing as the vehicle approaches the intersection because the system grows more confident that the vehicle will break the red light. D Tthe code to only trigger after 40 meters for this behavior. This is to avoid any premature alarms. Wrate of 0 to 1 m/s2. This is due to vehicles traveling at high speed and not decelerating at a rate which would indicate to our system that the vehicle will successfully stop at the stop line. There is zero frequency for deceleration rates of 1 to 3 m/s2 because the distance is great from the stop line and the deceleration rate is high. We see the frequency of alarms increasing as the vehicle approaches the stop line with a deceleration rate of 0 to 1 m/s2 because the system grows more confident of the vehicle breaking the red light. Adecelerating in the 1 to 3 m/s2 range. This is because of the speed of the vehicle being high and the deceleration rate not being high enough. Twould expect theoretically.
55
5.3 GPS Inaccuracy
he aim of this analysis was to determine the inaccuracy of the GPS. We noted a location
Figure 52: Scatter Plot of GPS longitude-latitude data
able 10 summarizes the relevant statistical information of the scatter plot.
Northings Westings Distance
Tin the Football Stadium using a Amherst Map from the W.E.B Dubois Library. We stood still at the location with the GPS and noted down the changes in the longitude-latitude data. Figure 52 shows the scatter plot of the data. The point circled in red is the actual longitude-latitude of the location according to the Map.
42.377730
42.377740
42.377750
42.377760
42.377770
42.377780
42.377790
42.377800
42.377810
42.377820
42.377830
42.377840
-72.534300 -72.534250 -72.534200 -72.534150 -72.534100 -72.534050
T
Mean -42.377787 72.534158 3.082612 Median 42.377784 -72.534158 3.177549 Mode 42.377785 -72.534153 4.064632
S td Dev 0.000021 0.000044 1.155778 Variance 0.000000 0.000000 1.335823 Skewness 0.085105 -0.052806 -0.360205 Maximum 42.377827 -72.534069 4.977798 Minimum 42.377743 -72.534248 0.374785
Range 84.183348 178.797882 8.603013 Count 91.000000 91 91
Table 10: GPS Inaccuracy Statistical Data
e conducted this test 91 times. We see that the mean distance error from the actual
his confirms the safety of the ranges we took into consideration to compensate for the
Wpoint is about 3 meters. The range of inaccuracy is about 8 meters, which is within the inaccuracy range specified by Garmin: ±5 meters. TGPS inaccuracy in our road calculations.
56
5.4 Confidence of Transceiver Connection Range
e ested the distance within which there was a connection between the RSU and OBU.
No. of tests = N = 143
Standard Deviation = 5.006 meters
90.886 ≤ Samp eters
ith 95% confidence we can say that there will be a connection at 91.706 ± 0.82 meters
igure 53 shows the normal distribution of the range with the shaded region being the
hus, the router
tW
We conducted this test 143 times and took the confidence interval to be 95%.
Mean = 91.706 meters
Z* = 1.96 le Mean ≤ 92.526 m
W Fconfidence interval.
Figure 53: Normal Distribution of Transceiver Connection Range
91.706 92.526
2.5% 2.5%
90.886
T falls short of its 100 meter specification by about 8 meters.
57
6 SUMMARY
.1 Conclusion
e conclude that all specifications have been met. The system passed all tests and
.2 Future Work
• GPS Inaccuracy Correction tatistical data on the GPS can be used to formulate
he other option is to buy a more accurate GPS, some of which are
300 meter range router
er router with a 300 meter router. Since the 300 meter
he best alternative is to use DSRC transceivers, which unfortunately are only
All road calculations on OBE
lems such as who pays for the repair of the RSE (US
Robustness of Road Calculations
s gives out premature alarms. The current system
Improve Code Efficiency
t would be to abolish the necessity of HyperTerminal in
Change to another Virtual Serial Configuration Program and Transceiver
s.
6 Wperforms within suitable parameters. 6
The scatter plot and sequations to provide for GPS inaccuracy correction. An example of this method can be seen in [15]. Thighlighted in Section 3.1.
•Replace the 100 metrange is theoretical and the signal degrades as one approaches 300 meters, use the 100 meter router as an Access Point to boost the signal across 300 meters. Tavailable in 2008.
•To avoid institutional probDOT? State? Vendor?), all road calculations can be done on the OBE. Thus, the RSE acts only to broadcast all messages received by it, which makes it an economically replaceable unit.
•As noticed, our system at timefinds it difficult to accommodate sudden braking. Thus, the road calculations pertaining to comfortable deceleration range and different speeds need to be taken into account. The system needs to be ‘transient’ in nature versus the current system where it works in black and white – above 1.5 m/s2 : alarm. Else: No alarm.
•A major improvemenattaining GPS data. Other improvements include editing the current code into a more compact version.
•Airbornedirect Serial Bridge is being phased out. VCOM has many bug
58
7
59
BIB
] Integrated Project PReVENT
LIOGRAPHY [1http://www.prevent-ip.org/ [2] Andreas Meier. Design of the Vehicular Safety Communication Architecture. http://www.tik.ee.ethz.ch/~andreame/tik/public/20050801-ma.pdf [3] Wikipedia
kipedia.org/http://www.wi [4] Quatech Airborne Evaluation Kit
less_products/ab%20eval%20kit.pdfhttp://www.dpactech.com/docs/wire [5] OTTO on Board
/pdf/FactSheet_OTTO_FactSheet1_101105.pdfhttp://www.ivhs.com [6] Proxim Tsunami QuickBridge
/quickbridge/index.htmlhttp://www.proxim.com/products [7] Q-Free Products
m/m/pro/?mid=m467&vn=736&mn=64http://www.q-free.co [8] Trimble GPS Tutorial
gps/index.shtmlhttp://www.trimble.com/ [9] United States Coast Guard DGPS Coverage http://www.navcen.uscg.gov/dgps/default.htm [10] FAA WAAS Coverage
/WAAS/waas-text.htmhttp://gps.faa.gov/Programs [11] U.S. Department of Transportation. Examination of Signalized Intersection, Straight
2] Garmin GPS Spanner Download wnloadsDetails.jsp?id=1627&product=010-00321-
Crossing Path Crashes and Potential IVHS Countermeasures [1https://buy.garmin.com/shop/store/do00&cID=139&pID=6445 [13] Bayer, Robertson. Windows Serial Port Programming http://www.robbayer.com/files//serial-win.pdf [14] Distance Using Longitude-Latitude
ew/54680.htmlhttp://mathforum.org/library/drmath/vi [15] Applied Single GPS Point Statistical Analysis to Geometric Correction of Digital
velopment.net/technology/gps/me05_072a.htmSatellite Imagery http://www.gisde
8 APPENDIX 8.1 RSE Code RoadSideUnit.h #ifndef _RoadSideUnit_H #define _RoadSideUnit_H #include <iostream> #include <string> #include <stdlib.h> #include <cstdlib> #include <windows.h> #include <conio.h> #include <mmsystem.h> #include <ctype.h> #include <process.h> #include <sstream> #include <stdio.h> #include <fstream> #include <math.h> #include <iomanip> using namespace std; void clrscr(); void exit(); char byte_receive_traffic_light(); char byte_receive_airborne(); void byte_send(unsigned char byte); void main_menu(); void com_menu(char menu); void set_serial_timeouts(char menu); void open_serial_port(char *port, char menu); void set_serial_port(char menu);
60
voi atatest(); voi trafficlightdatatest(); o roadsideunit();
d ddid
float receive_time(); ude();
void GPSdata();
void test();
nit.h"
= GetStdHandle(STD_OUTPUT_HANDLE); rd = {0, 0};
count; bi;
fo(hStdOut, &csbi); ut, ' ', csbi.dwSize.X * csbi.dwSize.Y, coord, &count); , coord);
v
float receive_latitloat receive_longitude(); f
float* data();
void RetrieveGPS(); void CalcDloc(); int CheckAcc(); int AccLess0(); int Acc0orMore(); int TimeGreen(); void Alarm(); void latencyflow(); void RSUlonglat(); #endif ClearScreen.cpp #include "RoadSideU void clrscr() {
HANDLE hStdOut COORD coo DWORD CONSOLE_SCREEN_BUFFER_INFO cs GetConsoleScreenBufferIn FillConsoleOutputCharacter(hStdO
orPosition(hStdOut SetConsoleCurs}
61
DataAcquisition.cpp
t.h" #include "RoadSideUni float* data() {
cdata = new float *cali
float[7]; lize;
; ictime[2]; state;
ity;
e;
loat speed; float state;
ime; initilize = byte_receive_airborne();
(')
itilize = byte_receive_airborne();
initilize = byte_receive_airborne(); }
char init sign; char
char hour[2]; ; char min[2]] char sec[2
char traff char traffic
char valid;lid float va
float second; d float longitu
float latitude; f float tt while(initilize != '
{ in
} valid = byte_receive_airborne(); if(valid == 'A')
; validity = 1 if(valid == 'V') validity = 0; initilize = byte_receive_airborne(); while(initilize != ')')
{
62
initilize = while
byte_receive_airborne(); (initilize != '$')
initilize = byte_receive_airborne(); ; i++)
{ ur[i] = byte_receive_airborne();
_receive_airborne();
2; i++)
e_airborne();
ive_airborne(); '*')
_receive_airborne(); ive_airborne();
'@') byte_receive_airborne();
+) = byte_receive_airborne();
= -1*latitude; airborne();
'#') ceive_airborne();
initilize = byte_receive_airborne();
n[10];
for(int i = 0; i < 2
ho } for(int i = 0; i < 2; i++) { min[i] = byte } for(int i = 0; i < { sec[i] = byte_receiv } second = atof(sec); initilize = byte_rece while(initilize != initilize = byte initilize = byte_rece while(initilize != initilize = cout.precision(8); char lat[10]; for(int i = 0; i < 9; i+ lat[i] latitude = atof(lat); sign = byte_receive_airborne(); if(sign == 'S') latitude initilize = byte_receive_ while(initilize != initilize = byte_re initilize = byte_receive_airborne(); while(initilize != '!')
cout.precision(8); char lo
63
for(int i = 0; i < 9; i++) { lon[i] = byte_receive_airborne(); }
de = atof(lon); longitu sign = byte_receive_airborne();
== 'W') if(sign longitude = -1*longit
ze = byte_receive_aiude; rborne();
rborne();
);
);
/ affic_light(); / affic_light();
_light();
/
/
initili while(initilize != '%')
nitilize = byte_receive_airborne(); i initilize = byte_receive_ai
nitilize != '^') while(i initilize = byte_receive_airborne();
ecision(8); cout.pr char spe[10]; for(int i = 0; i < 9; i++)
ive_airborne( spe[i] = byte_rece speed = atof(spe); initilize = byte_receive_airborne(); while(initilize != '&') initilize = byte_receive_airborne();
_traffic_light(); // initilize = byte_receive'$') // while(initilize !=
// { // initilize = byte_receive_traffic_light(// } / traffictime[0] = byte_receive_tr
byte_receive_tr/ traffictime[1] =// trafficstate = byte_receive_traffic/ / ttime = atoi(traffictime); / if(trafficstate == 'R') // state = 1; / / if(trafficstate == 'G') / state = 2; calcdata[0] = validity; calcdata[1] = second;
ude; calcdata[2] = latit
64
calcdata[3] = longitude; a[4] = speed; calcdat
// calcdata[5] = state; a[6] = ttime; // calcdat
return calcdata; } DataAcquisitionTest.cpp #include
= byte_receive_airborne();
valid
byte_receive_airborne();
eceive_airborne(); '$')
"RoadSideUnit.h" oid dv atatest() { clrscr(); char initilize; char traffictime[2]; char trafficstate; char valid; initilize = byte_receive_airborne(); for(;;) { initilize = byte_receive_airborne(); while(initilize != '(') { initilize }
= byte_receive_airborne(); cout << valid; cout << " "; initilize = byte_receive_airborne();
') while(initilize != ') {
lize = initi }
= byte_r initilize while(initilize != {
65
initilize = byte_receive_airborne();
ive_time(); ; _receive_airborne();
'*') { initilize = byte_receive_airborne();
initilize = byte_receive_airborne(); e != '@')
initilize = byte_receive_airborne();
itude = receive_latitude(); ;
eive_airborne(); '#')
airborne();
= byte_receive_airborne();
byte_receive_airborne();
'%')
} int time = rece cout << " " initilize = byte
while(initilize != } while(initiliz
{ } float lat cout << " " initilize = byte_rec
while(initilize != { initilize = byte_receive_ } initilize while(initilize != '!') {
= initilize }
ongitude = receive_longitude(); float l cout << " ";
eive_airborne(); initilize = byte_rec while(initilize != {
e_airborne(); initilize = byte_receiv } initilize = byte_receive_airborne();
(initilize != '^') while {
e_airborne(); initilize = byte_receiv }
66
cout.precision(8); e[10]; char sp
for(int i = 0; i < 9; i++) {
byte_receive_airborne();
t(); /
ht();
);
spe[i] = byte_receive_airborne(); }
peed = atof(spe); float s cout << speed;
ze = byte_receive_airborne(); initili while(initilize != '&') {
nitilize = i }
" "; cout <</ / initilize = byte_receive_traffic_ligh
= '$') / while(initilize !// {
e_traffic_lig// initilize = byte_receiv// } // traffictime[0] = byte_receive_traffic_light();
time[1] = byte_receive_traffic_light(); // traffic// trafficstate = byte_receive_traffic_light(
; // int ttime = atoi(traffictime) ttime; // cout <<
// cout << " "; trafficstate; // cout <<
cout << "\n"; RSUlonglat(); } } float receive_time() { char time[6]; for(int i = 0; i < 6; i++) { time[i] = byte_receive_airborne();
time[i]; cout <<
67
} ); float inttime = atof(time
eturn r inttime; }
ude() float receive_latit { cout.precision(8); char lat[9]; char sign;
; i < 9; i++) for(int i = 0 {
= byte_receive_airborne(); lat[i] } f latitude = atof(lat);
; loat ign =
rn
at eceiv
out.phar l
)
on[i] = byte_receive_airborne(); }
= atof(lon); sign = byte_receive_airborne();
ude;
s byte_receive_airborne()'S') if(sign ==
latitude = -1*latitude; < itude; cout < lat
etu r latitude; } flo r e_longitude() { c recision(8); c on[9]; char sign; for(int i = 0; i < 9; i++ {
l float longitude if(sign == 'W') longitude = -1*longit
longitude; cout << return longitude; }
68
LatencyCalculation.cpp nclude "RoadSideUnit.h" #i
static double gps[2][7], static double phi1, theta
a, Dloc, a_pred, longitude, latitude, treach, v, vsq, Dstop; 1, phi2, theta2, c, R = 6356750.0, time;
art_sec, tl_start, tl_state;
latitude longitude speed TL(R/G) TL(s) 3 | 0,4 | 0,5 | 0,6 | 3 | 1,4 | 1,5 | 1,6 |
oid R
w GPS data
//gps array
gps data into a row of gps array <5; j++)
= gps[1][j]; = gps1[j];
f yes, restart countdown and change traffic light state
art-1;
a e = 2;
static double l, w, Dcz, tl_ststatic int q=0; //gps array
connect time // // old | 0,0 | 0,1 | 0,2 | 0,
| 1,0 | 1,1 | 1,2 | 1,// new v etrieveGPS() { //loops twice to get two sets of ne
i++) for(int i=0; i<2; {
float* gps1 = data(); //transfer all for(int j=0; j {
[j] // gps[0] gps[i][j] } //check if traffic light time is 1 s. I
/else continue counting down / if(tl_start_sec == 1) {
= tl_st tl_start_sec
tate = 1) if(tl_s =t tl_st
69
else tl_state = 1;
_sec = tl_start_sec - 1;
0][6] = gps[1][6]; gps[i][6] = tl_start_sec;
gps[1][1]+60-gps[0][1];
time = gps[1][1]-gps[0][1];
gps[0][1]<<"\t"<<gps[0][2]<<"\t"<<gps[0][3]<<"\t"<<gps[0][4]<<"\t"<<gps[0][5]<[6]<<"\n";
out<< ][ ]<<"\ ]<<"\t"<<gps[1][3]<<"\t"<<gps[1][4]<<"\t"<<gps[1][5]<"\t"<<gps[1][6]<<"\n";
atitude in degrees data udeOBU, latitudeOBU;
eta2)+cos(phi1)*cos(phi2);
} else tl_start //fill last two cells of gps array // gps[0][5] = gps[1][5]; gps[i][5] = tl_state; // gps[ } //compensate for new time: 00 and old time: 59 if(gps[1][1]<gps[0][1]) time = else
cout<<gps[0][0]<<"\t"<<<"\t"<<gps[0] c gps[1][0]<<"\t"<<gps[1 1 t"<<gps[1][2<} void CalcDloc() { //finds distance using longitude and l double longit longitudeOBU = gps[1][3]; latitudeOBU = gps[1][2]; ofstream distance("distance.txt", ios::app); phi2 = 90 - latitudeOBU; theta2 = longitudeOBU; c = sin(phi1)*sin(phi2)*cos(theta1-th
70
Dloc = R*acos(c)*3.142/180;
on(8);
<latitudeOBU<<"\t"<<phi2<<"\t"<<theta2<<"\t"<<c<<"\t"<<Dloc<n";
)
"\n";
<endl;
//acceleration < 0
n(8); cout.precisio
distance.precisi
= "<<Dloc<<"\n"; cout<<"Dloc distance<<time<<"\t"<<longitudeOBU<<"\t"<<"\ distance.close(); }
(void CalcDcz {
istance //calculates clearance zone d l = 4.2;
w = 14.63;
cout<<"Dcz: gps[1][4] = "<<gps[1][4]<< cout<<"Dcz: gps[1][6] = "<<gps[1][6]<<"\n"; Dcz = gps[1][4]*gps[1][6] - l - w; cout<<"Dcz = "<<Dcz<<"\n"; } int CheckAcc() { //checks if car is accelerating/cruising or decelerating
a = (gps[1][4] - gps[0][4])/time; // cout<<"CheckAcc: a = "<<a<
if(a>=0) return 1; //acceleration >= 0 else
return 2; }
71
i cLess0() nt Ac
)/(2*abs(a)) + (2*gps[1][4]);
(Dstop>Dloc) //towards alarm - requires more distance to stop than is available
return 2;
t Ac
//different comfortable ranges for different distances se to stop line - obviously, even small accelaration is dangerous
Dloc>20)
//Towards alarm: not in comfortable range
{ //checks if Dstop < Dloc Dstop = (gps[1][4]*gps[1][4]
CalcDloc(); cout<<"Dstop = "<<Dstop<<endl;
if return 1;
else } ni c0orMore() { CalcDloc(); // cout<<"Acc0orMore: Dloc = "<<Dloc<<endl;
a_pred = -(gps[1][4]*gps[1][4])/(2*Dloc);
endl; cout<<"a_pred = "<<a_pred<< //too clo
if(Dloc>30) if (a_pred<-1.5)
return 1; //Towards alarm: not in comfortable range else return 2; if(Dloc<=30 && if(a_pred<-0.3)
return 1; else
return 2;
72
if(Dloc<= if
20) (a_pred<0)
t
[1 ][<vsq<<"\n";
if(vsq>0)
= sqrt(vsq);
cout<<"TimeGreen(): a = "<<a<<"\n";
4]);
4])/(a-0.5);
//20R....should cross before countdowns
return 1; else
n 2; retur}
TimeGreen() in{ //calculate time to reach stop line
][4]*gps[1 4])+(2*(a-0.5)*Dloc); vsq = (gps cout<<"v squared = "< {
v / /
if(a == 0) treach = (2*Dloc)/(v + gps[1][
else if(a != 0) treach = (v - gps[1][
cout<<"treach = "<<treach<<"\n"; } if(vsq==0)
out<< c "Car at stop line\n"; if(vsq<0)
return 2; if(gps[1][5]==1)
f(tre [6 i ach>gps[1] ]) rn 1; //Alarm retu
else return 2;
73
if(gps[1][5]==2) //20G....should cross after countdowns
//Alarm
"\n\a";
d R Ulong
90-la
l()
alarm=0;
atitude
\tR/G\tTL\tDcz\tDstop\tDloc\tc1\tc2\tc3\tAcceleratiottreach\tAlarm"<<endl;
if(treach<gps[1][6]) rn 1; retu
else return 2;
}
Alarm() void { //send alarm to OBE byte_send('X'); //alarm in RSE
Alarm"<< cout<<"} voi S lat() { //assumptions longitude = -72.534322; latitude = 42.376835;
titude; phi1 = theta1 = longitude; } void latencyflowcontro {
, c2, c3, enter=0, check=0, int c1 //set RSU longitude/l
RSUlonglat();
ory data //output file containing traject ofstream outfile("output.xls");
tTime\tLatitude\tLongitude\tSpeed outfile<<"c2\tv\n\tAcc_pred\tV-squared\tVelocity\
74
CalcDcz(); CalcDloc(); c2 = 0; //always loop while(c2 == 2 || enter == 0
{ )
c1 = 0; 2 = 0; 3 = 0;
//not entered first time? yes; clearance zone check != 0)
RetrieveGPS(); CalcDcz(); CalcDloc();
Dcz = "<<Dcz<<"\n"; = "<<Dloc<<"\n";
(gps[0][0] == 0 || gps[1][0]==0);
ng scenario
{ ither tl = 0 or car not moving"<<endl;
= 1;
c
c alarm = 0;
if(enter do
{
// cout<<"// cout<<"Dloc }
while //car not movi
if(Dcz<-18.83) cout<<"E
check c2 = 2;
} else
0; check = enter = 1; //for green: car should be outside Dcz if(gps[1][5] == 1)
75
{ loc<Dcz && check==0)
cout<<"In Clearance Zone\n"; 2=2;
r should be inside Dcz == 2)
(Dloc>Dcz && check==0)
}
Accelerating/cruising or decelerating
;
n clearance zone, enter 0)
Acc0orMore(); //if not in comfortable deceleration range: c2 = 1 && check==0)
AccLess0(); //if Dstop>Dloc: c2 = 1
//if at stop line, exit program
if(D {
c }
} //for red: ca if(gps[1][5] {
if {
n Clearance Zone\n"; cout<<"Ic2=2;
} //Decision for Check 1: //for green if(gps[1][5] == 1)
f(Dloc>Dcz && check==0) i c1 = CheckAcc(); //for red if(gps[1][5] == 2)
f(Dloc<Dcz && check==0) i c1 = CheckAcc();
"\n" cout<<"c1 = "<<c1<< //if not i if (c1 == 1 && check==
c2 = else if(c1 == 2
c2 =
if(Dloc == 0)
76
c2=0;
& check==0)
//if time to reach stop line < time for light to turn
//if negative: means decelerating and can stop before
;
//Check 4: Alarm?
] > 12) //to avoid premature alarms
Alarm();
} c2
ion( );
<<c2<<"\n"; cout<<"c2 = "
outfile<<c2<<"\t";
rning? //Check 3: Wa== 1 & if (c2
{ c3 = TimeGreen(); green: c3 = 1
f(vsq<0) istop line. no alarm
2=2; c }
<<c3<<"\n" cout<<"c3 = "
if (c3 == 1 && check==0) { if(c1 == 2) if(Dloc < 40 && gps[1][4 {
alarm = 1; } if(c1 != 2)
{ alarm = 1;
Alarm(); } c2 = 2;
= 2;
//outputting to a file outfile.precis 8
77
outfile<<gps[1][0]<<"\t" <<gps[1][1]<<"\t"<<gps[1][2]<<"\t"<<gps[1][3]<<"\t"<<gps[1][4]<<"\t"<<gps[1][
p<<"\t"<<Dloc<<"\t"<<c1<<"\t"<<c2<<"\t"<<c3<<"\t"<<a<<"\t"<<a_pre<<alarm<<endl;
ted to satellite
stem Interface Setup for Road Side Unit (RSU)\n";
5]<<"\t"<<gps[1][6]<<"\t"<<Dcz<<"\t"<<Dsto<"\t"d<<"\t"<<vsq<<"\t"<<v<<"\t"<<treach<
} outfile.close(); } oid l tency low()v a f { //set traffic light length and starting state tl_start = 91; tl_state = 2;
= tl_start; tl_start_sec //keep getting gps data until connec
do { RetrieveGPS();
c(); // CalcDlo }
hile( ps[0] 0] == w g [ 0 || gps[1][0]==0); latencyflowcontrol(); } Menu.cpp #include "RoadSideUnit.h" void main_menu() { clrscr(); cout << " Sy cout << "\n"; cout << "\n"; cout << "\n";
78
cout << "\n"; // cout << " 1. Open/Configure Traffic Light Serial Port\n"; cout << "\n";
" 2. Open/Configure Router Virtual Serial Port\n"
cout << " Main Menu\n";
;
" 3. Test GPS Data Transmission\n"; cout << "\n";
4. Begin Road Side Calculation\n";
Selection 1 - 5: \n";
= _getch();
'2' && ch != '3' && ch != '4' && ch != '5');
break; case '2' :
com_menu('A'); break;
(); break; '4' :
: it();
cout << cout << "\n";
cout << cout << "
cout << "\n"; cout << " 5. Exit\n"; cout << "\n";
cout << "Enter cout << "\n";
int ch; do {
h c ch = toupper(ch); }
h != '1' && ch != while(c switch(ch)
{ case '1' :
com_menu('T');
case '3' : datatest
case // test(); latencyflow();
eak; br case '5' ex
79
} } oi enu) v om_menu(char md c
or Road Side Unit (RSU)\n";
Serial Port Selection Menu\n";
. COM3\n"; " 4. COM4\n"; " 5. COM5\n";
"Select Serial Port To Open 1 - 9 Or X To Exit To Main Menu: \n";
(ch);
= '2' && ch != '3' && ch != '4' && ch != '5' && ch != '6' && ch != '7'
& ch != '9' && ch != 'S' && ch != 's' && ch != 'X' && ch != 'x');
ort("//./COM1", 'T');
{ clrscr(); cout << " System Interface Setup f cout << "\n"; cout << "\n"; cout << "\n"; cout << " cout << "\n"; cout << " 1. COM1\n";
. COM2\n"; cout << " 23 cout << "
cout << cout <<
cout << " 6. COM6\n"; cout << " 7. COM7\n";
" 8. COM8\n"; cout << cout << " 9. COM9\n"; cout << "\n";
cout << int ch; if(menu == 'T') { do {
); ch = _getch(er ch = toupp
} ch ! while(ch != '1' &&
&& ch != '8' & if(ch == 'X' || ch == 'x')
main_menu();') else if(ch == '1
open_serial_p
80
e
lse if(ch == '2') open_serial_port("//./COM2", 'T');
else if(ch == '3') rial_port("//./COM3", 'T'); '4')
n_serial_port("//./COM4", 'T');
ch == '6') en_serial_port("//./COM6", 'T');
ort("//./COM8", 'T');
ort("//./COM9", 'T');
= '1' && ch != '2' && ch != '3' && ch != '4' && ch != '5' && ch != '6' && ch != '7'
ch != '8' && ch != '9' && ch != 'S' && ch != 's' && ch != 'X' && ch != 'x'); 'X' || ch == 'x')
, 'A');
lse i
"//./COM4", 'A');
open_se
else if(ch == ope else if(ch == '5')
en_serial_port("//./COM5", 'T'); op else if( op else if(ch == '7')
en_serial_port("//./COM7", 'T'); op else if(ch == '8') open_serial_p else if(ch == '9') open_serial_p } if(menu == 'A') { do {
= _getch(); ch ch = toupper(ch); } while(ch !&&
= if(ch = main_menu(); else if(ch == '1')
pen_serial_port("//./COM1" o else if(ch == '2') open_serial_port("//./COM2", 'A'); e f(ch == '3')
/COM3", 'A'); open_serial_port("//. else if(ch == '4')
ort( open_serial_p else if(ch == '5')
81
open_serial_port("//./COM5", 'A');
imeou
ltiplier = 10; = 50;
ease Check Serial Port Connections And Try
else if(ch == '6') ort("//./COM6", 'A'); open_serial_p
else if(ch == '7') ort("//./COM7", 'A'); open_serial_p
else if(ch == '8') ort("//./COM8", 'A'); open_serial_p
else if(ch == '9') ort("//./COM9", 'A'); open_serial_p
} }
ortConfiguartP ion.cpp
#include "RoadSideUnit.h" HANDLE TrafficSerial; CB dcD bTraffic;
neSerial;HANDLE AirBorDCB dcbAirBorne; void set_serial_timeouts(char menu) {
) if(menu == 'T' { COMMTIMEOUTS timeouts = {0}; t ts.ReadIntervalTimeout = 50;
nstant = 50; timeouts.ReadTotalTimeoutCotMu timeouts.ReadTotalTimeou
timeouts.WriteTotalTimeoutConstant timeouts.WriteTotalTimeoutMultiplier = 10;
(TrafficSerial, &timeouts)) if(!SetCommTimeouts {
r Setting Port Timeouts. Pl cout << "ErroAgain\n"; exit(); }
82
} f(men i u == 'A')
{ ts = {0}; COMMTIMEOUTS timeou
timeouts.ReadIntervalTimeout = 50; imeoutConstant = 50; timeouts.ReadTotalT
timeouts.ReadTotalTimeoutMultiplier = 10; TimeoutConstant = 50; timeouts.WriteTotal
timeouts.WriteTotalTimeoutMultiplier = 10; f(!SetCommTimeouts(AirBorneSerial, &timeouts)) i
{ cout << "Error Setting Port Timeouts. Please Check Serial Port Connections And Try
xit(); }
har *port, char menu)
'T')
l); t = port; ial = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING,
)
u('T');
Again\n"; e
} } void open_serial_port(c{
if(menu == {
CloseHandle(TrafficSeria char *zpor
rafficSer TFILE_ATTRIBUTE_NORMAL, 0); if(TrafficSerial == INVALID_HANDLE_VALUE) { if(GetLastError() == ERROR_FILE_NOT_FOUND { CloseHandle(TrafficSerial); cout << "\n";
<< "\n"; cout cout << "Serial Port Does Not Exist. Press Any Key To Continue\n"; _getch(); com_men
}
83
cout << "\n"; << "Unexpected Error\n"; ();
out ";
<< "Please Wait While Port Parameters Are Set.....\n"; out << "\n";
Sleep(1400); set_serial_port('T');
e(AirBorneSerial);
GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING,
t Does Not Exist. Press Any Key To Continue\n";
cout exit
} clrscr(); cout << "\n"; cout << "\n"; cout << "Opening Serial Port "; cout << zport[4]; cout << zport[5];
zport[6]; cout << cout << zport[7]; c << zport[8]; cout << "........\n
"\n"; cout <<out c
c }
if(menu == 'A') {
loseHandl C char *zport = port;
ateFile(port, AirBorneSerial = CreFILE_ATTRIBUTE_NORMAL, 0); if(AirBorneSerial == INVALID_HANDLE_VALUE) {
f(GetLastError() == ERROR_FILE_NOT_FOUND) i {
loseHandle(AirBorneSerial); C cout << "\n"; cout << "\n"; cout << "Serial Por _getch(); com_menu('A'); }
"\n"; cout <<
84
cout << "Unexpected Error\n";
rial Port ";
Port Parameters Are Set.....\n";
);
char menu)
))
;
9600;
Y; &dcbSerialParams))
exit(); }
); clrscr( cout << "\n"; cout << "\n"; cout << "Opening Se cout << zport[4]; cout << zport[5]; cout << zport[6]; cout << zport[7]; cout << zport[8]; cout << "........\n"; cout << "\n";
t While cout << "Please Wai cout << "\n"; Sleep(1400);
' set_serial_port('A } }
al_port(void set_seri{
f(men i u == 'T') { DCB dcbSerialParams = {0}; dcbTraffic.DCBlength = sizeof(dcbSerialParams);
CommState(TrafficSerial, &dcbSerialParams if(!Get {
"Unexpected Error. Please Check Serial Port Connections And Try Again.\n" cout << exit(); } dcbSerialParams.BaudRate = CBR_ dcbSerialParams.ByteSize = 8;
ONESTOPBIT; dcbSerialParams.StopBits = dcbSerialParams.Parity = NOPARIT
ate(TrafficSerial, if(!SetCommSt {
85
cout << "Error Setting Port Paramaters. Please Check Serial Port Connections And Try
('T'); uts Set.\n";
n";
To 8.\n";
n";
None.\n";
\n";
'A') {
= {0}; h = sizeof(dccSerialParams);
mState(AirBorneSerial, &dccSerialParams))
rror. Please Check Serial Port Connections And Try Again.\n";
ity = NOPARITY; lParams))
. Please Check Serial Port Connections And Try
Again\n"; xit(); e
} set_serial_timeouts cout << "Port Timeo cout << "\n";
To 2400.\ cout << "Baud Rate Set cout << "\n"; cout << "Byte Size Set cout << "\n"; cout << "One Stop Bit.\ cout << "\n";
Set To cout << "Parity Bit cout << "\n";
d Successfully. Press Any Key To Continue cout << "Port Opene _getch(); main_menu(); }
if(menu == DCB dccSerialParams
dcbAirBorne.DCBlengt if(!GetCom
{ cout << "Unexpected E exit(); }
alParams.BaudRate = CBR_2400; dccSeri dccSerialParams.ByteSize = 8;
pBits = ONESTOPBIT; dccSerialParams.StoalParams.Par dccSeri
if(!SetCommState(AirBorneSerial, &dccSeria { cout << "Error Setting Port ParamatersAgain\n"; exit(); }
86
set_serial_timeouts(out
"Baud Rate Set To 2400.\n";
n";
sfully. Press Any Key To Continue\n";
t()
d;
Open. Press Any Key To Continue\n";
Re dFile
"Unable To Recieve Data. Check If Correct Port Is Open. Press Any Key To Continue\n";
'A'); c << "Port Timeouts Set.\n"; cout << "\n";
cout << cout << "\n"; cout << "Byte Size Set To 8.\n"; cout << "\n"; cout << "One Stop Bit.\n"; cout << "\n"; cout << "Parity Bit Set To None.\ cout << "\n"; cout << "Port Opened Succes _getch(); main_menu(); } } char byte_receive_traffic_ligh{ char byte;
wBytesRea DWORD df i (!ReadFile(TrafficSerial, &byte, 1, &dwBytesRead, NULL))
{ cout << "Unable To Recieve Data. Check If Correct Port Is
); _getch( CloseHandle(TrafficSerial); main_menu(); } return byte; } char byte_receive_airborne() { char byte;
WORD D dwBytesRead; if(! a (AirBorneSerial, &byte, 1, &dwBytesRead, NULL)) {
cout <<
87
_getch(); CloseHandle(AirBorneSerial); main_menu(); } return byte; } void yte_s b end(unsigned char byte) { DWORD dwBytesWritten;
ial, &byte, 1, &dw if(!WriteFile(AirBorneSer BytesWritten, NULL))
s Any Key To Continue\n";
neSerial); ain_menu();
}
#include "RoadSideUnit.h"
{ To Send Data. Check If Correct Port Is Open. Pres cout << "Unable
_getch(); loseHandle(AirBor C
m } void exit() { cout << "Exiting Program.....";
500); Sleep(2 CloseHandle(TrafficSerial);
erial); CloseHandle(AirBorneS exit(1); } RoadSideUnit.cpp
main(void) void
{ main_menu(); }
88
test.cpp #include "RoadSideUnit.h" void test() { for(;;)
float* calcdata = data();
<< calcdata[1]; cout
];
cout << calcdata[4]; cout << " ";
cout << calcdata[5]; cout << " ";
2 OBE Code
{
cout << calcdata[0]; cout << " "; cout
<< " "; calcdata[2]; cout <<
cout << " "; cout << calcdata[3
out << " "; c
cout << calcdata[6]; cout <<"\n"; } } 8. tdafx.h s
#pragma once #ifndef _stdafx_H efine _stdafx_H #d
89
#includ#includ
e <iostream> e <fstream>
#include <string>
ndows.h> <conio.h>
>
id byte_send(unsigned char byte); (); char *port);
void set_serial_timeouts(); rscr();
oid main_menu(); ();
#include <stdlib.h> #include <cstdlib> #include <wi#include #include <ctype.h>
cess.h#include <pro#include <sstream> #include <stdio.h> using namespace std; void test1(); void test2(); void test3(); void test4(); void test5(); void Tester(char a, int position); void char GPS( a, int position); void print(); //void time(char a, int position); //void counter(char a, int position);
); void sort(char a, int position(); void separate
id format(); voovvoid set_serial_portvoid open_serial_port(
void clvvoid com_menuhar byte_receive(); c #endif
90
GPS.cpp #include "stdafx.h" void main() {
te //delete all xt files if they exist to prevent use of old data in these files ead.txt"); txt"); txt");
tion[2] = {0, 0};
input may be slower than VC++ read speed al times to guarantee the file has stopped updating if you possess a faster computer. DO NOT comment it out
ck
e==0)
pens the GPS file tream myfile("GPS_Read.txt");
//gets and saves the last position of the cursor in the file myfile.seekg(-1L,ios::end);
remove("GPS_R remove("output.
r. remove("teste //DOS OBU Menu
main_menu(); } GPS_Read.cpp #include "stdafx.h" void test4() { int loop = 0, e = 0, tellg, posi char a; //GPS data //Thus the program loops sever //Increase the number of loops //hereafter called update che while(loop<1000) { while( { //o ifs
91
tellg = myfile.tellg();
//checks if last position in file == current position (tellg==position[0])
e=1;
file.eof())
//set cursor to position[0] from start of file myfile.seekg(position[0], ios::beg);
//get character at position[0] myfile.get(a);
//if not performed update check and last position not reached if(loop == 0 && position[1] != tellg) Tester(a, position[0]);
//since the if was entered, update has occurred. thus, set loop back to 0
//once last position is reached, and we continue trying to read after it Which is useless to us because it does not tell
us exactly r is at. To
//update position[1] with old position position[1] = position[0];
ion[0] with new position after reading a ();
if //if file open and position is not == last position; enter if(myfile.is_open() && e==0) { while(!my {
loop = 0;
//VC++ assigns position -1.
//how many positions from start of the text file the read cursosolve this:
//update posit position[0] = myfile.tellg
} }
data before closing it //to clear the buffer of old read
92
//we keep opening and closing
the text file to check for updates //as the GPS keeps updating GPS_Read.txt but when we open it, we see data from one moment
appended data
position right after last
std fx.cp : so rce f le th
#include "st afx.h
Tester.cpp
tdir spee [7];
tude;
//to get new data, we close and open again and we see myfile.clear(); myfile.close(); //endline is read as a character. so we decrement cursor to character
n[0] = position[1]-1; positio }
w update check //set e to 0 for ne=0; e
//increment number of update checks done
loop=loop+1; } / outfile.close(); / } stdafx.cpp // a p u i at includes just the standard includes
er // GPS_Read.pch will be the pre-compiled head// stdafx.obj will contain the pre-compiled type information
d "
#include "stdafx.h" static char rest[70], start[6], time[6], con, longdeg[2], longrest[7], longdir, latdeg[3], latrest[7], la , d
count=0, flag=0, enter,timecheck[6], pflag=0; static intstatic double longd, longr, latd, latr, velocity, longitude, latiHANDLE cSerial; DCB dccSerial;
93
o a ffstre m out ile; fstre m tes er;
RSU via the Airborne Direct
int
fun ion t e Airborne Direct
"%2.6f", flatitude); //converts latitude from float to an array of characters for(int i = 0; i < 9; i++) //transfers the elements of the array one at a time
byte_send(latitude[i]);
funtion to transmit the longitude to the RSU via the Airborne Direct ude(float flongitude, char hemisphere)
r longitude[10]; sprintf_s(longitude, "%2.6f", flongitude); //converts longitude from float to an array of
i = 0; i < 9; i++)
o a t // funtion to transmit the time to the oid transmit_time(char *time) v { for( i = 0; i < 8; i++) //transfers the elements of the array one at a time {
nd(time[i]); byte_se } } // t o transmit the latitude to the RSU via th
latitude, char hemisphere) void transmit_latitude(float f{ char latitude[10];
sprintf_s(latitude, { } byte_send(hemisphere); //transfers hemisphere } //void transmit_longit{ cha characters
for(int { byte_send(longitude[i]); //transfers the elements of the array one at a time } byte_send(hemisphere); //transfers hemisphere }
94
// funtion to transmit the speed to the RSU via the Airborne Direct d(float fspeed)
FO csbi;
Out
cout << "Exiting Program.....";
, ios::app); "
enter = 0;
void transmit_spee{
char speed[10]; sprintf_s(speed, "%2.6f", fspeed);
) for(int i = 0; i < 9; i++{
byte_send(speed[i]); //transfers the elements of the array one at a time } } id clrscr() vo
{ HANDLE hStdOut = GetStdHandle(STD_OUTPUT_HANDLE); COORD coord = {0, 0};
DWORD count; CONSOLE_SCREEN_BUFFER_IN GetConsoleScreenBufferInfo(hStdOut, &csbi);
t); FillConsoleOutputCharacter(hStdOut, ' ', csbi.dwSize.X * csbi.dwSize.Y, coord, &couneCursorPosition(hStd , coord); SetConsol
} t exits the program //funtion tha
oid ev xit() { Sleep(2500); //closes all open handles to avoid any errors
CloseHandle(cSerial); exit(1); } oid Tv ester(char a, int position) { //open testing/debugging files
.open("output.txt" outfile tester.open("tester.txt , ios::app);
95
now relevant data is to be parsed //if $GPRMC already read and
if(flag == 6 && enter == 0) { //$ indicates new line so $GPRMC line finished reading
//extract longitude, latitude, connection, speed, time data from rest[] separate();
grees. convert speed to m/s
t and tester.txt and main_menu() DOS screen
after $GPRMC in an array called rest[] position);
}
//close testing/debugging files
accessed until $GPRMC read
if(a == '$') {
flag = 0; count = 0;
//convert longitude and latitude to de format(); //output data to output.tx print(); } else
{ //save all data
sort(a,
} //enter until $GPRMC line found if(flag < 6 && enter == 0)
osition); GPS(a, p outfile.close();
tester.close(); } void GPS(char a, int position) { //function
96
outfile<<"Entered GPS()\n";
n"; outfile<<"flag = "<<flag<<"\<<"position = "<<position<< outfile
outfile<<a<<"\n";
flag =
flag =
lag == 2)
4)
flag = 5;
"\n"; enter = 1; if(a == '$')
{ 1;
start[0] = a; }
if(a == 'G' && flag == 1)
{ 2;
start[1] = a; }
& f if(a == 'P' & { flag = 3;
] = a; start[2 } if(a == 'R' && flag == 3) { flag = 4;
start[3] = a; }
= if(a == 'M' && flag ={
start[4] = a;
}
97
if(a == 'C' && flag == 5)
GPRMC
+) ;
separating and formatting have all been done (flag == 0)
s read twice by GPS_Read.txt time is same as last time read by program, then don't transmit/print
++) (timecheck[r] == time[r])
pflag = pflag+1;
n(8); tester.precision(8);
"<<con<<" "<<latitude<<" "<<longitude<<" "<<velocity<<"\n"; " "<<con<<" "<<latitude<<" "<<longitude<<" "<<velocity<<"\n";
flag = 0;
{ flag = 6; start[5] = a;
print(); } } void print() { //empties array holding $
== 6) if(flag{
for(int r=0; r<6; r+start[r] = ' '
}
only if sorting, //printif
{ /sometimes a line i /
//this check if for(int r=0; r<6; r
if
/if new data /
if(pflag != 6) {
cout.precisio
cout<<time<<" tester<<time<<
}
/clear all arrays / p
98
for(int r=0; r<6; r+timecheck[r]
+) = time[r];
= ' ';
for(int r=0; r<7; r++) {
longrest[r] = ' '; latrest[r] = ' ';
for(int r=0; r<3; r++)
r=0; r<70; r++)
con
utfil <<"po
for(int r=0; r<6; r++) time[r]
speed[r] = ' '; } for(int r=0; r<2; r++) longdeg[r] = ' '; latdeg[r] = ' ';
or(int f rest[r] = ' ';
= ' '; longdir = ' '; latdir = ' ';
} }
nt position) void sort(char a, i{ outfile<<"Entered sort()\n";
utfil <<"fl o e ag = "<<flag<<"\n"; o e sition = "<<position<<"\n";
\n"; outfile<<a<<"
enter = 1;
99
rest[count] = a; count = count + 1; } vo id separate()
een read
ces of info in GPS data: latitude,longitude...
[j] = rest[i]; j=j+1; eak;
//extract data whether GPS is connected to satellite. 'V': not connected. 'A': onnec ed
e 1: {
con = rest[i]; break;
}//extract longitude data
& f == 0)
longdeg[j] = rest[i]; } else
{ enter = 1;
elect=-1, j=0, f=0; int i = 0, s
array has not b //while whole while(i<70) {
ie //',' separates different pest[i] != ',') while(r
{ switch(select)
{ //extract time data
case 0: {
time br
} c t
s ca
case 4: { if(j < 3 &
{
100
{ if(j == 3 && f == 0) j = 0;
f = 1; longrest[j] = rest[i];
}
1;
}
ngdir = rest[i]; break;
[j] = rest[i];
{if(j == 2 && f == 0)
1;rest[i];
j = j +
break;
//extract E/W case 5:
{ lo
}
itude data //extract lat case 2: {
f == 0) if(j < 2 && {
latdeg } else j = 0;
f = latrest[j] =
} j = j + 1; break; } //extract N/S case 3:
101
{ latdir = rest[i]; break; } //extract speed data case 7: {
j speed[ ] = rest[i];
hown as a comma by GPS data
j = j + 1; break; } } i = i + 1; } select = select + 1; j = 0; f = 0; //condition for when speed = 0 which is s if(select == 6) { if(rest[i+1] == ',') { for(int j=0; j<7; j++) { speed[j] = '0'; } }
select = 7; } i = i + 1; } } void format() {
to degrees //change longitude and latitude longd = atof(longdeg); longr = atof(longrest);
102
longr = longr/60; longitude = longd + longr; latd = atof(latdeg); latr = atof(latrest); latr = latr/60; latitude = latd + latr; //change speed to m/s velocity = atof(speed);
4; velocity = velocity/0.5144456337777777 velocity = velocity*0.27 8;
SU
city);
ta via the serial port char byte)
BytesWritten; (!WriteFile(cSerial, &byte, 1, &dwBytesWritten, NULL)) //data in the byte variable is sent to the
data to R //to transmit
byte_send('('); byte_send(con); byte_send(')'); byte_send('$'); transmit_time(time);
); byte_send('*' byte_send('@');
atitude, latdir); transmit_latitude(l byte_send('#'); byte_send('!'); transmit_longitude(longitude, longdir); byte_send('%'); byte_send('^');
o transmit_speed(vel byte_send('&'); } /funt on th/ i at sends da
d(unsigned void byte_sen{ DWORD dw
if serial ports one byte at a time {
103
cout << "Unable To Send Data. Check If Correct Port Is Open. Press Any Key To Continue\n";le sending data program is routed back to the main menu
//wait for user input rial);
ar b
eive Data. Check if correct port is open. Press any key to continue\a";
rial);
ial, &dccSerialParams))
. Please Check Serial Port Connections And Try Again. Press any key to
CBR_2400; //sets baud rate to 2400
OPARITY; //sets parity to none (!SetCommState(cSerial, &dccSerialParams)) //assigns parameters to the serial port
//in the event of error whi _getch();
CloseHandle(cSe main_menu(); } } hc yte_receive() { char byte; DWORD dwBytesRead;
if(!ReadFile(cSerial, &byte, 1, &dwBytesRead, NULL)) {
o Rec cout<<"Unable t _getch(); CloseHandle(cSe main_menu(); } return byte; } // function that sets serial port parameters void set_serial_port() { DCB dccSerialParams = {0};
sizeof(dccSerialParams); dccSerial.DCBlength = if(!GetCommState(cSer {
cted Error cout << "Unexpentinue.\n"; co
_getch(); //waits for user input com_menu();
} dccSerialParams.BaudRate = dccSerialParams.ByteSize = 8; //sets byte size to 8 dccSerialParams.StopBits = ONESTOPBIT; //sets stop bit to one
alParams.Parity = N dccSeri if
104
{ cout << "Error Setting Port Paramaters. Please Check Serial Port Connections And Try Again.
ial_timeouts(); cout << "Port Timeouts Set.\n";
"Baud Rate Set To 2400.\n";
o 8.\n";
. Press Any Key To Continue\n";
desired serial port id o
VA
(GetLastError() == ERROR_FILE_NOT_FOUND) //in the event a time out occurs a program
Press any key to continue.\n"; r input _getch(); //waits for use
com_menu(); }
set_ser cout << "\n";
cout << cout << "\n"; cout << "Byte Size Set T cout << "\n";
"One Stop Bit.\n"; cout << cout << "\n";
et To None.\n"; cout << "Parity Bit S cout << "\n";
cessfully cout << "Port Opened Suc); //waits for user input _getch(
main_menu(); } funtion that opens a //ov pen_serial_port(char *port) { CloseHandle(cSerial);
port = port; char *z cSerial = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
f(cSe i rial == IN LID_HANDLE_VALUE) {
f irouts back to the com menu { CloseHandle(cSerial); cout << "\n"; cout << "\n";
105
cout << "Serial Port Does Not Exist. Press Any Key To Continue\n";
"Unexpected Error. Press Any Key To Continue\n"; r user input
"Please Wait While Port Parameters Are Set.....\n"; cout << "\n"; Sleep(1400);
n to set serial port parameters
ts for a serial port oid s
meoutConstant = 50; 10; ) //in the event a time out occurs a program routs back to
_getch(); //waits for user input com_menu(); } cout << "\n";
out << c _getch(); //waits fo com_menu(); } clrscr(); cout << "\n"; cout << "\n";
ng Serial Port "; cout << "Openi cout << zport[4];
5]; cout << zport[ cout << zport[6];
7]; cout << zport[ cout << zport[8]; cout << "........\n"; cout << "\n";
cout << set_serial_port(); //calls funtio } / fun time ou/ ction that sets the v et_serial_timeouts() { COMMTIMEOUTS timeouts = {0};
s.ReadIntervalTimeout = 50; timeout timeouts.ReadTotalTimeoutConstant = 50; timeouts.ReadTotalTimeoutMultiplier = 10;
eTotalTi timeouts.Writ timeouts.WriteTotalTimeoutMultiplier =
imeouts) if(!SetCommTimeouts(cSerial, &tthe main menu
106
{ heck Serial Port Connections cout << "Error Setting Port Timeouts. Please C And Try Again. Press
//waits for user input
lears screen System Interface Setup for On Board Unit (OBU)\n";
Main Menu\n";
en/Configure Airborne Direct Serial Port\n";
Transmitter\n";
ection 1 - 3: \n";
//checks for correct input {
&& ch != '3'); cts the program to the correct function depending on user input
n to set the Airborn Direct Wireless serial port settings
Any Key To Continue.\n"; ); _getch(
main_menu(); } } void main_menu() { clrscr(); //c
cout << " cout << "\n"; cout << "\n"; cout << "\n"; cout << " cout << "\n"; cout << " 1. Op cout << "\n"; cout << " 2. Start cout << "\n"; cout << " 3. Exit\n"; cout << "\n"; cout << "Enter Sel cout << "\n";
; int chdo
ch = _getch();
); ch = toupper(ch}
while(ch != '1' && ch != '2' switch(ch) //switch statement dire { case '1' :
o com_menu(); //calls the funti break; case '2' : clrscr();
107
cout << "Time (GMT) Latitude Longitude Speed\n";
rt menu
clears screen Global Positioning System Interface Setup\n";
u\n";
. COM6\n";
"Select Serial Port To Open 1 - 9 Or X To Exit To Main Menu:";
'2' && ch != '3' && ch != '4' && ch != '5' && ch != '6' && ch != '7' && '9' && ch != 'S' && ch != 's' && ch != 'X' && ch != 'x');
test4(); //calls the function to start the GPS Data acquision, parser and transmitter break;
case '3' ://exits the program exit();
break; }
} // function that displays the serial pooid cv om_menu() { clrscr(); // cout << " cout << "\n"; cout << "\n"; cout << "\n";
Serial Port Selection Men cout << " cout << "\n";
. COM1\n"; cout << " 1 cout << " 2. COM2\n";
. COM3\n"; cout << " 3 cout << " 4. COM4\n";
. COM5\n"; cout << " 56 cout << "
< cout < " 7. COM7\n"; " 8. COM8\n"; cout <<
cout << " 9. COM9\n"; cout << "\n";
cout << int ch; do //checks for correct input { ch = _getch(); ch = toupper(ch); }
!= while(ch != '1' && ch ch != '8' && ch !=
108
i || ch == 'x') //exits to the main menu f(ch == 'X' main_menu();
"//./COM2"); (ch == '3')
open_serial_port("//./COM3");
(ch == '5') );
'7') ial_port("//./COM7");
/./COM9"); }
//assigns a serial port to the Airborne Direct and calls funtion to open the desired serial port else if(ch == '1') open_serial_port("//./COM1"); else if(ch == '2')
pen_serial_port( oelse if
else if(ch == '4')
_serial_port("//./COM4"); openelse if
open_serial_port("//./COM5" else if(ch == '6')
ial_port("//./COM6"); open_ser else if(ch == open_ser else if(ch == '8')
ial_port("//./COM8"); open_ser else if(ch == '9') open_serial_port("/
109