Category: Weekly Status Reports

This week I modified our backend server to be stateful in order to handle multiple clients. At a high-level, rather than just responding to parking requests, we now keep track of what spots have been requested and what spots are actually occupied based on DB results. This info is then periodically updated with set intervals or on new requests. Next week, I will update this v1 with a conflict handling mechanism as well as test its impl once we have built hardware modules for diff locations and mock different users.

This week I helped the rest of the team with field testing. The data and analysis is included in our weekly team report. At home, I continued to research how to enable multi-client views on our web-app. I found that the flask app takes a ‘threaded’ parameter which automatically handles multiple threads. Kanvi and I worked together on the view spots frontend design. I also thought about how to encode the locations of each sensor module in software. Next week, I will work with Neville to code up backend support for multiple requests.

This week was a super hard one for me because of S’n’S Carnival show preparations/performances/take down so I did not have that much time to work on our project. I made a plan for before class: to finish building the third module that was going a little haywire last week and then set it up to work with the other two sensors. I will flash the code on to it for our in-person demo tomorrow. My goal for the next two days is to update the timing in the code so that all of the readings can line up and send data at the same time./

This week I did some code cleanup/refactoring necessary to get our demo ready. This involved pushing to our prod instead of test database & changing query frequency to match the data upload cycle etc. In terms of new implementation, I modified our architecture to use multiple pub-sub clients via threads. For next steps, I will integrate this multi-client architecture with the webapp, likely via Flask asynchronous requests and locks on shared data structures on the backend server.

We have focused on building more sensor modules to scale up and test our algorithms more thoroughly. In the upcoming weeks, we will make sure the modules have portable power and casing. We will enable our system to handle multiple requests. Lastly, we will continue field tests while we scale up. We are on schedule according to our gantt chart.

I have been focused on getting better after catching the flu earlier this week. For our demo, I have included the geolocation, geocoding, and directions api from google maps in our webapp. In the upcoming weeks until final, I will also include the distance matrix api to help rank the available spots to the user. We will also have to figure out a way to redirect the user in the case the given spot gets taken before the user reaches.

This week we focused on integration testing for all our subsystems. We observed the sensor modules readings with objects placed in front of them. We also compiled libraries python programs sending the sensor readings to the cloud via mqtt. We developed the front end API and sent queries over the backend interface to test all of the functionality. We have power, sensors, IoT, AWS, and user-end components working together. Though we think this is great progress and awesome for our interim demo, we will be working hard in the coming weeks to get two sensor modules working for our final demo.

I made all the MicroPython scripts on the ESP8266 work! We have code that senses the distance from the ultrasonic sensor every 10 seconds for a minute, and then shuts down for two minutes. If the sensor detects something within 18 inches for at least ⅚ of the readings, then it returns that the spot is being blocked. We are able to post this to our AWS server using an MQTT client and have it stored in our database. Because one of our concerns was about testing the accuracy of the distance being reported by the sensors, I set up an informal test (as pictured below). It looks like our sensors are accurate to 250cm, which is far beyond what we actually need. Our batteries are still behind the receiving desk so Monday morning, we will plug in all of our modules and make sure we have everything looking good for the interim demo! Next week, I plan to make something for our sensors to rest on/attach to so they face the correct angle from the curb to a car. I am happy with the integration work we got done this week!

This week I wrote the backend service for Kerry. Thai involved python  programming our algorithm for finding the closest available parking area. It involved integration the dbms + Google maps python  api retrieve occupancy data and calculate distances between the users destination and parking spots and then returning a jspn payload to the front end flask endpoint. I also wrote some algorithm tests using mock data via python’s unit test framework. This week I will work on creating more API endpoints as we create our 2nd UI iteration.e.g returning periodic status updates on the availability of spots to the UI

This week I worked on learning about the google maps api. Together with Kanvi, we now have a google cloud account with our project. Specifically, we will be using the geolocation api to help give our users directions from their current location to their inputted destination. This api also helps us incorporate traffic information and more proper distance metrics (instead of just using euclidean distance). I will keep looking into this over next week. I hope to have tracking the user location on our web app for the interim demo. Lastly, we have successfully built our spot module. So, I will help the team with field testing tomorrow.