This week I continued to work on developing our web app. I edited some of the frontend designs that were given in the template I was using last week. Additionally, I worked on figuring out how to connect the backend of the webapp to the database where we are storing sensor information. I have coded up all the helper functions that are independent of the query process such as converting from address to latitude longitude coordinates, finding the distance between two coordinates, finding the top k closest parking spots, etc. My main goal was to find a way to query the DB by the end of the week. However, I still need to work with Neville tomorrow or in the upcoming week to finish the integration and start testing this part of the project. As for tasks for next week, I will be helping the rest of the team with field testing to make sure that the predicted 8ft distance between sensors works or if it needs to be tweaked slightly.
Author: mmandal
Mrinmayee’s Status Report 3/19
This week I spent most of my lab time working on starting a framework for our web application. Since I have no prior experience in web development, I found this week’s work quite interesting and challenging. I chose to use Flask as our framework. Additionally, I used an online template for the frontend as a starting point. I have explored creating endpoints, using form actions, and rerouting urls. I spent the most time implementing GET and POST requests, since we would need it when the user tries to input their location somehow on our app. Additionally, I have started to code up some of the backend functionalities. Next week, I hope to work with Neville and figure out how to query the database from the app. We hope to start integration next week. Here’s a quick view of what the web app will look like.
Mrinmayee Status Report 2/26
I did not get a chance to visit the lab this week due to the design presentations. According to our gantt chart, I was supposed to help Kanvi build the spot modules. Instead, I focused on working on pseudocode for how the back-end of our web app would look like. According to Pennsylvania law(https://www.dmv.pa.gov/Driver-Services/Driver-Licensing/Driver-Manual/Chapter-3/Everyday-Driving/Pages/Parking.aspx), the tires of the car must be within 12 inches of the curbside. We will use this metric to tune the ultrasonic sensors inside the spot modules. Since each module has its own nodemcu unit, each module will be able to communicate with the database independently. Moreover, we will be statically storing their arrangement on software via unique ids that indicate which modules are next to each other. Overall, the database will store information, such as availability, location of the spot module(coordinates), location city, unique id of module, and a “assigned user” attribute. Thus, when the web app receives a request from a user, who inputs their destination, we use geocoding (https://developers.google.com/maps/documentation/javascript/geocoding) to convert the address to coordinates, with which we can query the database. The city attribute can help index through data faster. We will use the google maps api to calculate the minimum distance (https://developers.google.com/maps/documentation/distance-matrix?csw=1). It is important that we find not one available module that is closest, but rather three modules that are next to each other, since they are spaced 8ft apart each. Furthermore, since more than one user will be requesting parking spaces, we will assign priority to requests based on the request timestamp and use a queue to process all requests. To make sure the app does not direct two users to the same parking space, we set the “assigned user” attribute for a module in the database when a spot module is technically available according to sensor information in the database but is already assigned to a user request. Everytime the module gets occupied and is no longer available, this “assigned user” attribute gets reset for future use. Next week, I hope to work with Kanvi and build the module, and work with the team overall to turn this pseudocode into code, changing details as needed.
Mrinmayee Status Report 2/19
This week I focused on finding sensor components to prepare for the design review. I settled on the HC-SR04 ultrasonic sensor after reading an article where the sensor is interfaced with a NodeMCU (https://randomnerdtutorials.com/esp8266-nodemcu-hc-sr04-ultrasonic-arduino/). The cost of each sensor is approximately at most $2, according to amazon pack options (https://www.amazon.com/Ultrasonic-Sensors/s?k=Ultrasonic+Sensors). Additionally, the sensor requires 5V for power, so I made the decision to leave the idea of solar energy for our initial prototype and use batteries instead. Some details about the different choices of batteries are explained in this article (https://diyi0t.com/best-battery-for-esp8266/). Next, I started to research points to consider when trying to detect a parked car. If the sensors are placed along the curbside in regular intervals of about 8 ft (about half the length of an average car), then whenever there are 3 sensors in a row that are not detecting any objects, it is guaranteed that there is enough space for a car. I will continue to think about the software vs hardware tradeoffs between having a one-to-one or one-to-many relationship between the nodemcu unit and sensors. Currently, I am on track for the tasks from the gantt chart.
Team Status Report 2/12
Our team prepared and practiced for our proposal presentation. Our design plans did not drastically change, it only became a bit more specific to save cost + accuracy. We decided to use as few ioT devices in the field as possible rather than our initial 1:1 model where an Arduino might be running in each spot. We also decided to use a time-series database as those are custom-made for periodic data. We are looking into the specific types of wireless technologies that would best fit the requirements of our system. We found that ultrasonic sensors are the best type of sensors for this project application, and PIR sensors should be used as an additional “verification” tool. Whether or not the final implementation includes both sensors will be determined after testing our system on the field and the data from cost + accuracy tradeoff. We are looking into using the Digi XBee 3 Zigbee 3 RF Module to communicate from the sensor to the larger database. Once we test how this works, we will be able to start making the physical sensor set up. Our biggest risk currently is being able to detect an available curbside parking spot with accuracy, even in inclement weather. We will continue to research and adjust requirements if needed in the future. Overall, no big changes have been made to the existing system design or schedule this week.
Mrinmayee Status Report 2/12
The beginning of this week was spent by me practicing and delivering our proposal presentation. As per our gantt chart, I spent the rest of the week researching sensors and a literature review of existing curbside sensor module systems. Specifically, I focused on ultrasonic sensors and tried to find out if it sufficiently provides all the information that we will need. After watching some videos (https://youtu.be/7a1fiUJtp_k) and reading some articles (https://www.avnet.com/wps/portal/abacus/resources/article/pir-and-ultrasonic-sensors-whats-the-difference-and-how-do-they-work/), I concluded that ultrasonic sensors would provide all the required baseline information, and the PIR sensors would help in cases such as detecting human/animal movement in front of our spot modules. Next, I proceeded to think about the technical requirements for weatherproofing our system. When snow is plowed throughout the city, curb side parking is almost never included. This could be one edge case that we might not be able to handle. Next week, I will focus on researching the best way to arrange the sensors on the curb to be able to detect cars with high accuracy.