A Method for Detecting and Alerting

the Presence of a Reverse Running Vehicle

Tsukasa Kato1(&) and Hiroaki Nishino2

1
Graduate School of Engineering, Oita University, Oita, Japan
v18e3006@oita-u.ac.jp
2
Faculty of Science and Technology, Oita University, Oita, Japan
hn@oita-u.ac.jp

Abstract. Many researches have recently been paying attention to designing

safe driving support systems based on V2X (vehicle to X) technologies. A ve-
hicle can share various information with other vehicles through wireless con-
nections. These days increasing number of accidents caused by reverse running
cars become a serious problem. While the accidents occur on both expressways
and general roads, some preventing mechanisms against the problem are pro-
gressing in expressways. In the case of general road, however, drivers who are
on the one-way road have no way to recognize the existence of any reverse
running cars until they can visually confirm the existence. If they don’t assume
the existence, the possibility of accident become high when a reverse running
car actually exists. In this paper, we propose a method to solve the problem. It
automatically detects a road type (one-way road or not) by analyzing current
location, checking the existence of a reverse running car by wirelessly com-
municating with surrounding cars if the road is one-way, and alerting the driver
of the results with text and sound. We design and prototype a system and verify
the effectiveness of the proposed method through experiments.

1 Introduction

Recent advances of connected car research field such as V2X (vehicle to X) com-
munication technologies stimulate many research and development activities for traffic
safety monitoring and accident prevention. Increasing number of traffic accidents
caused by reverse running cars have been identified as serious problems. Because the
reverse running cases have higher risk of fatal and injury accidents than in forward
running cases, we must take some measures to prevent the accidents. About 200
reverse running cars have been observed on expressways every year and this number
increases on general roads. There is a trial to alert drivers of the reverse running cars by
installing umbonal objects for giving a light impact only to the reverse running cars on
a highway. It also warns the forward running car drivers by displaying the existence of
the reverse running car ahead before they encounter on an electronic message board.
Therefore, the forward running car drivers can avoid a possible accident on the
highway because they respond in a calm manner when actually encounter the reverse
running car.

© Springer Nature Switzerland AG 2020

L. Barolli et al. (Eds.): INCoS 2019, AISC 1035, pp. 46–56, 2020.
https://doi.org/10.1007/978-3-030-29035-1_5
 A Method for Detecting and Alerting the Presence of a Reverse Running Vehicle 47

On the other hand, most general roads have no electronic message board like
highways, the drivers have no means to know the existence of the reverse running car
beforehand. They should take actions to avoid the accident after they visually recognize
the. To make matters worse, actively alerting the reverse running car drivers is difficult
because traffic sign is an only way to notify the drivers on general roads. Uncareful
drivers may easily miss the one-way road sign and some obstacles may hide the sign.
Elderly drivers tend to drive the wrong way on expressways, but in the case of one-way
roads, any drivers who are not familiar with the area may drive the wrong way for the
above reasons regardless of their age. Since most drivers don’t assume the existence of
the reverse running car on a one-way road, they cannot cope with it when they sud-
denly find it. Such situation may lead to a serious accident.
In this paper, we propose a system for automatically detects a road type (one-way
road or not) by analyzing current location, checking the existence of a reverse running
car by wirelessly communicating with surrounding cars if the road is one-way, and
alerting both of the reverse and forward running car drivers via text message and sound.
We prototype a system and verify it through experiments.

2 Related Work

There are many research projects for supporting safety driving based on vehicle-to-
vehicle (V2V) communication. Peng et al. proposed a method for acquiring relative
trajectories of peripheral cars to detect their traveling lanes using and DSRC (dedicated
short range communication) based V2V communication [1]. While obtaining the
accurate position of a surrounding car needs multiple expensive sensors and a complex
control system, they proposed a low-cost solution by exchanging normal GPS data with
an error of several meters between vehicles traveling on a multi-lane freeway. It detects
relative positions of surrounding vehicles that are accurate enough for use with merge
and lane-change assist functions. They verified the effectiveness of the proposed
method via experiments.
Elleuch et al. proposed an intersection collision avoidance system based on V2V
communication and a real-time database [2]. They pay attention to the higher proba-
bility of accidents at intersections where traffic volume is high, they designed a method
to avoid the accidents by cooperatively exchanging some information between
neighboring vehicles. In the proposed method, a car approaching to an intersection
periodically transmits its position, speed, and traveling direction to surrounding cars via
DSRC based broadcast communication. The neighboring cars store the received data in
their local real-time database and analyzes if any collision is anticipated in the inter-
section. It decides the priority of crossing the intersection between vehicles where a
possible collision is expected. Then, it makes the lower priority vehicle and its fol-
lowing cars to automatically decelerate or stop to avoid the accident.
These days an increase in collisions caused by reverse driving of elderly drivers
became a social problem. Hirano et al. studied the effect of visual attention to make
48 T. Kato and H. Nishino

elderly drivers aware of dangerous events during driving [3]. They particularly focus
on a fact that elderly drivers tend to lose their cognitive ability and take longer time to
response when multiple hazardous events occur. They set up a driving simulator for
generating three hazardous events simultaneously such as deceleration of preceding
car, wobbling of nearby bicycle, and approaching of oncoming car, and ask both
elderly and young drivers to drive with or without visual warning of these events. They
reported the elderly drivers’ recognition rate of the events became higher with the
visual warning and their reaction time were shortened though they did not reach the
young driver’ improvements.
The increase in bicycle accidents including serious injury and death is another
social problem. This is due to the fact that many bicycles tend to travel in reverse
direction on the roadway though the bicycles should run on the left side of the road.
Yamanaka et al. analyzed the effect of a reverse running warning device placed on a
bicycle lane [4]. They made a device for detecting reverse running bicycles and lighting
up a warning message on an LED display board. They conducted an experiment to use
the device on a real road and compared the case to place a person for watching and
raising a warning panel. Although the effectiveness of the human panel warning was
higher, a certain amount of effect was confirmed in reducing the number of reverse
running bicycles.
In this paper, we propose a method for automatically detecting a road type (one-
way or not) and searching any reverse running vehicle by exchanging information with
other neighboring cars if own car is traveling on a one-way general road.

3 System Implementation

3.1 System Organization

Figures 1 and 2 show the proposed system organization and its appearance, respec-
tively. As shown in Fig. 2, the system consists of an Android tablet as a main controller
node, a Raspberry Pi board as a communication controller node, and a Wi-Fi SUN
communication module.
To start the system, a user firstly connects the Raspberry Pi board with the Android
tablet via a Bluetooth connection and start the main controller program implemented as
an Android application on the tablet. Next, the user starts driving the car after pressing
the system start button as shown in Fig. 3. Then, the main controller acquires its current
position using a GPS function every five to ten seconds indicated as item 1 in Fig. 1.
After that, it detects if the vehicle travels on a one-way road or not by inquiring to the
Google Maps Roads API [5] with the acquired position data. If it is on the one-way
road, the main controller also derives its traveling direction by calculating the differ-
ence between previous and current position coordinate values, and notifies the road
type (one-way) and the traveling direction to Raspberry Pi (communication controller)
indicated as item 2 in Fig. 1.
 A Method for Detecting and Alerting the Presence of a Reverse Running Vehicle 49

The communication controller tries to send the direction data to neighboring cars
and acquires their counterpart information via Wi-Sun connections [6] indicated as
items 3, 4, 5, and 6 in Fig. 1. If the direction received from a neighboring car is
opposite to the own vehicle, it notifies the result to the main controller indicated as item
7 in Fig. 1. Finally, the main controller outputs a warning text message with a sound as
shown in Fig. 4. It makes the driver aware of the possible danger due to the existence
of the reverse running car on the traveling road. The system iterates these processes
without driver’s intervention and allows the driver to concentrate on driving. The driver
can prepare for the time to meet with the reverse car and quickly takes actions to avoid
an accident when he/she visually recognizes the approaching car.

Fig. 1. Organization of the proposed system.

Fig. 2. Appearance of the proposed system

50 T. Kato and H. Nishino

Fig. 3. Main controller operation panel. Fig. 4. Warning message panel.

3.2 Road Type Detection

When the system recognizes that the own vehicle is traveling on a one-way road, it
repeats the series of processes described in the previous subsection. Therefore, the
system firstly needs to automatically detect whether the current road type is one-way or
not. We utilize the Google Maps Roads API for detecting the road type [5]. The system
inquires the road type to the Google Maps Roads API by rewriting the URL format as
shown in Fig. 5. The system sets the current location in the “parameters” part as a pair
of latitude and longitude acquired by the Android tablet of and the Google Map API
key obtained in advance in the “YOUR _ API _ KEY” part. This function replies the
road information in the vicinity of the inquired location. The system gets an answer
among the following three responses: no road, a one-way road, and a two-way road.

https://roads.googleapis.com/v1/nearestRoads?parameters&key=YOUR_API_KEY

Fig. 5. URL query format to the Google Maps Roads API.

The number of location coordinate values included in the response differs

depending on the road type (one-way or two-way). If the road near the location is a
two-way road, the system receives a pair of input coordinate values (two portions
enclosed by red squares) as shown in Fig. 6. In the case of one-way road, the system
receives only one coordinate value set as shown in Fig. 7. If there is no road near the
location, the answer is an empty content only with curly brackets ({}). When the main
controller running on the Android tablet obtains its location information every five to
ten seconds, it sends a query with the location values and analyzes its response to find
the road type. If the response indicates the road type is one-way, then the system
 A Method for Detecting and Alerting the Presence of a Reverse Running Vehicle 51

proceeds to the following processes to check the existence of approaching cars. If the
road type is two-way, the controller iterates the acquisition of current location and the
inquiry of road type.

Fig. 6. An example response in the case of two-way road.

Fig. 7. An example response in the case of one-way road.

3.3 Calculation of Traveling Direction

After the system detects the current traveling road type as one-way, it proceeds to the
step for checking whether any approaching vehicles exist or not. If such a car is found
nearby, that car or own may be traveling in reverse direction and the possibility of an
accident is increased. Then, the system tries to inform the driver of the result as
52 T. Kato and H. Nishino

warning against an encountering accident. This process needs to calculate own car’s
traveling direction, exchanging the direction information with other neighboring cars,
and comparing the own traveling direction with others. If the other car’s direction is
opposite to the own car, the system immediately issues the warning to the driver.
While the Google Maps Roads API can determine the road type, it cannot check the
direction of a traveling car. We, therefore, implement a method for calculating the own
car’s direction when it is traveling a one-way road. As shown in Fig. 8, the system
calculates the azimuth angle from a pair of position coordinates (latitude and longitude)
at two locations ti and ti þ Dt when the positive direction of the vertical axis is oriented
toward east. It records the current position coordinates in every step, calculating the
azimuth angle h between the current and past positions recorded at the previous pro-
cessing step, and using it as the current traveling direction. The system sends its current
direction to a neighboring vehicle via a Wi-SUN connection, and simultaneously
receives the other car’s direction calculated in the same way manner. Then, it compares
its own direction with other car’s to see if the difference in direction is greater than a
predefined threshold value. If the condition is true, the system decide the two cars are
moving in opposition directions to each other and finally presents the warning message
on a tablet display with an alert sound.

Fig. 8. Azimuth calculation from vehicle locations.

3.4 Inter-vehicle Communication Based on Wi-SUN

The system uses a wireless communication function called Wi-SUN (Wireless-Smart
Utility Network) for sharing information with neighboring vehicles. Wi-SUN was
originally developed by NICT (National Institute of Information and Communications
Technology), Japan, and now is standardized as IEEE 802.15.4g [6]. We adopt the
ROHM BP35A1, a Wi-SUN communication module conforming to the standard, as
shown in Fig. 9 [7]. Since the module is equipped with an antenna necessary for
sending and receiving data and operates for a long time with low power consumption,
incorporating the module into the system is easy. It is directly connected to the
Raspberry Pi board, the communication controller, via a connector.
 A Method for Detecting and Alerting the Presence of a Reverse Running Vehicle 53

Wi-SUN uses 920 MHz communication band which can use freely without license
in Japan and have some advantages over 2.4 GHz Wi-Fi communication facility as
described in Table 1. Although the communication speed is inferior to Wi-Fi, the
communication range to cover is up to 1 km and its diffraction performance is high.
Since the system is installed in a moving car to perform data communication, Wi-SUN
is considered to be an appropriate solution due to its wide communication range and
high reachability of radio waves (diffraction performance). Its low power consumption
performance is also a useful feature as an on-vehicle device.

Fig. 9. Wi-SUN communication module ROHM BP35A1.

Table 1. Wi-SUN characteristics over 2.4 GHz Wi-Fi communication band.

Wi-SUN Wi-Fi
(920 MHz band) (2.4 GHz band)
Communication speed Up to 200 kbps 10 Mbps and more
Radio interference Few Many
Power consumption Low High
Communication distance Up to 1 km Several hundred meters
Diffraction performance Good Bad

3.5 Data Transmission Protocol

Wi-SUN basically defines the lowest two layers (physical and data link layers) in the
protocol stack and we can choose upper layer protocols. We select TCP/IP for data
transmission protocol. If any packet loss occurs in the data exchange between vehicles
facing each other, the system may not able to detect the possible accident caused by the
reverse running car. As a result, the reliability of data transmission becomes a first
priority for data communication.
The system firstly needs to establish a connection to a nearby vehicle using Wi-SUN
to start communication. One car sets a dedicated channel for the communication with its
IP address and PAN (personal area network) ID as a master and the other car tries to
discover any available communication channel nearby by scanning with the same
Pairing ID as a slave. Next, the master only responds to a slave who scans the channel
54 T. Kato and H. Nishino

with the same Pairing ID and the slave acquires the channel bandwidth, PAN ID and the
master’s MAC address to set up the connection in the master’s response. Then, the slave
converts the MAC address to the master’s local IP address and tries to set up the TCP
connection through three-way handshake procedure. After that, the master and slave
nodes can exchange their traveling directions for analyzing the possibility of accident
caused by running cars on a one-way road as described in Sect. 3.4.
The V2V communication we implemented by using Wi-SUN is basically one-to-
one communication between a pair of master and the slave as described above. On a
congested one-way road, however, many vehicles need to efficiently exchange trav-
eling information. We added a function to prevent from reconnecting with a vehicle
previously talked with and exchanged information, and search for another channel set
by a different vehicle never talked with. Additionally, efficiently exchanging and
sharing the information among many vehicles is difficult if the master and slave
relationship is fixed. We, therefore, implement a function to make the slave vehicle
once received the traveling information of a nearby car change its role as a master for
providing the received information to other vehicles.

4 Preliminary Experiment and Improvement

4.1 Preliminary Experiment

We conducted a preliminary experiment indoors to verify the usefulness of the system.
We employed six university students. Each experimental task requires a pair of
subjects. We asked each subject to carry the system with an Android tablet, Raspberry
Pi board, and Wi-SUN module as a set, and asked to go straight on a corridor assuming
a one-way road. We asked them to start walking from both ends in the L-shaped
corridor without knowing each other’s presence and verified whether the system could
warn and avoid the risky condition before they collided.
We also asked them to perform three trials with different warning output in each
task for comparing three different alerts: an image only, a sound only, and both image
and sound alerts. After they finished the task, we asked them to answer a questionnaire
consisting of the following two questions: “is the system useful as a mean for recog-
nizing the partner before meeting?” in five ranks (5 is “useful” and 1 is “not useful”),
and “which warning message is the most effective as an alert?” (select one among the
three alerts). Tables 2 and 3 show the results of the usefulness and the best warning
message questions, respectively.
Although the number of subjects was not sufficient, everyone highly evaluated the
usefulness of the system function. Additionally, five among six subjects supported the
alert with image and sound was the best way to notify the possible risk. Multiple
subjects mentioned some positive comments like “I was able to proceed with caution
due to a prior warning”, and “simultaneous visual and auditory stimuli were effective in
accurately delivering important information.” On the other hand, other subject stated a
negative comment like “The warning sound was offensive and annoying.” This may
due to a sharp sound we used to present in an alert for reliably conveying the imminent
danger to the driver. We should reconsider to improve the sound alert.
 A Method for Detecting and Alerting the Presence of a Reverse Running Vehicle 55

Table 2. Results on the usefulness question.

Subject A B C D E F Average
Value 5 4 5 4 4 5 4.5

Table 3. Results on the best alert method question.

Alert method Image only Sound only Image and sound
Number of supporters 0 1 5

4.2 Discussion
As for the warning sound, since the current system repeatedly presents the same sharp
sound, the subject who claimed his discomfort might feel the iterated noisy sound
unpleasant. Additionally, other subject stated that the sound only alert didn’t tell him
what was going on in the experimental task. We, therefore, changed the sound to a
synthesized human voice indicating the existence of approaching vehicle ahead. We
asked subjects to hear the voice and confirmed that they felt it was more natural and
less offensive as an alert message. As a result, the driver may be able to grasp the
situation only by the voice alert.
Regarding the V2V communication performance, the TCP/IP connection may be
too heavy to especially support congested situation. Therefore, we should verify UDP
as an alternative protocol to see if it can satisfy with the performance without degrading
the reliability requirement.

5 Conclusions and Future Work

In this paper, we proposed a driving safety support system for detecting the existence of
reverse running vehicle if he/she is traveling on a one-way road and alert the possible
danger by image and sound. It automatically detects the current road type (one-way or
not) using the current location and calculates its traveling direction if it is on a one-way
road. Then, it exchanges the direction information with other neighboring cars via a
Wi-SUN wireless connection and analyzes if any approaching vehicle exists or not. It
finally presents the warning message with an image on a tablet screen and a sound
output to make the driver pay attention to the situation.
We prototyped the system based on the proposed method and verified the useful-
ness of the system function through an experiment. Although it was a quasi-experiment
asking two persons walking in reverse directions for each other by carrying the system
indoors, but we confirmed that the proposed reverse moving object detection and
warning functions work effectively.
We designed and implemented the reverse running vehicle detection function as our
own method and it cannot detect who is the real reverse running car. We would like to
further improve the function to accurately identify the reverse running vehicle and alert
56 T. Kato and H. Nishino

neighboring cars to prepare the possible danger as a future work. Conducting outside
experiments using real cars is another important issue to verify the practicality of the
system as a driving safety support system.

References
1. Peng, Z., Hussain, S., Hayee, M.I., Donath, M.: Acquisition of relative trajectories of
surrounding vehicles using GPS and DSRC based V2V communication with lane level
resolution. In: Proceedings of the 3rd International Conference on Vehicle Technology and
Intelligent Transport Systems, vol. 1, pp. 242–251 (2017)
2. Elleuch, I., Makni, A., Bouaziz, R.: Cooperative intersection collision avoidance persistent
system based on V2V communication and real-time databases. In: 2017 IEEE/ACS 14th
International Conference on Computer Systems and Applications, pp. 1082–1089 (2017)
3. Hirano, S., Enomoto, M., Sekine, M., Tanaka, K.: Effects of visual alerts on elderly drivers’
recognition of multiple, simultaneous hazards. Trans. Hum. Interface Soc. 21(1), 111–120
(2019). (in Japanese)
4. Yamanaka, S., Takehira, S., Dohko, T., Ikeda, N.: An analysis of the effect of on-street
warning device for wrong way cycling on bicycle lane. J. Jpn. Soc. Civil Eng. 73(5), 711–715
(2017). (in Japanese)
5. https://developers.google.com/maps/documentation/roads/intro. Accessed June 2019
6. Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., Obata, K., Okumura, R.: IEEE
802.15.4g based Wi-SUN communication systems. IEICE Trans. Commun. E100–B(7),
1032–1043 (2017)
7. http://www.rohm.co.jp/web/japan/products/-/product/BP35A1. Accessed June 2019