Overview of crowdedness detection solution

In this unit, we present the system model of the proposed work. Further, we elaborate on the opportunistics sensing based approach for automatic bus-stop detection and crowdedness detection.

System Model

Following figure presents the system model of the proposed work. It consists of four modules: bus module, learning module, server module, and commuter module. In the following, we describe the functionality of each of these module and associated sub-modules.

Bus Module:

Bus module is an application developed for the Android based smartphone to track the buses in real time. It fetches the location records and publishes it to the server module periodically using the publish-subscribe mechanism based Message Queuing Telemetry Transport (MQTT) protocol.

The format of the location records is as follows:

Location Record = {'Latitude': 23.154383,
                   'Longitude': 72.6677121,
                   'GPSIndex': 100,
                   'Time': 1541163887000.0,
                   'Speed': 4.770268440246582,
                   'Accuracy': 4.699999809265137
                  }

where Latitude, Longitude are the location coordinates, GPSIndex is the index of the GPS Record. It varies from 0 to the length of record-1, Time is the epoch time corresponding to the location record update.

On server side, the GPS records are processed to detect the stoppages on the routes. Further, the real-time records are also processed for arrival time prediction. (please refer [1,2] for more details).

Learning Module

Learning module is an Android application developed to train the classifiers to be used for crowdsourcing commuters’ data. The application is installed in the data collection volunteers’ smartphone. It records the GPS traces and accelerometer data for the entire trip, including the bus-boarding and alighting events.

Data collection volunteers were asked to use the learning module during their journey, and records for luxury bus, mini-distance bus, car, and motor bike were collected. During the trips, no restrictions related to phone placement were imposed on data collection volunteers. However, we asked the data volunteers to mark the phone placement at the end of their trip. The recorded trip data is sent to the server module using bulk data transfer in an off-line mode.

Aforementioned, the data from learning module compries of the GPS records and accelerometer records. The format of the GPS record is similar to that of the GPS record obtained from the bus module. Further, the format of the accelerometer data obtained from the learning module is as follows:

AccelerometerRecord = {'Time': 1541163789631.0,
                       'Ax': -0.4213795,
                       'Ay': 3.6296098,
                       'Az': 8.90643,
                       'GPSIndex': 1,
                       'AcclIndex': 92}

Here, the Time is the epoch time corressponding to the accelerometer record, Ax, Ay, and Az are the accelerometer reading in the X, Y and Z axis. Further GPSIndex is the record index used to sync the GPS and accelerometer records and AcclIndex is the index of the accelerometer records.

Server Module:

Server module is the central part of the system. It receives the real time location update from the bus module, recorded trip data from the learning module, and crowdsourced data from the commuter module. It has several sub-modules that process these data. The server module then publishes the processed data to the subscribed commuter clients. In the following, we list these sub-modules:

Publish-subscribe broker: The publish-subscribe mechanism based MQTT broker coordinates the communication among all the modules.
Database: The server module stores the received information from the other modules into the database. It also stores the computed information of crowdedness detected inside the bus for different routes and the feeder bus schedule based on the crowdedness on various routes. The database is implemented using MongoDB database.
Model learning and validation: The stepping detector, transport mode classifier, and commuter activity classifier are used to opportunistically sense the condition for crowdedness detection (more details in subsection. These classifiers are trained and validated using the feature-set computed from the recorded trip data of the learning module. The learned model is then published to the commuter module using the MQTT protocol.
Crowdedness detector: It uses the reported changes in the commuter state to compute the crowdedness on the route. The commuter states are mapped to the bus-stops on the route. Further, it uses the commuter state between the pair of bus-stops for crowdedness detection.
Feeder bus scheduler: It uses the crowdedness information of various routes to schedule the feeder bus that would travel through the crowded segments of the route before the main bus. This would offload the crowd from the main bus. We aim to schedule the feeder bus such that it could travel through maximum crowded segments of different routes if the main bus schedule permits it.

Automatic Bus-stop detection

The automatic bus-stop detector uses the amalgamation of GPS records of bus module and crowdsourced commuters' record. The Density-Based Spatial Clustering of Applications with Noise (DBSCAN) [3] is applied on the GPS records to detect the probable bus-stops on the route. Furhter, the list of bus-stops is upgraded based on the bus boarding locations of commuters.

DBSCAN algorithm for stoppage detection

Introduction

Server module applies the data cleaning procedure on the GPS data of bus module to tackle with GPS outage. Further, the filtered data are applied to DBSCAN algorithm for stopagge detection. DBSCAN algorithm can detect the clusters of arbitary shapes.

Steps to find the cluster in a data-set

Find the points in the {\(\varepsilon\)} (eps) neighborhood of every point
Mark core points if more than minPts
Identify connected neighbor points with the core points
If the point is not in the neighborhood of core point mark it as a noise
Repeat step 1-4 for unvisited data point

Stoppage detection

A bus follows a stop-and-go pattern during its trip. When a bus is in motion, the periodic location records published by bus module are separated from one another by a certain distance. When a bus is stopped at a bus-stop or any other location (due to congestion or red signal at a junction), the location records are clustered together. In the following, the heuristics for bus-stop detection is presented.

Heuristics for bus-stop detection

The clusters smaller than 15 data-points are marked as speedbreak or bump. This clusters corresponds to slow movement of bus.
The remaining stoppages are due to the stoppage at the bus-stop, intersection or traffic jam.
The DBSCAN based bus-stop detector marks the recurrent stops in different trips as the bus-stop

Limitation of DBSCAN based bus-stop detection

This approach detect the recurrent stoppages at the congested road segments and intersection.

Crowdsourced commuters’ record for bus-stop detection

We observe that the bus-stop is the location where the commuters board a bus. By using the smartphone sensors opportunistically, the commuter module can be used for bus-boarding event detection. The data from GPS and accelerometer sensor of the commuter module are used for detection.

Discussion of possible approaches:

Commuter Module

Commuter module is an Android application developed for displaying the arrival time of the buses for the route of the interest to the commuter. The commuter module application subscribes to the route of the interest. Subsequently, it receives the arrival status and arrival time prediction on the subscribed route from the server module. The communication between the commuter module and the server module is based on the MQTT protocol.

Following figure \ref{figCommuterModuleApp} shows the user interface of the commuter module application. At the start of the application, it fetches the bus operating routes (see fig-(a)). The commuter can select the route of his/her interest. On selecting the route, the commuter module application fetches the bus-stops on the route and displays it on the screen (see fig-(b)). If the commuter wants to get the arrival status and arrival time prediction for the selected route, he/she may subscribe to the route by clicking Subscribe a route. On subscribing for a route, the commuter module fetches the arrival status of the ongoing bus trips. The commuter can also get the prediction for any ongoing trip (see fig-(d)}) by clicking the hyperlinked arrival status (see fig-(c)). The commuter module application is extended to crowdsource commuter’s data for crowdedness detection in an opportunistic manner.

Opportunistic sensing of commuters’ data

Stepping detector

Activation: When commuter queries for a bus by subscribing a route, a background service in the commuter module is invoked that fetches the current location of the commuter and compares it with the list of the bus-stops on the subscribed route. If the current location of the commuter is in the vicinity of one of the bus-stop, it is likely that the commuter is waiting for the bus. In this case, the commuter module activates the stepping detector.

Functionality: The stepping detector is used for identifying bus-boarding event. The intuition of using the stepping detector is that the commuter will take some steps to board the bus. The stepping detector remains activated til the commuter is found in the vicinity of one of the bus-stops. If the commuter module finds that commuter is no longer in the vicinity of the bus-stop, it stops the background service.

Transport mode classifier

Activation If the commuter module detects the stepping event, it fetches the GPS speed of the commuter to identify the mobility. In case the speed of commuter is higher than normal walking speed [4], it activates the transport mode classifier.

Functionality The commuter module can detect that the commuter is traveling using the stepping detector and movement speed of the commuter. Even though the commuter might be querying for the bus, he/she might have taken another mode of commute. The transport mode classifier identifies the mode of commute for accurate bus-boarding event detection. If the commuter module detects that the commuter is not in the bus, it closes the service to stop sensing the commuter data.

Commuter activity classifier

Activation The commuter activity classifier is activated if the commuter module detects that the commuter is inside the bus using the transport mode classifier.

Functionality The commuter activity classifier identifies whether the commuter got a seat during his/her journey or not by classifying the commuter as sitting or standing. Additionally, the commuter module uses the accelerometer data to detect whether the commuter has left the bus or not. If the commuter module detects that the commuter has left the bus, it publishes the commuter state during his/her journey along with the bus-boarding and alighting information to the server module using MQTT protocol. In the following, we describe the procedure used for identifying, recording, and publishing the commuter state during his/her journey.

Reference

1. Rajput, M. Chaturvedi, P. Patel, Advanced urban public transportation system for Indian scenarios, in: ACM Int. Conf. Proceeding Ser., ICDCN ’19, Association for Computing Machinery, 2019, pp. 327–336.
1. Rajput, M. Chaturvedi, Automatic detection of bus-stops and bus-crowdedness using crowdsourced data, in: 2019 IEEE Intell. Transp. Syst. Conf., ITSC 2019, 2019, pp. 740–745.
Martin Ester, Hans-Peter Kriegel, Jorg Sander, and Xiaowei Xu. August, 1996. A density-based algorithm for discovering clusters a density-based algorithm for discovering clusters in large spatial databases with noise. 2nd ACM conf. on Int. Conf. on Knowledge Discovery and Data Mining (KDD) (August, 1996), 226–231.
R.W. Bohannon, Comfortable and maximum walking speed of adults aged 20-79 years: Reference values and determinants, Age Age. 26 (1)(1997) 15–19.