Someone to Watch Over You: Using Bluetooth Beacons for Alerting Distracted Pedestrians

Abstract

In the United States, an estimated 7,005 (crude rate 2.13) pedestrians were killed in traffic crashes in 2020, according to the Centers for Disease Control and Prevention (CDC). This statistic is currently increasing annually and research suggests that distraction by smartphones may be a primary reason for the increasing number of pedestrian injuries and deaths. Timely interruptions may alert inattentive pedestrians and prevent fatalities. To this end, we developed StreetBit, a Bluetooth beacon-based system that warns distracted pedestrians with a visual and/or audible interruption when they approach a potentially dangerous traffic intersection while distracted by their smartphones. We posit that by using StreetBit, we can educate distracted pedestrians and elicit behavioral change to reduce or remove smartphone-based distractions when they enter and cross roadways. To demonstrate the feasibility of StreetBit, we conducted a field study with 385 participants. Results show that the system demonstrates adequate feasibility and behavior change in response to the StreetBit program.

I. Introduction

The number of pedestrians killed in traffic in the United States is increasing [1]. Several reasons are likely contributing to this public health issue, but the increasing number of pedestrians distracted by mobile devices is commonly hypothesized to be a significant contributor [2], [3], [4], [5]. Therefore, pedestrians distracted by smart devices have gained attention in the public and research communities. Our research seeks to address the problem through a novel and innovative technology that alerts distracted pedestrians of their risk at the moment they approach a busy intersection. Distracted pedestrians suffer from three types of impairment. Pedestrians’ visual focus may be impaired if they look at their phones while approaching or crossing a roadway. Similarly, listening to music or a phone call while walking impairs their auditory focus. There is initial evidence that auditory cues are used extensively by safe adult pedestrians [6], [7], [8]. Finally, perhaps less explicitly obvious but probably most critical for safety, a distracted pedestrian suffers from reduced cognitive attention. Crossing the street requires substantial processing of stimuli and rapid decision-making [9], [10], [11]. Therefore, pedestrian safety may suffer when the cognitive load is split between walking and smartphone use [12]. Empirical research evidences the consequences of distraction. For example, one survey showed that 51% of young adult phone users bumped into other person or objects while walking distracted [13]. Another study showed that 75% of participants distracted by a smartphone failed to notice a clown on a unicycle as they walked by it [14].

One effective strategy to reduce distracted pedestrian behavior would be to intrusively alert distracted pedestrians via smartphone as they approach street-crossings. Such a system would need to be precise enough to notify an inattentive pedestrian approaching an intersection but not give false alerts at other times. We, therefore, developed a system that uses Bluetooth Low Energy (BLE) as a platform for position detection of potentially-distracted smartphone users as they approach intersections. We performed these tasks through an application named StreetBit. The technology is economically feasible to adopt because of the affordable cost of Bluetooth beacons. In addition, the StreetBit app consumes low energy since it operates in the background, bringing itself to the foreground only when the user is distracted and within range of a Bluetooth beacon installed at target intersections. Finally, it is grounded in behavior change theory, offering an intrusive alert only at times when the user is engaging in dangerous behavior and remaining silent and hidden otherwise.

This paper aims to demonstrate the feasibility of the StreetBit system by exhibiting the following features: (a) StreetBit can accurately assess when users are approaching a traffic intersection; (b) StreetBit can accurately determine if individuals are distracted by their smartphone usage as they approach and enter an intersection; and (c) StreetBit’s alerts encourage users to stop distracting activities, reducing their risk of injury when they cross an intersection. To evaluate the system’s feasibility and usability, we conducted a study among 385 participants [15]. During the study, we analyzed their behavior while crossing a targeted road intersection. The sample was demographically diverse and adults of all ages were eligible to participate. We also restricted recruitment to individuals familiar with smartphone technology and who were willing to frequently cross the target intersection chosen for this study.

Contribution:

We make the following key contributions in this study:

1. This study demonstrated that Bluetooth beacons could be an effective and low-cost solution for alerting distracted pedestrians about their risky behavior in and near traffic.

2. We deployed a real-life implementation of the solution through the StreetBit app and identified the practical challenges and solutions for deploying such a system in a heavily trafficked urban environment.

3. Finally, we performed a user study and collected post-completion survey data to demonstrate the feasibility and effectiveness of StreetBit. The results show that in 71% of distracting events, participants stopped engaging in their distracting activity on the smartphone after getting the alerts. In addition, participants’ phone angles changed from Phone-in-use to Phone-in-not-use mode in 23.74% of the events. This implies that StreetBit is effective in preventing distraction among a majority of pedestrians. 73.3% of participants responded that they were more careful while crossing the street after using the StreetBit app. More than 52% of the participants thought that the StreetBit app changed their street-crossing behavior.

II. Background

A. Distracted Pedestrians

Almost everyone has witnessed pedestrians engage with their smart devices while walking, whether on social media, talking, or listening to music. People even use smartphones at busy intersections and on crowded sidewalks[16], [5]; in those cases, they are unaware of their surroundings. These are known as “Distracted Pedestrians” [17], [18] or “Smartphone Zombies”[19]. However, behavioral research has shown that using a smartphone while walking on the road diverts walkers’ attention away from the difficult cognitive-perceptual process of navigating through traffic [17], [20]. The diverted attention likely increases the risk of injuries and fatalities. The number of pedestrian fatalities increased by 53% during the previous ten years from 2009 to 2018; by comparison, the combined number of all other traffic deaths increased by 2% [4]. The average yearly number of non-fatal medically attended pedestrian injuries in the United States is about 200,000 and has been growing in recent years [1].

According to cognitive science research, multitasking (attempting to accomplish two cognitively challenging activities simultaneously) reduces attention and performance on one or both tasks [12]. The use of mobile devices, whether for phone conversations, text messaging, or internet surfing, imposes some level of cognitive load on the user, limiting their capacity to concentrate cognitive effort on the street-crossing activity. Apart from cognitive distraction, some forms of distraction (i.e., texting, internet surfing, etc.) reduce visual attention to the street environment, while others (i.e., music listening) reduce auditory attention. Reduced cognitive, visual, and/or auditory attention impairs pedestrian safety in all instances [21], [22], [8], [23], [17], [5].

B. Bluetooth Beacons

A Bluetooth beacon is a small wireless device that works based on Bluetooth Low Energy (BLE) [24]. BLE beacons are capable of transmitting signals that include identifying information. The Universally Unique IDentifier (UUID), Major, and Minor together make up the beacon’s unique identifier. UUID is a 16-byte string that distinguishes the group of beacons in the same network from another network. Major and Minor are both 2-byte unsigned integers, where Major values indicate a group of beacons from the same network, and Minor identifies a specific beacon in a group.

Any device enabled with Bluetooth Low Energy (BLE) may receive the broadcast signal and determine its source in terms of distance. The beacon can also transmit signals at different broadcasting powers. The stability of the signal depends on broadcasting power and advertising rate. Higher broadcasting power and advertising rate frequency provide a stable signal with a greater range. However, higher broadcasting drains the battery faster. Therefore, the values of advertising rate and broadcasting power depend on the use case of the beacons. If distance measurement is important for the application, then higher values must be set.

Most smartphones currently support BLE technology, including all Android phones released after version 4.3 and all iPhone models released after the iPhone 4. Several BLE beacon manufacturer companies compete in the market, including Estimote¹, RadBeacon², BlueCats³, Kontakt⁴, and Gimbal⁵. We chose Estimote beacons for this study because they offered good documentation and affordability. Currently, a development kit with four Estimote proximity beacons costs $99. Besides, the Estimote beacons are energy efficient – an Estimote beacon can run on two AAA batteries for one to three years [25].

III. Related Work

A number of technological approaches have been proposed to enhance the safety of pedestrians crossing traffic intersections [26]. In particular, several previous studies exploit communication between vehicles and pedestrians’ smartphones [27], [28], [29]. Others use cameras, sensors, GPS, and other technology, to detect distracted drivers and alert them. We can categorize the existing pedestrian safety systems based on technology used, including inertial sensors, positioning, camera, augmented reality, etc. Jain et al. [30] developed a pedestrian safety system using a shoe-mounted sensor named LookUp. The system automatically detects transitions from a sidewalk into a road. LookUp warns the pedestrians whenever the sidewalk descends into the street, either through a ramp or a curb. However, LookUp can not provide a pre-alert to the pedestrians; users have to enter the street to receive a warning. ObstacleWatch, developed by Wang et al. [31], is a collision detection system for pedestrians based on a smartphone’s acoustic sensors. However, multiple sources of acoustics and personalized phone holding behavior affect the angle calculation. Auto++, developed by Li et al. [32], is another acoustic-based system. It detects the sounds of vehicles from different directions and warns the pedestrian if any cars are approaching. However, this system only works for moving vehicles that actively emit acoustic noises.

Usually, users in positioning-based safety systems share GPS data with associated parties. After that, the system calculates the distance, relative velocity, etc., and warns users by identifying collision possibilities. This technique has an advantage; the detection could be non-line-of-sight. That means the obstacle does not need to be within the pedestrian’s eyesight. Lin et al. [33] proposed pSafety, which adopts the intrinsic GPS receiver of smartphones and instantly alerts a pedestrian to potential collision events. However, the signal accuracy in the consumer devices is low (e.g., in the iPhone 6, the position accuracy is 7-13 m [34]). The accuracy of GPS depends on sufficient signal quality received, which often limits the accessibility. Besides, the GPS chip is hungry for power, which drains the smartphone battery. Most importantly, using GPS-based systems raises privacy concerns about the exposure of user location data.

Mobile cameras have developed over time and now support a multitude of techniques that were difficult less than a decade ago. For example, mobile cameras are increasingly used in pedestrian safety to detect approaching vehicles toward the pedestrian, discover the sidewalk accessibility, and identify incoming hazards. Wang et al. [35] developed a smartphone application named WalkSafe for pedestrian safety that detects approaching vehicles using the back camera of a smartphone. Jain et al. [36] proposed TerraFirma, a smartphone camera-based safety application. TerraFirma characterizes the materials and texture of the ground surface and detects the pedestrian’s transition from the sidewalk to the street. The AutoADAS [37] and Inspector [38] developed by Wei et al. and Tang et al. respectively warn the pedestrian while distracted. The AutoADAS detects the obstacle or hazardous object, while Inspector identifies the traffic hazard based on the distinctive surface pattern. However, continuous image streaming is not energy efficient and needs significant computation power. The phone’s orientation with respect to objects, the requirement of direct-line-of-sight, and image quality due to mobility make the use of camera-based systems challenging.

Augmented Reality (AR) applications render virtual images over real-world objects with various sensors and calculate the objects’ distances. AR applications use device cameras to collect, process, and show potential obstacles in pedestrians’ direct-line-of-sight. Kang et al. proposed SafeAR [39], an obstacle alert system for pedestrians using AR applications while walking. The system extracts 3D feature points which are visually exclusive and the 6DOF (Six Degrees of Freedom or 6D position) camera pose from the input image. Then SafeAR calculates the distance between each feature point and the ground (reference plane). If the distance is greater than a specific value, the feature points (object) are identified as obstacles. Hesenius et al. [40] designed a navigation system with augmented traffic to guide pedestrians. The application provides multiple features to pedestrians, including the exact navigational path, safe zone to cross the street, and information of incoming vehicles. Gruenefeld et al. [41] developed a prototype of peripheral vision-based glasses to protect pedestrians in critical traffic encounters. The system protects pedestrians at an intersection, where a car is either approaching from the pedestrian’s left or right side. In AR-based systems, efficiency mostly depends on feature extraction accuracy. Textureless objects can not provide high accuracy during extraction from the inputs. A sudden change of illumination, angle, and distance leads to an error in detecting an obstacle and impeding the visual process. Besides, pedestrians need to wear AR-supported devices (e.g., AR glasses, headset) while crossing the intersection and walking. In addition to the above technology, some studies used a hybrid safety system. For example, InfraSee [42] developed by Liu et al., can detect a sudden change in the ground using an infrared sensor that augmented the smartphone. To remove the human walking-induced noise, InfraSee uses smartphone embedded sensors. However, infrared sensor-based systems require a direct-line-of-sight to detect any obstacle.

IV. System Design

A. Define Distraction

We defined distraction based on the use pattern of the smartphone. Therefore, we established a set of conditions. If all these rules are true for a pedestrian, the StreetBit system identifies that individual as distracted. The sets of conditions are listed below:

1. The pedestrians are within the intersection area or activation zone. StreetBit adopted a 20-meter radius as an activation zone.

2. The pedestrians are moving and approaching the intersection. The possible measures are - walking, tilting, still, and running.

3. The smartphone’s screen is ON.

4. (a) The pedestrians are engaged in an application (i.e., texting, playing games, etc.).

   OR

   (b) The pedestrians are talking or listening to something on their phones (including video).

   [If 4(a) is true]

5. The pedestrians are holding their phones within a specific angle.

Figure 1 presents how the system determines a user as distracted. StreetBit detects distraction in two ways. Condition 1,2 and 3 are common in both cases. Therefore, the system checks if a pedestrian is in the intersection area, then if pedestrians are moving toward the intersection, then if the pedestrian’s phone screen is ON. If all these answers are Yes, then StreetBit checks the fourth condition (two segments), that is, if the pedestrian is talking, listing to music on the phone (a), OR interacting with apps (b). If the answer is Yes for condition (a), StreetBit identifies pedestrians as distracted. On the other hand, if condition (b) is true, StreetBit checks condition 5, if Phone In-Use-Angle, and marks as distracted if the answer is Yes. StreetBit checks each condition one by one and does not move on to the next condition if any state receives a NO response. However, StreetBit performs phone angle estimation independent of whether the pedestrian is distracted or not-distracted. Therefore, we declare this module as a service that calculates phone angle in each second and stores it in the database. Figure 1(a) illustrates the flow diagram of distraction detection. Figure 1(b) shows the different holding angles of the phone while pedestrians walk, which is measured by Pitch and Roll values to determine phone In-Use-Angle (Figure 1(c)).

Fig. 1.

How StreetBit defines a pedestrian as distracted. (a) The rule-based workflow of pedestrian distraction detection while crossing. (b) Pedestrians hold their phones at multiple angles during walking. (c) To cover most of the smartphones’ angles during walking, StreetBit stores the Accelerometer, Gyroscope, and Magnetometer values, then takes maximum Pitch (X-axis values) and Roll (Y-axis values) as phone In-Use-Angle.

B. System Requirements

The primary purpose of this study was to provide a framework for a pedestrian safety system that is designed to deal with distracted individuals. In particular, we aimed to develop a system that would accurately detect whether a pedestrian is distracted by a smartphone while approaching an intersection and, if so, issue warning alerts to them at the appropriate time and place. Based on our analysis, the desired properties of our system include:

1. The system should accurately determine if a user is distracted or not. If the user is not distracted, they should not get a warning.

2. The system must be able to locate the pedestrian as precisely as possible to provide warnings at the appropriate time.

3. The alert should interrupt distracted behavior, but should not be annoying to users. After crossing one side of intersection, the user may cross a second side immediately - this would happen, for example, when a pedestrian needs to reach a destination catty-corner to their current position. The warning should not be shown twice in that case. Similarly, the system should not send a warning to a pedestrian who turns right or left on the sidewalk at the intersection without crossing any streets.

4. There should be multiple ways to provide warnings to pedestrians, including notifications, overlay video warnings, audio alerts, and vibrations. However, the warning should not be provided in such a way that it distracts the pedestrian.

5. The system should have high availability. The Bluetooth beacon hardware should be able to withstand natural extremities such as extreme heat, cold, rain, wind, etc. Moreover, the whole system should be energy efficient. Both the hardware and software should be optimized in energy consumption for longer uptimes.

The full StreetBit system consists of three components - BLE beacons, the StreetBit mobile application, and a backend server for data storage (study data analysis). We explain the components in the following subsections. First, we justify the choice of Bluetooth beacons as the location and positioning mechanism in our system.

C. Justification for the Use of Bluetooth Beacons

As we are considering pedestrians who are distracted due to the usage of smartphones, smartphone applications are the most logical, feasible, and direct way to alert users about their risk. Considering the design goals, we chose to use BLE beacons, which broadcast signals to smartphones. An app in the smartphone uses the signal to determine users’ locations and display alerts to them if they are distracted. The recent development of Bluetooth technology has changed the way of communication among enabled devices (i.e., smartphones, smart cars, etc.). For example, Bluetooth 5.0 provides four times the range, twice the speed, and eight times the broadcasting capacity compared to Bluetooth 4.0 [43]. The transfer speed is up to 2 Mbps, which enables in-time warnings and reduces the broadcasting delay. Another major reason to choose Bluetooth over other available technologies is low power consumption. Since the receiver application has to allow the required service (i.e., Bluetooth, Location Service, Network Service, etc.) to receive signals, we chose the least battery hungry BLE technology [44], [45]. GPS-based positioning, WiFi, and geofencing could offer an alternative way to implement the warning system. However, there are some shortcomings of using these services, including continuous location services, inaccessibility of signals, communication delay, and accuracy. For example, the lack of signals and the horizontal error of positioning accuracy often limit GPS uses in consumer-level devices [46], [47], [34].

D. Using Bluetooth Beacons for Positioning

BLE beacons offer excellent potential to localize users using smart devices. BLE beacons send out signals that devices can detect. A smartphone application may estimate the approximate distance from the beacon after receiving the signal (Estimote provides an API for this purpose). Beacons can be placed at corners of the intersection so that the app detects signals and determines that a pedestrian using a phone is approaching closer and is likely to cross the intersection. However, in practice, we identified a limitation – the smartphone application takes 1-2 seconds to capture the signal from the beacon for the first time. We discuss how we addressed this limitation below, in section V.

After receiving the broadcast signal from the beacons, the smartphone application needs to identify correctly whether the user is near the intersection. Therefore, the app has to recognize beacon identifying information. Once the beacon has been appropriately identified, the app must figure out how far it is from that beacon. The signal strength and measured power are used to compute the distance to the beacon. The Received Signal Strength Indicator (RSSI) measures signal strength. The RSSI value decreases with increasing distance. Other effects, such as absorption, interference, or diffraction, may impact RSSI values.

For proper distance calculation, the signal must be as stable as possible. The Estimote beacons have broadcasting power ranging from −40 dBm to +4 dBm. The proximity beacons can theoretically transmit signals up to 70 meters at maximum transmitting power (+4 dBm), but in practice, we find the maximum range to be about 40-50 meters. The range and energy consumption of a beacon are directly linked to its transmitting power. With increased transmitting strength, a greater range may be achieved with a higher energy cost. The advertisement interval is another critical metric for beacon signals. This is the frequency at which the beacon transmits its signal. The advertisement interval ranges between 100 and 2,000 milliseconds. With a shorter advertisement interval, the signal becomes more steady. However, shorter intervals need more energy than longer intervals.

E. Frequency of Alerts

To ensure that the alert does not become annoying to pedestrians, it is necessary to decide when and how many times the alert should be provided. Showing alerts multiple times across short intervals may make the user annoyed. It can be assumed that users will be cautious for a while after receiving an alert. Therefore, we designed our system to ensure that the app does not provide alerts again as long as the user remains in the same intersection.

F. Phone Angle Estimation

Pedestrians use their phones in different orientations when they walk; their positions may change based on the situation. The main challenge of smartphone angle estimation from the embedded sensors is the variable reference point due to anthropometric characteristics (e.g., height), holding patterns, and different carrying locations. We used the projection-based technique for device orientation transformation. This transformation generates data to place in the uniform coordinate system. The application collects sensor data and pre-processes by normalizing with mean and standard deviation; then, the global coordinate values are calculated from these data. After that, the application converted these data to corresponding angle values. StreetBit applied the K-Nearest Neighbor (KNN) [48] algorithm to identify possible clusters for different smartphone angles. We set the threshold value for Pitch between 0 to 90 and the Roll value as −50 to +50. If the angles are laid between the threshold value, it is In-Use-Angle mode; otherwise, In-Not-Use-Angle mode. StreetBit application continuously records the phone’s angle values whether the screen is ON or OFF within the intersection.

G. Experimental Setup

We choose to conduct this research at a busy traffic intersection at our urban campus. We installed Bluetooth beacons at designated locations on all four corners of the intersection. Figure 2(a) indicates the approximate locations of 14 beacons in the four corners and the landscaped median, which divides traffic directions on the busier cross-street. Eleven of the fourteen beacons were mounted on light poles or traffic signal posts, and the other three were mounted on stakes. Figure 2(b) shows pictures of some of the installed beacons. To ensure the beacons would not be damaged by bad weather conditions, we first placed them inside a waterproofed sealed Ziplock bag. We then used duct tape to affix the beacon in a stable position.

Fig. 2.

Beacon installation. (a) shows the positions of installed beacons in the specified intersection. The green circles represent individual beacons with identification numbering, which we defined during the experiment. (b) Some installed beacons at the intersection (light-posts).

There are three beacons at each corner of the intersection; one is called the main beacon (middle one), and the other two are called helper/supporting beacons. They help to initiate the calculation of distance and launch the sensors. The final two beacons are placed in the median of the wider roadway to ensure that all beacon zones are linked together. Combined, the 14 beacons are arranged in a manner to ensure users remain inside at least one beacon zone at all times while crossing the intersection. Hence, the beacon zones overlap somewhat with each other.

H. Mobile Application

Recognizing the popularity of both Android and iOS devices, we created StreetBit mobile applications for both platforms. The Android version was developed with Java and compatible with Android 6.0 (Marshmallow) or newer. The iOS application was developed by Swift, and it is compatible with iOS 12.1 or newer. StreetBit identifies the distraction and gives alerts appropriately to the pedestrian. StreetBit defines each crossing as one event, and pedestrians get only one alert at each event. It provides two types of alerts: visual alerts and aural alerts. Based on the situation, a pedestrian can get either a visual alert, an aural alert, or both types of alerts simultaneously. StreetBit plays a pre-recorded warning voice for aural alerts when a pedestrian is distracted aurally. StreetBit shows a visual alert with animation on the phone screen when the pedestrian is distracted visually. By default, there are two ways to show a warning – full-screen pop-up and notification. The iOS platform delivers the notification warning and automatically disappears after 3 - 5 seconds from the screen but resides on the notification panel. The android platform offers a pop-up alert, and pedestrians have to acknowledge it. Users can select warning modes, including audio alerts, visual alerts, and simple header notifications; for the purposes of our study, we defaulted the app to require all alerts and the largest visual popup possible on the device. StreetBit tracks the pedestrian’s phone angle measurement to get the response. It could happen when the pedestrian receives an alert and acknowledge it by moving the phone position without clicking anything on the screen. Figure 3 provides an overview of the StreetBit application’s user interface and an example of visual warning.

Fig. 3.

StreetBit mobile application. (a) shows the app calculating the distance from the nearest intersection corner, which appears only on start-up and is not seen by most users. (b) showing alert in the StreetBit home screen. (c) Overlay alert from StreetBit while the distracted pedestrian is using YouTube on an Android phone.

I. Application Workflow

We generated the required number of random user IDs and pre-populated them on our server. After successfully installing the StreetBit app on a smartphone, users provided permissions such as location service, Bluetooth access, notification, and overlay screen display. After allowing these permissions, the user could log in to the system with a user ID. Following a successful login, users were not required to interact further with the application except when responding to alerts. The app always ran in the background to avoid disturbing regular phone usage. When users walked with the phone, StreetBit waited for signals from the beacons. We assured that the app could differentiate between walking users (who should get an alert if they are distracted while in the intersection) versus users who are driving through the intersection (who should not get an alert) by measuring the speed and nature of movement, as measured through the smartphone’s sensors.

Since communication between the beacons and the application occurs through Bluetooth, the user needs to enable the smartphone Bluetooth service. Upon receiving a signal, the app identifies the beacon along with the approximate distance and thus identifies the current zone. Whenever a smartphone recognizes multiple beacons, the distances between them is utilized to calculate the user’s current zone and precise position. The distance between the closest beacon is recorded for future calculations. This computation is repeated for each signal update iteration. Based on the road widths and the distance between beacons at the study site, we selected a radius of 20 meters for supporting beacons, called the activation zone and 8 meters for main beacons called the alert zone. Figure 4 shows the beacon characteristics, which depend on their location. The StreetBit app collects data when users enter the activation zone and stop when they leave all beacon zones.

Fig. 4.

Beacon characteristics based on the position. The main beacon radius is 8 meters and the system gives an alert if the pedestrian enters this region. The supporting beacons radius is 20 meters and they are responsible for the system activation.

From the time when a user enters the zone of the first beacon to when they leave the zone of the last beacon is considered one single event. A user receives only one alert during this single event. The alert is issued for the first time when the user attempts to enter the intersection in a state identified as distracted. The application does not show an alert if the phone is locked and no audio is playing. After giving an alert, the user’s response is recorded based on whether the user stopped using the smartphone or ignored the warning and continued using it. In the case of a visual alert, the user’s response by swiping/clicking the alert is also recorded. The system is designed to provide alerts around 2-3 meters away from the intersection. Maintaining this distance is important to ensure that the users become aware of the upcoming intersection from a safe distance.

When the application identifies that an event has started, it begins collecting data at an interval of every one second. Collected data from the smartphone includes music status, lock status, screen brightness, smartphone orientation, nearest beacon number, nearest beacon distance, and values from various sensors, including the accelerometer, gyroscope, and magnetometer. Data collection does not depend on providing the alert. Instead, the application always collects data within the target intersection irrespective of whether any alert has been shown (and thus, whether the user is distracted or not for analysis purposes). After completing the event, StreetBit sends the data from the whole event to the server. In the case when there is not an active Internet connection in the user’s phone, the application saves the event data in internal storage and sends it to the server later when an Internet connection is available.

V. Practical Challenges and Mitigation Strategies

A. Vertical Position and Placement of the Beacons

We considered the installation height from the ground and the distance between each beacon in order to get the most accurate results and notify users at the proper time. We assessed the height at which distracted pedestrians would hold their devices while walking. We mounted beacons on lampposts 2-3 meters high and stakes 1-1.5 meters high. As the StreetBit app considers one crossing event to start when a pedestrian enters one side of the intersection and exits on another side, we chose a 20-meter radius for the outer circle for activation of the application. We also placed all beacons in such a way that the beacon radii would overlap each other. Figure 4 shows how multiple beacons create a common zone.

B. Weatherproofing and Vandalism

We installed the beacons on posts and stakes using clear plastic bags and duct tape. We worked judiciously while affixing duct tape around the plastic bag because the signal strength would be diminished if we placed the duct tape over the beacon’s signaling device. Additionally, we had to deal with environmental issues like heat, cold, rain, wind, etc. We placed the beacons such that no rainfall could penetrate the plastic bag to decrease the beacons’ effectiveness or signal strength. We chose a thin bag since thicker ones weakened the signal strength.

We originally had planned to cover the beacon with a metal box but altered that plan because the metal box also decreases the signal strength. We also faced the challenge of the threat of having the beacons stolen off the lampposts and stakes by vandals. In fact, we did have two stolen beacons during the study period. In both cases, the thief tore apart the duct tape and plastic bag and pulled the beacon off the light post. In both cases, we recovered the stolen beacon from the surrounding area (the criminal(s) apparently were frustrated that the beacon was useless to them and, therefore, they discarded them on the street). We reinstalled them promptly.

C. Presence of Obstacles

Beacon signals differ significantly in the presence of obstacles, such as buildings. At our study site, there are three tall buildings around the intersection (see Figure 2(a)). The signal is very strong on the front side of the buildings. Moreover, there are several trees around the intersection. We considered these issues in determining the proper placement for beacon installation through trial and error.

D. Unequal Width of the Road

The width of the two roads in our target intersection are unequal; one road is significantly wider than the other. The 20-meter range for the beacons worked well to track pedestrians as they crossed the narrower road, but it did not work as expected for the wider road. We found users extended out of the range as they crossed the wider road, falsely initiating a new event. Hence, we placed two additional beacons beyond our original plan into the median of the wider road. The median, which was landscaped with shrubbery, provided an appropriate location for beacons and those additional beacons serve as a link between the beacons on the corresponding sides of the wider street.

E. Unequal Distances Between the Posts

The light posts and walk signal posts are not in optimal positions for beacon installation. To adjust, we calibrated the StreetBit app multiple times to make the system work perfectly. The radii of the signal reachability of the beacons vary somewhat based on their position and orientation. One strategy that we used originally to adjust for these challenges was to install beacons on trees near the intersection. However, we recognized that the duct tape we used to install beacons on trees could damage the trees’ bark, trapping moisture and making the trees vulnerable to disease. Thus, even though beacon placement on trees offered greater convenience for the app’s calculations, and the posts were further away from the ideal positions, we removed the beacons from the trees and placed them on light posts instead.

F. Fluctuation of RSSI

RSSI denotes the signal strength received by the enabled device from the beacon. Signal strength is proportional to the broadcasting power and inversely proportional to the measured distance. However, the value might change because of absorption, interference, or diffraction. These factors influence the outcome of the distance computation since the measured distance fluctuates in response to the RSSI variation. Specifically, the fluctuation increases if the distance between the device and beacon increases. We observed variations in calculated distances, even while standing in a single place. We overcame this challenge by introducing the activation zone and the alert zone (Figure 4). When pedestrians approach an activation zone (supporting beacons), the application starts triangulation, keeps tracking the user movement, and turns on the sensors. StreetBit receives all nearby RSSI, calculates the relative distance every second, and store the values. The system compares these available distances with user activity (i.e., walking, running). If an unusual distance (RSSI fluctuation) identifies from a particular beacon, the application calculates the average distance with the help of other signals and previous values. Therefore, the distance calculation becomes more precise when a pedestrian keeps approaching the alert zone. Pedestrians only get a warning in the alert zone if distracted at the main beacon.

G. Battery Drainage of the Smartphone

We encountered power drainage issues with Android-based cellphones. For the iOS version, the operating system maintains device utilization such as Bluetooth and GPS; therefore, battery life was not impacted. In contrast, the program operates and collects data through GPS, Bluetooth, internet connection, and sensors on Android devices. We addressed Android’s battery drain issues by implementing adaptive use of these functionalities. StreetBit activates the sensors and location service only when the user reaches the activation zone. When users leave the intersection, the program disables all sensor and location services to save battery power. In addition, StreetBit runs all services in the background to reduce battery consumption during this time.

VI. User study

Following deployment of the Beacons at the intersection, we conducted a study to investigate the usability and feasibility of Streetbit. We measured the prevalence of distraction among pedestrians and the effectiveness of StreetBit in alerting distracted users when they approached the intersection. This section discusses the details of the user study and the findings.

A. Participant Recruitment

We recruited 437 participants for this study. All participants were 17 years or older, crossed the target intersection frequently, and used either an Android phone or iPhone. All users installed our StreetBit application onto their smartphones. As the application runs in the background, the participants did not have to take any actions after installing the app. Participants were offered a monetary incentive of $50 ($25 at the beginning and another $25 at the end of the study) for their time participating in the study.

B. Study Protocol

We conducted a ten-week long study among the participants. The study protocol was reviewed and approved by the Institutional Review Board (IRB) of our university. The study was divided into three phases. (i) Phase 1: a three-week period during which participants did not receive any alerts from the StreetBit app (baseline phase). (ii) Phase 2: the next three weeks, during which participants received alerts from the StreetBit app if they were distracted when crossing the street (intervention phase). (iii) Phase 3: the next four weeks, a post-alert phase during which participants did not receive any alerts from the StreetBit app and we measured retention of learned behavior (post-intervention phase).

C. Demographic Details

At the beginning of this study, we recruited 437 participants. However, 385 individuals actively engaged in the study until the end and crossed the crossing regularly; 52 participants did not finish the study, and we classified them as inactive. 67% were female and 33% male. 78.2% were iOS users and the remainder were Android users. The participants were from a range of different age group categories, with a mean age of 24.9 years. Among the active participants, 27% were African American and 42% white. Table I shows the demographics details of the study participants

TABLE I.

Demographic details of study participants

	At least one crossing (n=385)	No crossings (n=52)	p-value*
Gender (%)
Female	256 (67.0)	31 (63.3)	0.6003
Male	126 (33.0)	18 (36.7)
Race/Ethnicity (%)
African American/Black	103 (27.1)	14 (29.2)	0.8046
Asian/Pacific Islander	70 (18.4)	9 (18.8)
Hispanic	22 (6.8)	2 (4.2)
Native American / American Indian / Alaskan	3 (0.8)	0 (0.0)
White	160 (42.1)	18 (37.5)
Other	22 (5.8)	5 (10.4)
Phone operating system (%)
Android	84 (21.8)
iOS	301 (78.2)

^*Estimated from a chi-square

D. Research Ethics

User privacy was maintained throughout the study by using anonymous and randomly-assigned IDs. No personal information was saved on our servers. All crossing event data were linked to user IDs. Moreover, because the application was activated to collect data only in the study intersection, data collection processes stopped whenever the user was out of the beacon’s range. All participants completed informed consent forms electronically. StreetBit’s mobile app asks for basic permissions to operate. Users must provide Bluetooth and motion permissions on both Android and iOS. The iOS application needs notification permission, while the Android application requires overlay screen permission.

VII. Findings

A. Study Survey

All 385 actively-engaged study participants self-reported that they crossed the target intersection frequently. Following the ten-week time period, we informally interviewed some users to inquire about their experience with the app. Two participants made the following comments regarding the first time they received alerts.

“I was going to ****** for lunch and texting my friend who was going to join me for lunch, and I got a warning that I was approaching the traffic intersection when I was 10 - 12 feet away from the signal.”

“I got an alert from my phone when I was about to cross the intersection as I was reading an email.”

Participants anecdotally reported after the study that the alerts were consistent, not annoying, and appeared at appropriate times. Both aural and visual alerts were produced, and those alerts matched the users’ activity (that is, aural alerts occurred when users listened to music and visual alerts when they were using apps that required looking at the smartphone). Figure 5 shows the post-survey questionnaire results, which generally indicate positive impressions about StreetBit from the users. From the post-survey questionnaire, about 70% of people thought that using the StreetBit app was worthwhile for their health and safety. More than 80% of users did not find SteetBit annoying and more than 69% of users would recommend StreetBit to others.

Fig. 5.

Responses to post-survey questionnaire among n=363 respondents

B. Interaction and Distraction

StreetBit identifies each crossing as an event and categorizes it as distracted or not distracted based on state. Certain circumstances exist when pedestrians approach an intersection but do not cross the street; rather, they take a left or right turn. We do not classify these situations as events, but, they do involve interaction with StreetBit. Thus, all events and nonevents are subsets of the interaction. There were a total of 36,240 interactions during the 10-week study, and among them 33,815 were identified as crossing events. StreetBit identified 25,124 events as distracted across the entire study, an overall 74.3% of all crossings Table II shows the interactions and crossing events.

TABLE II.

Total pedestrian interaction, crossing events, and turn left/right over ten-week study.

Phase	Total Interaction	Crossing Event N(%)*	Non-Crossing (Left or Right Turn) N(%)*
1st Phase (3-week)	12609	11597 (91.97)	1012 (8.03)
2nd Phase (3-week)	11815	11133 (94.23)	682 (5.77)
3rd Phase (4-week)	11816	11085 (93.81)	731 (6.19)

^*Total interaction is the base value.

The geography of the campus was such that most pedestrians had reason to cross the intersection rather than turn right or left without crossing. There are destinations like classroom buildings and the student center on corners, and fewer logical destinations accessed with right/left turns at each corner. The data shows the pedestrians crossed the intersection slightly more than 90% of the time in each phase. We defined each corner of the intersection by unique numbers like 1,2,3,4, which indicates the main beacons. StreetBit determines the directionality of the pedestrians by these numbers. For instance, pedestrians will receive signals from at least two main beacons if they cross one street in an individual event. StreetBit identified that pedestrians crossed one street 60.8% of the time. On the other hand, 39.2% of the time, pedestrians crossed two or (very rarely) three streets. In four corners, two are near the classroom facility, one is near the student center, and another is a park. Table III shows how often pedestrians crossed from the corresponding corners at the intersection. Pedestrians crossed more than 62% of the time from the two classroom corners. The least (15%) visited corner is near the park.

TABLE III.

Pedestrians’ directionality in terms of approaching corners. The percentage values show how many times pedestrians crossed from the corresponding corner.

Intersection Side	Phase One*	Phase Two*	Phase Three*
Side 1 (Mini Park)	14.70	16.68	15.73
Side 2 (Classroom)	39.44	39.75	38.52
Side 3 (Hill S. Center)	21.36	20.88	18.02
Side 4 (Classroom)	24.49	22.69	27.73

^*Data shows in percentage values. Hill S. Center = Hill Student Center.

StreetBit uses Google Activity Recognition (AR) API to identify pedestrian activity. Extensive pilot testing allowed us to determine whether the pedestrian was walking, running, or bicycling. Those who were driving in a vehicle were omitted from the analysis. Table IV presents the activity distribution during the study. Pedestrians walked when crossing the intersection nearly 70% of the time and ran 8% of the time.

TABLE IV.

User activity distribution.

Activity	Count (%)
No movement	12.64
Walking	69.73
Running	8.56
Bicycling	1.18
Unknown/Other	7.27

C. Post-warning Reaction

After receiving system alerts, participants clicked on them to acknowledge receipt 63.87% of the time in phase 2, which is when the app was actively functioning. On 36.13% of occasions, participants did not respond (Figure 6 (a)). Most important, 71% of the time, participants discontinued at least one rule, which combined identified them as distracted (Figure 6 (b)). Therefore, a Not Distracted state signifies that pedestrians switched off their phone screen / stopped interacting with the app / changed the phone position / stopped listening to music / stopped talking after receiving the warning from the system.

Fig. 6.

Study findings, chart (a) shows user response after getting alert in the phone and (b) shows the participant’s status after receiving the alert. (c) Participant’s phone “in use mode” based on the phone position during the study.

The system categorizes the phone position in the different regions, including phone in front of the users, portrait, landscape, in the pocket, etc. We classified these positions and orientation into two broad categories, phone is In-Use-Angle and phone is In-Not-Use-Angle mode. Figure 6(c) shows the findings of phone positions in different study phases. In phase 1 when the event starts, 49.04% of total events were Phone-In-Use-Angle mode. As there was no alert during this phase, just 4.98% of the time, pedestrians changed the phone position by the end of the corresponding events. In phase 2, at the beginning of the event, 49.92% of the time, phones were In-Use-Angle mode. However, after receiving the alert from StreetBit, the In-Use-Angle rate decreased to 26.18%. That means 23.74% of the event’s phone positions changed from In-Use-Angle to In-Not-Use-Angle during phase 2, when StreetBit actively issued alerts. In phase 3, the In-Use-Angle changed from 46.8% to 38.67%, suggesting there was some retention of behavior learned during phase 2 into phase 3. We emphasize that the In-Use-Angle and In-Not-Use-Angle are based on the orientation of the phone and may not be directly proportionate to pedestrian distraction. However, it does offer a nice proxy measure. For example, pedestrians might be distracted by listening to music when their phone is in their pocket, offering a false Phone-in-not-use measure.

VIII. Discussion

Our study indicates that the StreetBit app successfully recognized when users approached the target intersection, alerted those users through both visual and aural warnings, and elicited a change in behavior, as indicated by users clicking acknowledgment of receiving the alert, turning off their phone screens, and crossing the street while distracted less frequently. In phase 2, nearly 40% of distracted participants received an alert but did not acknowledge it during the crossing. We infer that the user was curious about the outcome, and they kept the application open until the end of the intersection instead of acknowledging it.

The beacon infrastructure was inexpensive. As each beacon retails for $25, we incurred a total cost of $350 to install the beacons. The installation materials were quite inexpensive as well (duct tape, plastic bags and wooden gardening stakes), and it took two people working together to install the beacons only about half an hour on pre-existing traffic signal and light posts, plus a few stakes. Hence, it is possible to set up the StreetBit system without requiring significant infrastructural support. The low cost of the beacons combined with the use of the comparatively cheap AWS-based server as the back-end demonstrates that installing such a system is quite affordable.

StreetBit offers tremendous potential to reduce distracted pedestrian behavior. There are comparatively few public health challenges in the United States and worldwide that are increasing in prevalence. Pedestrian injury rates are among them; pedestrian injury mortality rates have increased consistently and rather dramatically in the United States over the past several years. Distracted pedestrian behavior (as well as distracted driving behavior) is hypothesized to play a significant role in these increases [4]. Existing interventions to reduce pedestrian distraction through policy, behavior, road engineering, and/or technological intervention have achieved mixed results. StreetBit offers a novel and innovative strategy with the potential for broad dissemination after further testing, development and evaluation. It is grounded in behavioral theory, which suggests a direct and intrusive reminder alert may alter human behavior, break habits and instigate safety. The StreetBit app received positive feedback from users in the post-study survey. Around three-quarters of users said StreetBit helped them think more watchfully while crossing roadways and half reported that they changed their behavior while crossing the street. Finally, users in our study indicated anecdotally that the system was easy to use, not overly intrusive, and accurate in perceiving when they approached the intersection but not issuing false alarms.

Our system does not require any other communication infrastructure and does not store any personal pedestrian data. StreetBit is a standalone and small-size application that only receives the broadcasted signal and performs the required calculation locally. The user has full control not to send any data to others. In addition, Bluetooth 5.0 provides enhanced security communication which bolsters user privacy. Long-term visions and potential could include expansion to other road users (e.g., cyclists), integration of StreetBit as a standard smartphone feature, and integration of StreetBit with smart vehicles, foreseeing its use with the advent of autonomous vehicles operation and communication between autonomous vehicles and pedestrians.

Our study presented early-stage research to assess emerging technologies to alert inattentive pedestrians and hence has certain limitations. First, StreetBit identifies pedestrians using beacons in the targeted intersection. Though this will be functional in other intersections and designated street crossings, the current system will not work in mid-block or undesignated crossings. However, we envision that StreetBit or the successor of this technology could be adopted in pedestrian to vehicle or pedestrian to infrastructure in autonomous vehicle operations, which would alert in any part of the roadway. Second, StreetBit is unable to determine whether people remove earbuds or headphones from their ears to acknowledge the alert after receiving auditory alerts. In addition, we faced a challenge with the iOS alert layout. Specifically, we were unable to give the same kind of full-screen invasive alert on iPhones as we did on Android smartphones due to restrictions of the iOS operating system. StreetBit provides alerts using banner notification in the iOS platform. As the alerts in Android platforms come with a full screen, users must acknowledge the alert to move forward. In contrast, banner notifications in iOS come from the upper portion of the screen, and users can move forward without acknowledging it. We are working with persisting and system-level alerts to alleviate this issue in the future.

IX. Conclusion and Future Work

Injury to distracted pedestrians is a significant public health problem. In this paper, we have presented StreetBit, a low-cost and easy-to-deploy solution for urban environments. StreetBit can provide timely interventions to alert distracted pedestrians who are crossing an intersection. We implemented a real-life deployment of our system in a busy intersection and demonstrated the effectiveness, usability, and feasibility of StreetBit. The results of our pilot study suggest that our system was able to provide timely interventions to alert distracted pedestrians while they were crossing the intersection. After receiving the alert, 71% of the time users stopped engaging in their distracting activity on the smartphone. Also, 23.74% of the time, pedestrians changed their phone position after getting the alert. The post-completion survey indicates that about 70% of people found the StreetBit app was worthwhile for their health and safety and 69% of users would recommend StreetBit to others. In addition, more than 77% of users recommended the StreetBit app in other intersections. Currently, we installed 14 beacons at the intersection to obtain an accurate and timely warning. In the future, we will work to develop the system with fewer beacons. To encourage a habit of reducing distraction at traffic intersections for particular populations such as adolescents, we could implement a point-based game. In addition, we hope to perform a large-scale behavioral study to determine whether we can introduce long-term behavioral changes by enhancing awareness through StreetBit.