What is BusAmus?

As the Population density is growing, buses density is growing too. we think that bus lines frequency and routes should be decided dynamically and with fast feedback, rather than the current situation on which a bus path is determined by surveys.

The solutions of other private companies to this problem is to create an alternative transportation, such as Uber, Bouble or Scooters, We offer to fix the current infrastructure, integrated with the alternatives, the public transportation would significally improve.

This is BusAmus project:
We provide a device, installed on a each bus, the device detects the number of people during the whole ride, it sends the data to the cloud for analyzing and processing.


We can use this Big-Data for:

  • • Let developers (such as Moovit) use our insights and expose it to their customers (passengers), letting them choose the appropriate public transportation considering the density.

  • • Let transportation companies (such as Egged and Dan) use our density data in order to change their bus lines frequencies and routes according to the real density at the specific time, day and hour, this would optimize their service in sense of increasing loaded lines, and decreasing frequencies / scheduling smaller transits on sparse stations.




Logic

  • • Each telemetry of the Arduino device provides a sample of user phones, GPS location and the bus velocity.
  • • the Arduino device sniffs all 14 channels and sends the data (using bus Wi-Fi) to the cloud.
  • • The data is written to our database in the cloud.
  • • When the user (mobile device) asks for information of specific bus number and station, she gets density estimation produced by our mathematic algorithm.

Operation Scheme



Device

We passively track devices by processing in-air WiFi frames. We log a sample of those frames meta-data, and then perform statistical calculation to estimate density. The data that we are sending to the database consists of current timestamp and gathered in-air samples.

  • Device logic:

  • 1) Synchronize ESP8266 time and GPS location using GPS antenna.

  • 2) Scan the Wi-Fi channels to catch in-air frames.

  • 3) Prepare a telemtry packet of samples with gathered data, timestamp, location and velocity.

  • 4) Repeat.


Our board



Board's schematic sketch



Device Code

The arduino code consists of a few seperated open-source modules:

  • •WiFi_Sniffer – Allowing us to sniff Wi-Fi frames and build it into a data-structure

  • • Azure-ESP8266-HTTP (Arduino IDE provided tutorial) - Allowing us to queue a telemetry message onto Azure IoTHub, using HTTP.

  • • ArduinoJson - Parsing JSON responses from the server

  • • ESP8266WiFi - ESP8266 Wi-Fi advanced support

  • • TinyGPS - Allowing us to transform the UART serial messages of the GPS chip into Location and Time objects which are easy to query and extract info from



BackEnd

All of our server applications are written in C# in Azure Cloud services

We are using Azure tables to store all the data with the following structure




Each sample from a device consists of:
  • • GPS Location
  • • Velocity
  • • Time
  • • List of devices (MAC, channel and rssi for each device)





EventHub Trigger

MessageReceiver Function gets the JSON sent from device by EventHubTrigger and writes all the new data to the relevant Azure Tables, After obtaining requests with new MAC addresses we validate the data types insert the data, timestamp, and signal strength to the tables and return valid status codes for the device



Math Model

In order to predict the specific passenger density (instead of the active caught phones by Wi-Fi) we designed a math model.



    API for Developers

    Html request Trigger our calculations for developers, We give each transport application the ability to use our data with the following API



    Moovit example

    As moovit is one of the popular application for transportation we wanted to demonstrate how such applications can use our service.
    We designed a plugin that hooks moovit and simulating the implementation of BusAmus into Moovit,
    We listen to the specific bus line and station ID (including its GPS coordinates). Then we execute a request for our azure function, which calculates the density and present it to the users using AJAX (same user experience as in normal moovit usage)







    Bus Rides

    In order to test the whole project we conducted a few bus rides in line 189 (Dan) and 274 (Egged), This way we could test from end (device) to end (application) as long as the cloud part from inserting the data in real time and request the load which did all calculation in the backend.

Challenges and Solutions

The backend implements a mathematic model, which uses several features to determine the position of the devices
We worked hard to allow querying of 20-25 devices in the ESP8266, by eliminating memory leakages and inefficient memory usage, worked with smarter memory approaches. Currently, we believe that 15-20 devices per sample are enough to predict the real bus load, taking into account the Confidence (how many times a device is seen in different samples) and reception distribution.
We had a problem in the extension, because we were listening to all get requests of moovit and then reached our servers while trying to change the html view, It's not possible to do and the browser is not allowing to do in order to prevent XSS, For solving in we added permissions in the plugin, as long with origin CORS allowance from moovit domain to our servers.
ESP8266 device can’t connect to WiFi after it has connected already.
So we designed our chip code to gather information, build the sample output, connect once to the bus WiFi, send the information and reset itself. It poses some restrictions to our device.

About Us

This project was submitted by Alon T., Ron T. and Meni Y.
At the time of submission we were third year students in Tel Aviv Unitersity, Studying for B. Sc in Computer Science.
The workshop was guided by Sivan Toledo and Nir Levy
June 27th, 2019.