None of us had worked with embedded systems before so we had to think a lot before taking up this course. 

At first, we had been allotted a different project, name “Person Counting using Radar”. We had to basically take radar data and then apply ML algorithms to it to estimate the number of people in a room, along with the their movements and variations. However, after about one month of working on this project, we realised that the proprietary BumbleBee radar that we were using kept giving bad samples that couldn’t be used for support vector algorithmic approaches. After repeated tries and attempts to make it work, we realised that we had come to a standstill and so we were given the new project.

This added a major challenge since we had lost about 1.5 months of work and we had to complete an altogether new project in just 2.5 months. We spent a lot of time every week to meet the requirements of the project and give our best.

Another major challenge was that we weren’t using commercial beacons for BLE advertisement of the stops. Instead, we had converted the Raspberry Pi into an EddyStone URL Beacon. However, Google has discontinued the support for Eddystone URL Beacon in November last year, and has moved to newer forms of beacon technology that the Pi doesn’t support. And so it took us an immense amount of time to find valid documentation for receiving Eddystone URL data on the Android application.

One more challenge was to tackle the problem of multiple buses and multiple users. We had to make improvements to our code and front end design to add this functionality. 

While making the server, we required a public IP for an IIT Delhi virtual machine so that the server can be accessed without the need for IITD WiFi. However, we couldn’t obtain permission for the public IP due to security reasons and so we had to use an external server for posting and requesting data.

We also had a minor setback when one of our Raspberry Pi’s was accidentally shorted and started malfunctioning. That Pi contained some valuable data that hadn’t been backed up yet and so it took us a while to recover that data but fortunately we were able to do so.

Overall, this project provided us with many challenges and situations where we felt lost and had low hopes. But this was a huge learning experience since we got to deal with real-world technical problems that we will have to face in the future in a tech company or startup.

On the server side we have created a website which can be used by the bus operator to view the live location of any bus he wants. We have also added the functionality of assigning bus routes to the buses so that the system can be more dynamic and the bus operator will also have the option to change bus routes of any bus he/she wants. We have tried to make the system robust so that any number of busses could be added and the functionality still work.

Working:

We have created a simple website that is hosted on github. It is an easy to use where the operator just needs to login and then all the functionality are available to him/her. The live location functionality works as follows:

1. The raspberry pi continuously send the latitude and longitude data which it gets from the GPS module to the server using a simple messaging script created on Python.
2. When the server receives the data it uses the coordinate values to display on the map using Google Map API.
3. Whenever the server gets the data it updates the marker to view real time location of the bus.

Other functionality that we have provided is  bus route assigning it works as follows:

1. The operator has to select the bus and the route that he needs to assign to that bus.
2. The the server sends the details of the route such as stop names , location of stops etc. to the bus module.
3. Then the bus module on receiving the details updates the route on it’s script and start following the new route.

Challenges:

There were some challenges that we faced like sending data from bus module to the server , updating the marker on the Map in real time but the main challenge that we faced on the server side was making the functionality robust for multiple busses. Displaying the live location of a single bus easy but for multiple busses it was a problem as if all the busses use the same channel to communicate then the server won’t be able to decide which bus coordinate are these and also the channel will get overcrowded with request and our system will become slow. To solve this problem we made different channel for different busses so the there is no overcrowding of request and our system works seamlessly.

None of us had worked with embedded systems before so we had to think a lot before taking up this course. 

At first, we had been allotted a different project, name “Person Counting using Radar”. We had to basically take radar data and then apply ML algorithms to it to estimate the number of people in a room, along with the their movements and variations. However, after about one month of working on this project, we realised that the proprietary BumbleBee radar that we were using kept giving bad samples that couldn’t be used for support vector algorithmic approaches. After repeated tries and attempts to make it work, we realised that we had come to a standstill and so we were given the new project.

This added a major challenge since we had lost about 1.5 months of work and we had to complete an altogether new project in just 2.5 months. We spent a lot of time every week to meet the requirements of the project and give our best.

Another major challenge was that we weren’t using commercial beacons for BLE advertisement of the stops. Instead, we had converted the Raspberry Pi into an EddyStone URL Beacon. However, Google has discontinued the support for Eddystone URL Beacon in November last year, and has moved to newer forms of beacon technology that the Pi doesn’t support. And so it took us an immense amount of time to find valid documentation for receiving Eddystone URL data on the Android application.

One more challenge was to tackle the problem of multiple buses and multiple users. We had to make improvements to our code and front end design to add this functionality. 

While making the server, we required a public IP for an IIT Delhi virtual machine so that the server can be accessed without the need for IITD WiFi. However, we couldn’t obtain permission for the public IP due to security reasons and so we had to use an external server for posting and requesting data.

We also had a minor setback when one of our Raspberry Pi’s was accidentally shorted and started malfunctioning. That Pi contained some valuable data that hadn’t been backed up yet and so it took us a while to recover that data but fortunately we were able to do so.

Overall, this project provided us with many challenges and situations where we felt lost and had low hopes. But this was a huge learning experience since we got to deal with real-world technical problems that we will have to face in the future in a tech company or startup.

Disability is God given,

Handicap is man-made.

above the stairs at National Association for Blind Delhi

Visually impaired people regularly commute through buses, just like the rest of us. However, they face a huge trouble in locating the bus that they want to board, and also getting off at their required destination stop.

Assistech IIT Delhi has already been working on a solution for boarding the bus, named OnBoard. (http://assistech.iitd.ernet.in/onboard.php). However, there wasn’t a proper solution for getting off the bus till now. The buses have speakers to speak out the upcoming stops but they are mostly non-functional or play music instead of the announcements.

We are four students of IIT Delhi pursuing B.Tech in Electrical Engineering. As part of the Embedded Systems course COP315, we have developed a solution that allows easy de-boarding for the visually impaired. We call it “Deboard”.