Enabling WiFi P2P-Based Pedestrian Safety App

04/20/2018 ∙ by Myounggyu Won, et al. ∙ South Dakota State University DGIST 0

Recent studies reported a significant increase in the number of accidents caused by distracted walking. In this paper, we develop a mobile system that provides a timely warning to the pedestrian and the driver to reduce the chance of pedestrian-involved accidents. The proposed system performs pedestrian risk assessment to estimate the collision probability based on accurate user localization, user-phone-viewing event detection, and WiFi P2P-based vehicle to pedestrian communication. Depending on the resulting collision probability, the pedestrian (and the driver) is alerted to prevent accidents. The proposed system is implemented on a COTS smartphone, and experiments are conducted in a department parking lot. Experimental results demonstrate that it effectively calculates the collision probability and sends accordingly an alert message to the user in a timely manner leveraging its improved positioning accuracy, energy efficiency, and effective user context awareness.



There are no comments yet.


page 9

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The number of accidents concerning distracted pedestrians have increased substantially, especially recently due to the release of Virtual Reality (VR) games such as Pokemon Go [1]. A study has shown that about one third of the pedestrians use mobile phones while crossing streets [2]. In fact, in 2015, 5,376 pedestrians were killed which accounts for an increase of 9.5% compared with pedestrian fatalities in 2014, and it was the highest number of fatalities since 1996 [3]. The statistics indicate that every 1.6 hours a pedestrian was killed, and was injured every 1.6 minutes. There is a pressing need for development of new technology to address this significant societal issue.

Various approaches have been proposed to improve pedestrian safety. Image-based solutions utilize phone cameras and image processing techniques to detect vehicles posing danger to pedestrians [4]. However, these solutions raise the privacy issue and consume too much energy for running image processing algorithms. Dedicated Short Range Communication (DSRC)-based solutions use the 802.11p standard to enable communication of safety information between a car and a pedestrian [5][6]. However, implementing the DSRC protocol on a phone requires significant modifications to the host system, and specialized equipment is required to implement it for a vehicle. Some approaches utilize a backend server via a cellular network to analyze pedestrian safety [7]. Unfortunately, these approaches incur not only increased message delay, but a cost for exchanging data on the cellular network.

Recently, WiFi is being actively adopted to implement a safety app for pedestrians [8][9][10]. We note, however, that an effective pedestrian safety app must meet all of the five conditions: (1) Non-intrusiveness: the app should operate seamlessly on off-the-shelf phones without requiring modifications to the original hardware and protocol stack; (2) Interactivity: both drivers and pedestrians must be alerted of hazardous situations for improved safety; (3) Sustainability: the energy consumption of the app should be minimized for extended operation time; (4) Independence: the app should run independently without relying on external servers and specialized hardware; (5) Timeliness: alert messages should be sent to drivers and pedestrians only when it is needed to minimize driver distraction. Unfortunately, however, we found that existing WiFi-based approaches do not meet one or more of the above conditions.

To this end, this paper proposes the design, implementation, and evaluation of WiSafeCross, a stand-alone pedestrian safety app that accurately assesses the hazardous situations, and provides warning to both drivers and pedestrians in a timely and energy-efficient manner without requiring modifications to the host mobile system. The proposed app utilizes the WiFi Direct technology to allow drivers and pedestrians to exchange safety information, assess the collision probability, and send alert messages to prevent accidents. Although the concept itself is quite simple, a number of technical challenges must be addressed to enable a fully functioning pedestrian safety app. Positioning of drivers and pedestrians is one of the key components of WiSafeCross. Unfortunately, however, in urban areas with a large number of skyscrapers where most pedestrian accidents occur, the accuracy of a phone GPS module is substantially degraded resulting in significant location errors. To address this problem, a map matching algorithm based on a Hidden Markov Model and human walking speed is developed to accurately identify a sidewalk segment that the pedestrian is estimated to be located, which is then used to either eliminate potential location outliers, or perform projection of erroneous locations into appropriate points on the sidewalk segment. To save power consumption of a phone, especially concentrating on the significant energy consumption by the energy-hungry GPS module, a dynamic approach is developed to activate the GPS module adaptively depending on the estimated time that the user is expected to be geographically close to a nearby crosswalk. Another challenge is to ensure that the user is alerted only when he or she is viewing their phone while walking to prevent unnecessary interruption to the pedestrian, and minimize driver distraction. Motivated by the observation that when users view their phones while walking, they tend to try to minimize the shaking of the phone to better read the screen, type a message for texting, or watch videos, an algorithm is developed that accurately detects the user-phone-viewing activity. Consequently, by integrating all the system components designed to address numerous challenges, the collision probability is estimated to assess the pedestrian safety level, and alert messages are sent to the driver and the pedestrian accordingly.

This paper is organized as follows. We start with a preliminary experimental study in Section II to understand the feasibility of WiFi Direct to be used as an underlying technology for our pedestrian safety app. In Section III we describe an overview of the proposed app followed by the details of each system component. The performance of the proposed app is evaluated in Section IV. Section V provides a literature review on related approaches designed for improving pedestrian safety. We then conclude in Section VI.

Ii Feasibility Study

WiSafeCross adopts the WiFi Direct technology to establish a quick peer to peer communication channel between a pedestrian and a driver without involving WiFi routers. In this section, we perform an experimental study to verify that WiFi Direct is a feasible solution to enable ad-hoc phone-to-phone communication in traffic environments. More specifically, we measured packet delivery rates, end-to-end delay, and communication range of WiFi Direct. We used Samsung Galaxy S5 with 1.5GHz octa-core processor, and 3GB RAM running on Android 5.0.

Fig. 1: Packet delivery rates for WiFi Direct.
Fig. 2: Round trip delay for WiFi Direct.

It is crucial to ensure that a packet is reliably received between a pedestrian and a driver. To this end, we measured packet delivery rates for both the driver (sitting in a car) and the pedestrian by varying the distance between them. The packet size was 50 bytes, specifically accounting for the message contents of the proposed app (Section III-E). In each experiment, a total of 500 packets were transmitted. We repeated this experiment for 5 times for each distance between the driver and the pedestrian. Results are displayed in Figure 2. As it can be seen in the figure, packet delivery rates were very high when the driver and pedestrian were close to each other, and it started to decrease as the distance increased. Overall, the results indicate that average packet delivery rates were greater than 80% for distances smaller than 70m. Considering the recent report demonstrating that the communication range above 40m ensures pedestrian safety when the vehicle speed is 60km/h [10], the reliable packet reception rates for the distance of up to 70m or so indicate that WiFi Direct is a feasible technology for the proposed app. A further performance analysis on WiFi Direct regarding the effect of varying vehicle mobility is presented in Section IV-D.

We then measured the round trip delay for packet transmission to show that it is small enough to provide timely warning to the driver and the pedestrian. In this experiment, a packet was sent from the pedestrian to the driver, and the packet was sent back to the pedestrian by the driver. The round trip delay is defined as a period of time between the point when a packet transmission request is made from the pedestrian phone, and the point when the transmitted packet is returned to the pedestrian. The same packet size was used for each experiment. We repeated the experiment for 5 times by varying the distance between the pedestrian and the vehicle. Figure 2 depicts the results. As the figure shows, no significant correlations between the distance and the round trip delay were found because distances of up to 70m would not make a noticeable difference in the propagation delay. Overall, the round trip delay was between 100ms and 200ms. As it will be explained, the proposed app takes into account measured round trip delay in estimating the probability of collision (Section III-E).

Iii System Design

This section presents an overview of the proposed system followed by the details of each system component.

Iii-a System Overview

The mechanism of the proposed system is simple: If a pedestrian is walking while viewing his or her phone, and if the pedestrian is geographically close to a crosswalk, the probability of collision is calculated by exchanging messages with surrounding vehicles using WiFi Direct. Based on this safety assessment, the pedestrian, the driver(s), or both are alerted to avoid collision via warning messages.

Developing this seemingly simple system, however, poses a number of challenges.

  • Alerting the users timely and accurately depends heavily on the positioning accuracy. However, it is not trivial to provide accurate localization with a smartphone especially in urban areas.

  • The GPS module of a phone consumes too much power if it is turned on continuously.

  • Detecting the user-phone-viewing event is not straightforward as existing image processing-based approaches based on face detection are computationally too expensive.

  • Alert messages should be sent in a timely manner based on accurate collision assessment to not send unwanted messages to prevent driving interruption.

  • WiFi Direct does not support n-to-n communication while there may be multiple pedestrians who want to send warning messages to surrounding vehicles.

Fig. 3: System overview: (a) component diagram; (b) flow chart.

The proposed app consists of five modules that are designed to address the afore-mentioned challenges, namely Location, Energy, Context, Alert, and Communication modules (Figure 3(a)).

While the Location module is primarily responsible for providing location information of the user to other modules, it is also used to improve the positioning accuracy especially in urban areas. The Energy module, as shown in Figure 3(a) interacts with the Location module to adaptively control the operation of the GPS module to reduce power consumption. The Context module detects efficiently the user-phone-viewing event to activate the proposed system only when the user is viewing his/her phone while walking. The Alert module is the heart of the proposed system that determines when and to which user (driver or pedestrian) an alert message will be sent based on the collision probability analysis. As the figure shows, the Alert module relies on the Communication module that implements wireless communication between a pedestrian and a driver based on WiFi Direct. The communication module is designed such that n-to-n communication is enabled for WiFi Direct.

A flowchart (Figure 3(b)) better explains the general usage of the proposed system. It starts with identifying the user type, i.e., whether the user is a driver or a non-driver by running a driver phone detection algorithm which has been researched extensively. Numerous works have been proposed for driver phone detection [11]. If the user type is determined to be a driver, the app opens a network port for WiFi Direct and waits for incoming messages from pedestrians. More specifically, the ‘autonomous’ mode of WiFi Direct [12] is used to ensure that the pedestrian immediately becomes the P2P Group Owner and surrounding vehicles scan for network to join the group. Once a message is received from a pedestrian, the driver phone joins the group created by the pedestrian and sends necessary information to the pedestrian so that the pedestrian can assess the safety level by performing the collision probability analysis. Consequently, the driver receives an alert message depending on the result of the assessment.

Now if it is determined that the user is a pedestrian, the proposed system continuously checks for the user-phone-viewing event, i.e., the user is walking while viewing his/her phone. In particular, even if the event is detected, when the user is not geographically close to a crosswalk, the GPS module is put into an inactive mode to save power consumption. On the other hand, if the user is close to a crosswalk and is viewing his or her phone while walking, the pedestrian immediately advertises a message to surrounding vehicles to create a WiFi Direct P2P group with them. As a result, the pedestrian is able to collect necessary information from surrounding vehicles via WiFi Direct. Based on the collected information, the pedestrian phone performs the collision probability analysis to determine whether or not to send an alert message to himself/herself, the driver(s), or both.

Iii-B Improving Positioning Accuracy

Fig. 4: Location errors in metropolitan area.

Pedestrian accidents occur frequently in urban areas. The positioning accuracy of GPS is, however, significantly degraded in urban canyons due to multipath and non-line-of-sight effects constraining the use of pedestrian safety apps. Using the GPS module of Samsung Galaxy S5, we collected GPS locations in the downtown of Minneapolis, United States, where skyscrapers are concentrated. Figure 4 depicts the measured GPS locations and the ground truth trajectory (green arrow). It can be easily noted that the location errors were significant compared with the ground truth trajectory. This section explains the Location module of WiSafeCross that is designed to eliminate location outliers, so that unwanted warning messages are not sent to pedestrians and drivers.

The Location module aims to effectively identify location outliers and replace them with estimated user locations. Figure 5 shows an overview of the module. The key idea is to leverage our prior knowledge on the user location, i.e., it is confined within a specific segment of a sidewalk. More precisely, given an obtained GPS location, this module identifies the most probable sidewalk segment that would contain the user location by using a Hidden Markov Model-based map matching algorithm. Once the sidewalk segment is estimated, an outlier rejection mechanism is applied to identify location outliers. Such outliers are either removed or replaced with the projected position on the sidewalk segment depending on the degree of location error.

Fig. 5: Overview of Location module.

An algorithm that estimates the current sidewalk segment is described. The design of this algorithm is motivated by recent map matching algorithms [13][14]. The proposed algorithm formulates the problem of identifying the most probable sidewalk segment using a Hidden Markov Model (HMM). More specifically, define a set of states where each state represents a sidewalk segment, where is the total number of states. To reduce computational overhead, only the road segments that are in the proximity of the current user location are considered as the states. Now based on HMM, the algorithm finds the most probable segment denoted by given an observation , i.e., a set of latitude/lontitude measurements in a sliding window at time .

More formally, a HMM is modeled as . is the state set, and is an observation that is represented as a sliding window consisting of GPS measurements of size at time , i.e., , where is a GPS measurement at time . is the observation probabilities denoted by which define the likelihood that the pedestrian is actually on each segment . is the transition probabilities that represent the likelihood of the pedestrian moving from one segment to another . is the initial state probabilities which are defined as . In contrast to [13][14], the key idea is to use a set of prior GPS measurements as an observation motivated by our findings that using a single GPS location as an observation incurs significant errors in identifying a sidewalk segment.

To determine the most probable state (i.e., a sidewalk segment), we need to model , , and . More specifically, in modeling , we leverage the observation that a measured location that is far from the true road segment is less likely [13]

. Thus, the probability distribution of the geodetic distance between

and denoted by where is the closest point on from , is used to represent . The geodetic distance specifies the GPS positioning error, which can be modeled as zero-mean Gaussian as follows.



is the standard deviation of GPS measurements, which can be obtained empirically. Now considering a set of GPS measurements in a sliding window, the observation probabilities

is defined as follows.

Fig. 6: Illustration of the moving distance and the geodetic distance.

Next the transition probabilities given two observations and are defined as follows. Note that there is a new GPS point compared with . Given two GPS points and , let us define the ‘moving distance’ as the distance between the two points along the shortest sidewalk trajectory. Figure 6 shows the geodetic distance and the moving distance between and . Newson and Krumm found that a transition between road segments would occur less likely when the moving distance is close to the geodetic distance [13]. However, we note that this does not apply appropriately to the pedestrian walking scenario where the pedestrian moves much shorter distance than a car between two GPS measurements. Thus, rather than using the two immediately subsequent GPS points to calculate the moving distance and the geodetic distance, two points and with some interval are selected. More specifically, given the two points, the difference between the moving distance and the geodetic distance is defined as . It was shown that

follows an exponential distribution 

[13]. Thus,


Here is a system parameter that a larger value represents more tolerance to non-direct paths. Consequently, we can define as the following.


We also note that using Eqs. 1 and 2, immediately follows.

Once the most probable sidewalk segment is determined, given that segment, previous GPS measurements, and the maximum brisk walking speed [15], we calculate a rectangular region (shown as a dotted blue area in Figure 5). The width of the region is defined as ‘ (max walking speed) (GPS interval)’, where is a parameter that adjusts tolerance to location error, and the height of it is ‘ (width of sidewalk)’. Consequently, measured GPS locations that are outside the region are rejected and replaced by the estimated location, which is defined as the projected location on the identified sidewalk segment’. Furthermore, if the measured GPS point is far from the region greater than a threshold, that GPS point is not considered. For our experiments, we used , and the threshold was 15m.

Iii-C Improving Energy Efficiency

Fig. 7: Experimental setup for power consumption measurement.
Fig. 8: Power consumption of GPS module of smartphone.

The GPS module of a smartphone is one of the major power consumers. Keeping the module on continuously will drain the battery very quickly. Experiments were performed to characterize the power consumption of the GPS module. More specifically, we used the Monsoon power monitor and Samsung Galaxy Nexus to measure power consumption. The experimental setup is depicted in Figure 8.

Figure 8 displays the power consumption of the smartphone GPS module. As it is shown, when the WiSafeCross app was started, a large amount of power was drawn to load, process, and display the app on the screen. It was also observed that the periodic position update of the GPS module used a lot of energy compared with when it was in the idle mode. These results indicate that if we put the GPS module into the sleep mode when it is not needed, power consumption can be reduced significantly.

To explain the Energy module, a term alert zone must be defined. The alert zone is a set of GPS points for which the geodetic distance to the nearest crosswalk (represented as a line segment) is smaller than a certain value, which is a system parameter that can be adjusted based on the degree of GPS positioning error. Now the key idea of the Energy module is simply to put the GPS module adaptively into the sleep mode if the user is not within an alert zone. More precisely, the Energy module estimates the minimum time for the user to arrive at the nearest alert zone, i.e., the estimated minimum time is calculated as where is the geodetic distance between the current user position and the nearest alert zone, and is the maximum brisk human walking speed [15]. The GPS module is then put into the sleep mode until this estimated time is expired. This design decision of calculating the distance to the nearest alert zone is to ensure maximum pedestrian safety as we do not know which crosswalk the user will use.

A notable observation is, however, that using the maximum human walking speed in estimating the user arrival time might cause the GPS module to turn on too early. The Energy module is thus designed such that the user can use his/her actual walking speed that is estimated based on the histogram of the actual user walking speed obtained from the Location module. More specifically, the user can select the walking speed at different percentile values from the histogram to adjust the balance between the accuracy of the estimated user arrival time and energy efficiency.

Iii-D Detecting Pedestrian Phone Use

It has been reported that 56% of pedestrian phone use is telephone communication [16], which can be easily detected by using the proximity sensor of a smartphone. However, other phone use involving a phone-viewing activity, e.g., texting, watching video, or reading email messages, which takes 21% of the pedestrian phone use is very tricky to capture especially when such activity does not incur user interactions like tapping on the phone. The Context module is designed to detect the user phone-viewing event efficiently to avoid sending false alert messages to drivers and pedestrians. A straightforward method to detect the phone-viewing activity is to utilize the phone camera to recognize the user face. This approach, however, raises privacy issues and consumes a lot of energy for running the camera and heavy-weighted image processing algorithms.

The key idea to detect the phone-viewing activity without using the phone camera is based on the observation that when users view their phones while walking, they tend to try to minimize the shaking of the phone to better read the screen, type a message for texting, or watch videos. So the Context

module examines the variance of the acceleration magnitude of the phone to quantify the shaking of the phone and use as an indicator to determine whether the user is viewing the phone while walking. More specifically, given the accelerometer data

of the phone in the , , and directions, the random noise is removed, and we obtain the filtered accelerometer data denoted by

. The magnitude of the acceleration vector

is then calculated as follows.

Fig. 9: Sliding window of 10 sec.
Fig. 10: Sliding window of 20 sec.

We define a sliding window of size that saves a set of the acceleration magnitude values, i.e., . For each sliding window, we calculate the mean absolute deviation (MAD) that represents the degree of shaking as follows.

Proof-of-concept experiments were conducted to understand the feasibility of this approach. Five human subjects walked with and without viewing their phones. Figures 10 and 10 show the results for different sliding window sizes of 10sec and 20sec, respectively. As it can be noted, the variance of MAD for the phone-viewing scenario was significantly smaller than when the user is not viewing his or her phone while walking. The results also indicate that the accuracy of event detection also depends on the window size. An optimal window size is determined for our experimental settings in Section IV-C.

Iii-E Alerting the User

Sending an alert message to an appropriate user in a timely manner is crucial to not disturb the user phone use and to prevent driver distraction. The Alert module is designed to calculate the collision probability, based on which to determine when and to whom to send an alert message.

Fig. 11: Overview of Alert module.

The Alert module is activated when the user enters an alert zone, and it starts to compute the collision probability to determine when to send an alert message to the pedestrian and/or the drivers of surrounding vehicles. More specifically, as soon as the position of the pedestrian is within an alert zone, the pedestrian sends a message via WiFi P2P to surrounding vehicles to obtain necessary information for calculation of the collision probability. The message consists of , , (Figure 11), where is the time for the vehicle to reach the crossing; is the time for the pedestrian to reach the crossing, and is the speed of the vehicle. The message sent by the pedestrian contains only ; surrounding cars receiving this message then calculate their and values, add them to the message, and send it back to the pedestrian. Given the information contained in the returned message, the pedestrian calculates the collision probability to determine whether or not to send an alert message, and to whom to send it. These message exchanges occur continuously while the pedestrian is inside an alert zone for computation of an up-to-date collision probability to ensure real-time safety.

In particular, is calculated differently depending on whether the pedestrian is walking or running. The Android context API is used to detect the user activity, i.e., walking or running, and the pedestrian speed is determined accordingly. To ensure greatest safety, the maximum user walking speed as well as the maximum user running speed were used [15]. Now given the pedestrian speed and the distance between the pedestrian and the crossing within the alert zone denoted by , can be calculated as . Note that is calculated similarly by the driver based on the vehicle speed, and the distance to the crossing ahead obtained from the Location module.

Now if for all surrounding vehicles , which means that all surrounding vehicles will pass before the pedestrian arrives at the crossing, no alert message is generated. Note, however, that any vehicle appearing in the range of WiFi Direct may invalidate this condition as the collision assessment is continuously performed. On the other hand, if the condition is not true, there is a chance of collision. We then define the ‘user warning time’ denoted by as such that , i.e.,, if there is at least one car that has not passed the crossing when the pedestrian arrived at the crossing. Now given the user warning time, the following conditions must be satisfied to send an alert message to the pedestrian and/or driver:

  • The pedestrian is walking/running while viewing the phone.

  • The probability of collision is greater than a threshold.

The first condition ensures that if the pedestrian is stopped, or not viewing his or her phone, then there is no need to alert him. The last condition indicates that the probability of collision must be greater than a threshold. Now we calculate the probability of collision given . The probability of collision is defined as:


where is the round-trip message delay for a single-hop 802.11 link; is the driver reaction delay; and is the amount of time from the point when the driver applies brakes until the car completely stops. If the sum of these time components is greater than , the likelihood of collision is deemed high. In particular, we disregard the WiFi Direct connection establishment time since the connection has been already established before the first message is sent from the pedestrian.

The probability of collision is explained in more detail. is empirically obtained as the pedestrian continuously exchanges messages with the vehicles. More specifically, we use the average of measured round-trip message delays as . In calculating , it is known that the log-normal probability model fits the driver reaction time well [17]. Thus, is defined as follows:


where we select and  [18].

To calculate , we first derive the distance that a vehicle moves before complete stop when full brakes are applied as follows.


where is the vehicle mass, is the vehicle speed, and is the resistance force, which is given as follows [10].


where is the density of air, is the cross-sectional area of the vehicle, is the drag coefficient, is the speed of the vehicle relative to the air, and is the other resistance force, e.g., due to the tire condition, and performance of the braking system. In our experiments, performed on a sunny day on a good conditioned road with Volkswagen Passat 2013, we used the parameter: , , , , according to [19][20][21]. was approximated as the current vehicle speed due to the slow wind speed. Thus,


Now since , , and are known, the collision probability can be written as:


which can be calculated as

follows the log-normal distribution specified in Eq. 


If all the conditions are satisfied, the pedestrian receives a warning message and is asked to respond to the message. An alert message is sent to the driver only if the pedestrian ignores the warning message a number of times to minimize driver distraction. The intuition is that due to the alert message, the user is expected to stop using his or her phone, and look up for safety. However, if the user keeps using it by ignoring the alert message times, an alert message is sent to the driver. This parameter can be adjusted to determine the tradeoff between the user safety and driver distraction. For our experiments, was used.

Iii-F Communication Engine

WiFi Direct supports only 1-to-1 or 1-to-many communication patterns. For example, CarA and CarB are connected to the WiFi Direct group owner PedA (Figure 11). However, the problem occurs when there is another pedestrian, say PedB who wants to send messages to CarA and CarB. But these cars would not respond to this request since they have formed a group with PedA already. To address this challenge, the following protocol is proposed.

The key idea is simple. A pedestrian, say PedB, overhears the network for a very brief period of time before it forms a group with the vehicles. If there is any pedestrian, say PedA, who has already formed a group with the vehicles, PedB stops broadcasting messages since it cannot form a group with the vehicles; instead PedB joins the group formed by PedA as a client. After that, any message exchanges between PedB and cars are done via PedA, basically implementing the communication between PedB and the vehicles without establishing a new group.

Iv Experimental Results

In this section, we evaluate the performance of WiSafeCross. We aim to provide answers for the following questions.

  • Does the Location module provide sufficiently high positioning accuracy in both rural and metropolitan environments?

  • Does the Energy module activate/deactivate the GPS module in a timely manner? What is the effect of human walking speed?

  • Does the Context module accurately detect the user-phone-viewing activity? What is the optimal system parameter for this module?

  • Consequently, putting all modules together, are alert messages sent to the pedestrian and drivers correctly, reliably, and in a timely manner?

The proposed system was implemented on Samsung Galaxy S5 with 1.5GHz octa-core processor, and 3GB RAM running on Android 5.0. Note that the energy measurement was done with a different phone, i.e., Samsung Galaxy Nexus, because Samsung Galaxy S5 did not expose its battery.

Iv-a Positioning Accuracy

Fig. 12: CDF of location error.
Fig. 13: CDF of location error after applying Location module.

GPS locations were measured in both rural and metropolitan areas with concentrated skyscrapers. Five different walking trajectories were selected in each environment. Given the ground truth trajectory that is represented as a sequence of line segments on a sidewalk denoted by that the user actually walked along, the location error for a GPS position was estimated as the shortest geodetic distance to the line segments as follows.

where is the geodetic distance between a GPS point and a line segment . Figure 13 depicts the location errors for the rural and city areas. The mean location error for the rural area was 0.97m while that for the city area was 12.99m. The error was significantly high in the city area which makes it impossible to use raw GPS data for WiSafeCross.

We then applied the proposed Location module in an attempt to reduce the location error especially in the city area. Figure 13 displays that the average location error for the rural and the city areas was 0.88m, and 3.57m, respectively. The location error was decreased by only 9% for the rural area since the error was already quite small for the raw GPS data. A notable result is that the location error for the city area was significantly decreased by 72%. Although an average error of 3.57m is not completely negligible, the huge error reduction by the Location module allows us to easily compensate for the error, e.g., by extending the range of an alert zone.

Iv-B Energy Efficiency

The longer the GPS module is put into the sleep mode, the more energy can be saved. On the other hand, it is important to reactivate the GPS module in a timely manner to ensure that an alert message is sent to the users at the right moment. This set of experiments thus are performed to confirm that the

Energy module activates/deactivates the GPS module appropriately to achieve the balance between energy efficiency and timely generation of an alert message. As a performance metric, we used the geodetic distance between the alert zone and the pedestrian location measured when the GPS module was reactivated.

Fig. 14: Histogram of measured walking speed.
Fig. 15: Performance of Energy module with varying walking speed.

To understand the effect of real-world human walking speed on the performance of the Energy module, we collected walking speed for a duration of 5mins, from which we derived a histogram of walking speed (Figure 15). Different human walking speed was used based on the histogram, i.e., values at 50th 90th percentiles of the histogram as well as the maximum human walking speed to estimate the time that the user will arrive at the nearest alert zone. The human subject started walking 30m away from the alert zone, and we measured the distance between the user location and the alert zone when the GPS module was reactivated by varying the human walking speed as described above. Results are depicted in Figure 15. The results indicate that the GPS module was activated nearly on time, i.e., about 1m away from the alert zone when the average user walking speed (at the 50th percentile) was used. Although the distance increased for faster walking speed, considering the location error and to provide utmost safety, we determined to use comparatively fast walking speed for our experiments (i.e., the maximum human brisk walking speed [15]).

Iv-C Context Detection

The Context module is used to detect the user-phone-viewing event. To evaluate the effectiveness of the module, we determined an appropriate window size that consists of acceleration magnitude values. We then found the threshold MAD value denoted by such that the event detection accuracy is maximized. Consequently, based on and , the performance of the Context module was evaluated.

As the first step, we performed experiments to determine . It must be selected such that it clearly distinguishes between the user-phone-viewing and non-viewing events. Let denote MAD values for the phone-viewing event, and be MAD values for the non-viewing event. A metric is defined to quantify how well the two events are distinguished as follows.

Fig. 16: Effect of window size.
Fig. 17: Detection accuracy of Context module.

A greater value indicates clearer distinction between the two events. We measured by varying . Seven volunteers participated in this set of experiments. Results are depicted in Figure 17. As shown, as increased, greater values were obtained. These results demonstrate that more acceleration magnitude values in a larger sliding window leads to better separation between the two events. We also note, however, that a larger causes delay in initializing a sliding window with acceleration magnitude data. Considering this tradeoff, we adopted the window size of 25sec for our experiments.

Given the MAD values of the two events that are separated sufficiently by selecting an appropriate window size , the threshold MAD value was determined. More specifically, we used the average of the mid points between a pair of MAD values (i.e., one for the phone-viewing event, and the other one for the non-viewing event) as the threshold :



Now based on the threshold and the window size , we measured the accuracy of the Context module for each participant. Seven participants walked for a duration of 5 mins while performing the phone-viewing and non-viewing actions. Figure 17 depicts the results, which demonstrate that varying detection accuracy was obtained for different participants potentially due to different phone using styles. Overall, the average accuracy was sufficiently high as 92%.

Iv-D Putting It Altogether

Fig. 18: A test site for proof-of-concept experiments.

We have verified the effectiveness of each module of WiSafeCross, and determined appropriate system parameters. We are ready to perform proof-of-concept experiments by integrating all modules with selected parameters. For these experiments, a department parking lot was used as a test site. The dimensions of this test site are shown in Figure 18. To ensure safety, all experiments were conducted when there was no car in the parking lot, and the vehicle speed was strictly controlled.

Fig. 19: User warning time and collision probability when an alert message is sent to the driver.

This section provides in-depth analysis on how the pedestrian and driver are alerted. We obtained time when the pedestrian sent an alert message to the driver, and recorded time when the vehicle received the message. The user warning time was then calculated that represents the amount of time allowed for the driver to avoid collision after discovering the pedestrian, i.e., after receiving the alert message. Figure 19 depicts the user warning time with varying vehicle speed. As shown, the driver is given less than 2 seconds when he was driving at the speed of 20mph. On the other hand, he had a relatively sufficient amount of time of greater than 10 seconds when he was driving at 5mph.

Considering the measured and , the collision probability was calculated when the pedestrian sent an alert message to the driver. The results are shown in Figure 19. The results indicate that after subtracting and from the user warning time, the driver is left with only less than 1 second to avoid the accident, resulting in a very high collision probability of nearly 100% when the vehicle speed was 20mph. On the other hand, WiSafeCross determined that the collision probability for the vehicle speed of 5mph was almost 0% as long as the driver received the alert message and applied braking.

Figure 21 shows the distance from the driver to the crossing when the driver received the alert message. To calculate the collision probability and to ensure that the driver received the alert message, we set the threshold for the collision probability to 0, i.e., the alert message was sent when the pedestrian entered into the alert zone, which was set to 7m away from the crossing. Note that this threshold was used for experimental purposes only, and it must be used to adjust the tradeoff between the pedestrian safety, and driver distraction.

Fig. 20: Driver warning per vehicle speed.
Fig. 21: Effect of vehicle speed on the packet delivery rates.

Besides, the collision probability would make sense only when the alert message was received by the driver. We measured the packet delivery rates by varying the vehicle speed. More specifically, we let the pedestrian continuously transmitted alert messages to the driver and measured the number of successfully received messages. In particular, to maintain the constant speed, we used the vehicle’s cruise control system and used part of the vehicle trajectory as the acceleration zone to reach the desired speed (Figure 18). Figure 21 displays the results which indicate that packets are in general very reliably received regardless of the vehicle speed although a slight decrease was observed for higher speed.

V Related Work

Wang et al. developed an app that uses the rear camera of a phone to detect the dangerous situation, and alert the pedestrian [4]

. A machine-learning-based image processing algorithm was designed to capture approaching cars for pedestrian safety assessment. This approach, however, raises the privacy issue as it takes photos of cars, and also suffers from the power consumption problem as the image processing algorithm consumes a lot of energy.

Specialized equipment was designed for pedestrian safety. Sensors were adhered to the pedestrians’ shoes to find whether the pedestrian is crossing at a crosswalk by detecting the slope between the sidewalk and the roadway [22]. An electronic transponder was attached to the pedestrian’s body to determine if the pedestrian is visible or not [23]. These specialized equipment, however, prohibit widespread adoption of the technology.

A cellular network was utilized to allow pedestrians to communicate with cars (i.e., car-mounted navigation system) via a backend server [7][24] [25]. Using a cellular network, however, not only incurs costs but also results in higher message delay compared with the direct peer to peer communication. Dedicated Short Range Communication (DSRC) is a wireless communication standard specifically designed for vehicle to vehicle communication (V2V). Researchers utilized DSRC as a means to enable vehicle to person (V2P) communication for pedestrian safety [5][6][9]. However, implementing DSRC on a phone requires significant modifications to the host system firmware, and extra device support is needed to operate DSRC for vehicles.

WiFi has been actively considered as an appropriate alternative technology to enable vehicle to pedestrian communication for pedestrian safety [26][8][10][9]. In particular, WiHonk is quite close to our work [8]. However, it was based on the modification of the beacon frame of IEEE 802.11 which requires the root privilege that makes it difficult for common use. Additionally, no consideration was presented on when to exchange messages with cars, potentially resulting in unnecessary network bottleneck [27]. WiSafe is another WiFi-based pedestrian safety system that is close to our work [10]. Our work is different in that the system design involves both the driver and pedestrian while WiSafe utilizes only one-way communication from a pedestrian to cars. Compared with existing WiFi-based approaches, the proposed work is distinctive in that it takes a holistic approach by providing solutions for practical issues on energy-efficiency, positioning accuracy, context awareness, collision probability analysis, and integrating them together to design the first fully-functioning pedestrian safety app.

Vi Conclusion

We have presented the design, implementation, and evaluation of WiSafeCross, a pedestrian safety app based on the WiFi Direct technology. Numerous techniques proposed in this work to address a number of practical challenges (i.e., positioning accuracy, energy efficiency, effective context awareness, and collision probability analysis) are expected to be used as resources for development of other solutions not only for pedestrian safety but also for general transportation apps.


  • [1] “Health Line,” http://www.healthline.com/health-news/tech-texting-while-walking-causes-accidents-0310141, accessed: 2017-5-1.
  • [2] “CBS News,” http://www.cbsnews.com/news/1-in-3-use-phones-text-while-crossing-the-road/, accessed: 2017-5-1.
  • [3] “Pedestrians,” https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/812375, accessed: 2017-5-1.
  • [4] T. Wang, G. Cardone, A. Corradi, L. Torresani, and A. T. Campbell, “Walksafe: a pedestrian safety app for mobile phone users who walk and talk while crossing roads,” in Proc. of HotMobile, 2012.
  • [5] X. Wu, R. Miucic, S. Yang, S. Al-Stouhi, J. Misener, S. Bai, and W.-h. Chan, “Cars talk to phones: A dsrc based vehicle-pedestrian safety system,” in Proc. of VTC, 2014.
  • [6] F. Seeliger, G. Weidl, D. Petrich, F. Naujoks, G. Breuel, A. Neukum, and K. Dietmayer, “Advisory warnings based on cooperative perception,” in Proc. of Intelligent Vehicles Symposium, 2014.
  • [7] C. Sugimoto, Y. Nakamura, and T. Hashimoto, “Prototype of pedestrian-to-vehicle communication system for the prevention of pedestrian accidents using both 3g wireless and wlan communication,” in Wireless Pervasive Computing, 2008. ISWPC 2008. 3rd International Symposium on.   IEEE, 2008, pp. 764–767.
  • [8] K. Dhondge, S. Song, B.-Y. Choi, and H. Park, “Wifihonk: smartphone-based beacon stuffed wifi car2x-communication system for vulnerable road user safety,” in Proc. of VTC, 2014.
  • [9] Z. Liu, L. Pu, Z. Meng, X. Yang, K. Zhu, and L. Zhang, “Pofs: A novel pedestrian-oriented forewarning system for vulnerable pedestrian safety,” in Proc. of ICCVE, 2015.
  • [10] P.-F. Ho and J.-C. Chen, “Wisafe: Wi-fi pedestrian collision avoidance system,” IEEE Transactions on Vehicular Technology, 2016.
  • [11] Y. Wang, J. Yang, H. Liu, Y. Chen, M. Gruteser, and R. P. Martin, “Sensing vehicle dynamics for determining driver phone use,” in Proc. of MASS, 2013.
  • [12] D. Camps-Mur, A. Garcia-Saavedra, and P. Serrano, “Device-to-device communications with wi-fi direct: overview and experimentation,” IEEE wireless communications, vol. 20, no. 3, pp. 96–104, 2013.
  • [13] P. Newson and J. Krumm, “Hidden markov map matching through noise and sparseness,” in Proc. of SIGSPATIAL, 2009.
  • [14] H. Aly and M. Youssef, “semmatch: Road semantics-based accurate map matching for challenging positioning data,” in Proc. of SIGSPATIAL, 2015.
  • [15] “Brisk Walking Speed,” https://www.verywell.com/how-fast-is-brisk-walking-3436887, accessed: 2017-5-1.
  • [16] “Look Up,” https://intersections.devpost.com/submissions/26518-look-up, accessed: 2017-5-1.
  • [17] G. T. Taoka, “Brake reaction times of unalerted drivers,” ITE journal, vol. 59, no. 3, pp. 19–21, 1989.
  • [18] D. Gazis, R. Herman, and A. Maradudin, “The problem of the amber signal light in traffic flow,” Operations Research, vol. 8, no. 1, pp. 112–132, 1960.
  • [19] D. R. Ankrum, “Ivhs-smart vehicles, smart roads,” Traffic Safety (Chicago), vol. 92, no. 3, 1992.
  • [20] R. W. Rivers, Evidence in traffic crash investigation and reconstruction: identification, interpretation and analysis of evidence, and the traffic crash investigation and reconstruction process.   Charles C Thomas Publisher, 2006.
  • [21] W. Hugemann, “Driver reaction times in road traffic,” in Proc. of XI EVU, 2002.
  • [22] S. Jain, C. Borgiattino, Y. Ren, M. Gruteser, Y. Chen, and C. F. Chiasserini, “Lookup: Enabling pedestrian safety services via shoe sensing,” in Proc. of MobiSys, 2015.
  • [23] A. Fackelmeier, C. Morhart, and E. Biebl, “Dual frequency methods for identifying hidden targets in road traffic,” in Advanced Microsystems for Automotive Applications 2008.   Springer, 2008, pp. 11–20.
  • [24] A. Flach and K. David, “Combining radio transmission with filters for pedestrian safety: Experiments and simulations,” in Proc. of VTC, 2010.
  • [25] C.-H. Lin, Y.-T. Chen, J.-J. Chen, W.-C. Shih, and W.-T. Chen, “psafety: A collision prevention system for pedestrians using smartphone,” in Proc. of VTC, 2016.
  • [26] J. J. Anaya, P. Merdrignac, O. Shagdar, F. Nashashibi, and J. E. Naranjo, “Vehicle to pedestrian communications for protection of vulnerable road users,” in Proc. of Intelligent Vehicles Symposium, 2014.
  • [27] A. Rostami, B. Cheng, H. Lu, J. B. Kenney, and M. Gruteser, “Performance and channel load evaluation for contextual pedestrian-to-vehicle transmissions,” in Proceedings of the First ACM International Workshop on Smart, Autonomous, and Connected Vehicular Systems and Services, 2016.