Accident Quick Response System - AQRS

Hola Mundo!!! I am SoardRaspi and welcome to my blog. Actually, there are a few more welcoming lines I could have written, but that would just take up your time and probably make you lose your interest already. So without any further demora, let's get straight to the point.


I love making electronics projects and programming and try my best to apply these two skills to solve general problems that people face. One such project which I had made for one of my inter-school science competitions was the AQRS. I was in my 10th grade (15 years old). The idea was simple: there would be a box with three buttons; for the police, the ambulance, and the fire station. These units (from now on, we will refer to the box with buttons as units) would be installed on the roads .eg. highways, expressways, et cetera. Whenever an emergency occurs .eg. let's say a car accident, the other passing-by vehicles would halt and press the appropriate button from the box, to call the proper emergency service (in our example, the ambulance).


When the button is pressed, a message would be sent to the AQRS network which would reach the AQRS Operations Center. Once the message is received, the nearest available Ambulance would be prompted through the AQRS Saviour App which would be installed on a tab present in the ambulance. The ambulance would then reach the accident spot and perform the further ambulance protocol.


Phew!! A lot is going on, innit?! Lemme explain a little more in detail; part by part:

Part 1: The Accident

Imagine a person driving a car. It is raining heavily; the roads are slippery, and all the other vehicles are riding slowly, but our driver here has an expensive car and is trying to ride it fast, to probably show off. Guess what happens next; the car skids and topples. Friction wasn't enough and the road was not banked at the angle so that it could support the driver's speed (At this point, you may be thinking 'what the heck is SR writing'. Well, roads are banked a little so that they can support a range of speeds for vehicles. We are getting a little distracted here; this would be the topic for a different blog though). But that's not the point. The conclusion is that the accident happens. Now the other passing by vehicles come to a halt to check if our driver is alright; oh crap!! he's unconscious and bleeding (Yeah, I mean what else you'd expect). So, now they need an ambulance. They take out their cell phones and try calling the ambulance but then oh, there isn't any cellular network, so now what?!


Now here comes AQRS, the people would rush over to the nearest 'Unit', press the button and so now, the message has been triggered which would pass through subsequent units and reach the AQRS Operations Center. Now let's pause for a while and let me explain the network part. In my first version, I used the SIM900 A6 GSM/GPRS Module by AI Thinker and ublox NEO-6M GPS Module (yea yea, I know there is SIM900 A7 Module as well which has both GSM/GPRS and GPS features, but it was new then and I didn't have the time to implement it because the exhibition day was coming close). In version one, the idea was that when the button would be pressed, the message would be sent as an SMS to the Operations Center; the SMS would contain the service required and the location, and the rest you know (described above). The problem was that what if there isn't any cellular network? The whole system would fail then, won't it? Also, what is the need for the GPS module; anyways the unit would be installed on the roads, so the location of the unit isn't changing. One more problem, SIM Cards for each and every unit would be required. So there was a high installation and maintenance cost. This had to be solved!


So I made a second version. In this version, there was neither any GSM/GPRS Module nor any GPS Module. There were just three buttons and a LoRa Module (the SX1278 LoRa Module), and oh I almost forgot, I am using the Arduino UNO R3 (My favorite 😄). It is the base for almost all my projects. So yeah, the units would be connected through the LoRa Network of course. When the button is pressed, the message is passed from one unit to the other. Now in the networking language, we would call these units nodes. So reframing the previous sentence: When the button is pressed, the message is passed from one node to the other, until it reaches the parent node. Now if you have no idea of what nodes are and the different ways through which they can communicate, then think about it as the game of 'Passing the Parcel'. The message here is the parcel and the nodes are the participants. The only difference is that the parcel keeps on passing until it reaches the parent node. Once it reaches the parent node, the parent node would then send the message to the Operations Center through an SMS or maybe through a further LoRa network. In the second version, there is relatively low installation and maintenance cost. Now before you even think 'Hey SR, how about an ESP instead of LoRa', I would like to tell you that LoRa provides a longer range than ESP does. I mean, if I use an ESP (8266 or 32) it would be like you come across a unit somewhere and when you walk a few steps, you would come across another unit and that is unnecessary. BTW I could have used an XBee as well, but it isn't breadboard or perfboard friendly ¯\_(ツ)_/¯.


Now this may sound a little similar to Project OWL (IBM Call For Code 2018 Grand Prize Winner) but trust me, I had made my project way before I came across Project OWL (also, I respect Project OWL, it is just amazing!!!). So anyway, we are done with the networking part and now for the message part. So what does the message contain? The message contains two main parts; the location of the unit and the emergency service required. They get passed on from one unit to the other until it reaches the parent node which is then sent to the AQRS Operations Center. We are done with Part 1, now time for Part 2.


Part 2: AQRS Operations Center

Now for the Operations Center, I had made a webpage that I hosted online through Firebase Hosting (I have the Spark Plan, after all, who doesn't like free 😅). Unfortunately, I don't have a photo of the webpage but I will try my best to describe it. The webpage was a two-page webpage. The first page was the Login Page and the other page was the main page where all the prompts and the corresponding location of the emergency locations and ambulances would be visible. I used Firebase's Realtime Database to update the prompts. So whenever a button was pressed, a new prompt would immediately get added to the list of prompts. Basically, it was like Uber, the only difference was that the nearest driver (if online) would be prompted automatically. If the nearest driver isn't online, the next nearest driver would be prompted and so on. Now what is a prompt and what about the location of the ambulance?!


On my webpage, there were two vertical panels, for the panels I used the <div> tag. In the left panel, there was a map (I used Mapbox Map API. I will explain later why I didn't use HERE Maps API or Google Maps API or TomTom Maps API). The right panel displayed the prompts. Now I haven't yet answered the question, 'What are prompts?'. In my project, I define a prompt as a packet of information that contains 4 items. They are:

  1. Latitude of the location
  2. Longitude of the location
  3. The time when the service requirement was triggered
  4. The service which is required
Now when this prompt is received at the Firebase Database, the webpage reads that entry and displays it in the form of a round-cornered rectangular box. This rectangular box is also made up of the <div> tag which contains 5 <p> tags, 4 for the four items listed above, and 1 which shows the time passed since the moment the service requirement was triggered. A new prompt would get added to the list as soon as a new item gets added in the Firebase Realtime Database.

Now, why did I use Mapbox Maps API and not the other equally or more popular Maps APIs? I have explained both sides of the coin from my perspective. Views may vary from viewer to viewer and I appreciate your views in the comments.
  1. Views about Google Maps API: Although Google Maps API is widely used, both by developers and by non-developers (through Google Maps App) for navigation and other purposes. To begin with, I wanted something free and easy to use and without any complications. In Google Maps API, as far as loading a Google Map on your webpage is concerned, it is free. However, in my project, it was not sufficient. The webpage would receive the coordinates of the location and so, the Reverse Geocoding API was also required. As far as I have seen, Google Maps does not provide that for free. In my project, I would further require the Geofencing API as well and that as well is not free by Google Maps API. These are the only reasons why I didn't choose Google Maps API. If you are building a project which requires a maps API and are fine with paying for the Maps service, then I would say go for Google Maps API. It is reliable and has a huge forum in case you face any difficulties and wish to find a solution online. Also, it ihas been running for a very long time now.
  2. Views about HERE Maps API and TomTom Maps API: Another quite popular Maps APIs are HERE Maps API and TomTom Maps API. Now honestly, I have no solid reason for not using them. Its just that, when I was building my project, I was not able to easily find the documentation and code examples of HERE Maps nad talking about TomTom Maps, its wasn't popular then. I mean if I were to compare the popularity of these Maps APIs at the time when I was building the project, it would be something like: Google Maps > HERE Maps > Mapbox Maps > TomTom Maps. However, it seems that in these few years period, the popularity of TomTom Maps has increased more than that of Mapbox Maps and would say that now the order is something like: Google Maps > HERE Maps = TomTom Maps > Mapbox Maps. Again, this is what I feel and the views may vary from viewer to viewer. I would love to hear your views as well in the comments section 😊.
So now the prompt has been received and has been displayed on the webpage; what next? Now before I proceed, I would like to share something about the project day so that the upcoming content is understood. Whatever I have written till now was practically implemented by me. I mean all the webpage coding and making the circuit for the unit and programming it was physically done. Now the. competition was divided in different levels, so you would have to add something new to your project at each level. Now, my project got selected in the first level (the District Level, as they call it here) and I was pretty sure that it would get selected for the second level as well because the purpose of the project was important and the issue addressed by my project was important to be solved. And guess what, my project didn't get selected for the second level. I was heartbroken, first reason being I had lost and the second being I had never lost in any of my previous projects. Initially I thought that the project that did get selected for the second level was better than mine and was at peace with this reasoning. However, a few days later, I came across an article about the competition and that the National Level Winners were anounced. Curious I read the article to see what was the project which was better than mine and was astonished to find that the National Level Winner of the competition was a project which found a better way (or something like that) to make Herbal Dye. I was and still am astonished by the utter mediocracy that the competition supported. But anyways, I have moved on and whatever I am going to write from now onwards is what I had planned to do had I won the second level of the competition.

Now what I had planned to do further was to use AI and give higher priority to those prompts which have been remained unattended. So basically, the priority of a prompt would increase as the time passed since the moment the service requirement was triggered increases. But this doesn't sound something which is worth using AI right? I am you would probably say, 'Hey SR, just keep checking the time elapsed and then update the list of prompts by putting the prompts with highest elapsed time at the top of the list'. Well, you see, the time elapsed isn't the only parameter that should be considered. The other factors that need to be considered are :
  1. The nearest ambulance or police station or fire station to the emergency spot.
  2. The shortest route from that spot to the particular service provider.
  3. The traffic conditions on that route.
  4. The previous history of the area in which the emergency spot lies which enables us to classify the area as an accident-prine area.
Now the 4th point mentioned above, itself considers a few paramters:
  1. The frequency of accidents or emergency triggers occuring in that area.
  2. The extent of emergency (eg. if an accident has happened in the past then how bad was it; did the vehicle topple over or was it just a bump...)
And so, we require AI here. You see, the 2nd point listed above is a qualitative paramter and not a quantitative one. I mean you can't tell how bad an accident was on a scale of 1 to 10, right? So the parameters that should be considered here should be:
  1. The health condition of the patient(s) (if any) just after the emergency.
  2. How long did it take for the patient(s) to recover (if they did).
  3. The seriousness of the emergency (eg. in an accident, were the passenger(s) bleeding or unconscious or worse).
and so on...

So we are done with what happens in the AQRS Operations Center. Now its time for the AQRS Saviour App.

Part 3: AQRS Saviour App

Now what is the AQRS Saviour App. This is the app which would be installed on the cell-phones of the drivers of an ambulance or those of the police officials or those of the fire fighters. This app can also be thought to be installed on a tablet. This tablet would then be installed in the vehicle of the emergency service provider. Now this app would contain the option for the drivers to claim the responsibility of serving the emergency spot. Now these vehicles and drivers would be registered and verified for the AQRS Network based on how safely do the drivers drive the vehicle and how well-maintained are the vehicles. There isn't much in this app; just an Android Application which is connected to the PubNub Server for live update of the locatio of the vehicles so that they can be tracked from the AQRS Operations Center. Now this app also constantly check whether the vehicle has reached an accient-prone area, so that the drivers can remain alert and ready for dispatch whenever required. This could be done by dynamically adding new accident or emergency locations to the pre-existing geofences or by creating new ones and then comparing the location of the vehicles with the boundary of the geofences.

That was all!!! A lot wasn't it. I have tried my best to explain it in as detail as possible. I really appreciate if you stayed till the end and read my blog. I would love to hear your views or any suggestions from your side. Hope you found it useful and probably learned some new techniques to use in your next project or maybe just learnt smething new. Do let me know in the comments. Thanks for reading.

Regards,
SR.

Comments

Popular posts from this blog

Getting Started with Quantum Computing using Qiskit