Author: cchima

This week I worked on noting key points for our slides and testing. In terms of testing gear,  I did some research on toy car dimensions that would work for our UC demo simulation and ordered appropriate sizes. In terms of code, I wrote an automated script to automatically act as Kerry users and call our backend routines. This allowed us to repeatedly run  various tests on its functionality while flexibly changing parameters e.g nun simultaneous requests,  sensor position etc.

There was a bug in the request formatting for our Gcloud DIstance matrix API. I fixed that this week. Apart from that, I’m helping Kanvi & Minu make sure they’re tasks are completed asap so we can live-test the software impl using many real sensors and frontend display. I will work on the presentation slides as this week approaches.

Our team focused on testing and verifying our designs this week through testing. We found that the range for ground clearance of cars is 7-9 inches, larger values for SUVs. We also found that the standard curb height is 6 inches (but varies around gutters, traffic separators and rolled curbs). From previous research, we know that cars must park within 12 inches of the curb. Next week, once our module encasings arrive we will begin packaging them as Kanvi builds more hardware modules. We are in schedule as per our gantt chart

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 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.

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 refining the original database query code to work for our app. It now takes the Mqtt data as input( as opposed to mock data )and uses an automated batch writer to store multiple sequentially arriving payloads to the DB. I also worked on spinning up container resources using AWS light sail to run our backend programs. I’ve written a containerizer script that obtains the needed files and runs our database dump entry point program. I will soon replicate that for the mqtt portion. This will I will work with Minu to complete coding up our backend detection algorithm

As a team, we are focusing on prepping for everything we will need done for our interim demo. The ethics assignment was an interesting thought exercise for us, as it helps us consider what exact data we should be collecting and potential misuses of our product. This guided Minu’sdevelopment of the web application, in both implementation translations and backend implementations. We want to ensure that  the UI is as simple and clear as possible, by translating our parking sensor data into the most digestible graphical format. We have a goal by the end of the next week to get data from our hardware module to our database and then to display something on our GUI. We are following our gantt chart so far and require no changes. Our biggest risk still remains the same issue of our algorithm using multiple sensors being able to detect the presence of cars accurately. We will perform field testing next week and come up with experimental results

Over the past two weeks I have worked on setting up our ioT communication pathway: specifically the mqtt message transfer & database dump. I have been able to set up necessary security permissions on our AWS account and configure DynamoDB and AWS ioT core to receive mock input records and messages respectively. An AWS console image is posted below & the code for this can be found in the dev branch of our github https://github.com/18500-Kerby/Kerby/tree/dev (It’s private because we thought it should be that way but if you’d like access to monitor our progress just say so). The next step iterating on this would be to i) Run experiments varying parameters e.g batch write throughput, TCP keep alive settings to analyze their effect on latency ii) Setup containers on Amazon LightSail to persist a job running the code for our communication pathway.

This week was about making decisions on our system design. Once we presented our design review, we continued to make revisions on our software. Having reduced time in the lab has been changing our schedule a lot, but we are hopeful to get working hardware with some programs flashed before we head home for spring break. Nevertheless, we worked on initializing the software-side components. We set up our github repo, provisioned our database, and started experimenting with Amazon’s python ioT & DB APIs. We also hope to translate Minu’s pseudocode into working algorithms to process collected data into “parking spot availability” information. The accuracy of this algorithm still remains our biggest concern.