Team status report 4/30

With all of the LED additions to the modules, recording all of our testing for the final demo video is going to be much easier! We have made plans for exactly what situations we are going to record to show off the many features of our project. We also are going to have a great set up for our actual demo space on Friday to show off our modules working in live time. 

Our web app also is becoming more robust, in both functionality and aesthetics. Our backend algorithms are working for spot coalescing and we are excited to show it all off together this week! This whole process has been incredibly fun and rewarding. We are proud of what we have accomplished.

Neville status report 04/30

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.

Mrinmayee’s Status Report 4/30

This week I worked on final updates for the web-app, made plans with the rest of the team for final testing, and started planning for the poster submission. After discussing with Neville, I worked on redirecting the user’s screen when their requested spot gets taken on their way there. I also realized that the view spots needed some changes. Rather than just showing the available spots, Neville suggested that I figure out a way to show taken spots as well. I will finalize these updates by the end of day Sunday. After Kanvi’s presentation, I created a testing plans document to figure out the last action items for our last testing session. Lastly, I set up a meeting to talk about the poster tasks and finalize our testing doc. Next week, I will be working with the rest of the team to get ready for the public demo, report, and video.

Kanvi Status Report 4/23

This week I got to flash code on to all of the extra modules I assembled. This allowed us to finally test how our database receives data from multiple modules and how the information can be displayed on our web app. Our voltage regulators didn’t come in the mail in time so battery power will still be something we test before our final demo, but I’m excited for our final presentation. I’ve been working on the slides to show all of our testing methods and making sure we properly explain how we have evolved our techniques because of results from testing. With presentations this week, I’m super ready to learn about everyone else’s projects and then what comes from the time we have during finals week to make our demo/video. Everything seems to be coming together!

Team Status Report 4/23

This week we focused on testing and getting results to share on the final presentation. We also aimed to finalize all important integration between subsystems. We are still working on getting the modules to be powered by batteries but plan to have it done by this week.

Next week, while Kanvi focuses on delivering the final presentation, Neville and I will start thinking about our miniature version for the public demo.

Overall, we are on schedule according to our gantt chart!

Mrinmayee Status Report 4/23

This week I started working on the second viewing mode for our webapp. This mode would allow users to get a visual idea of where and which curbside parking spots are available. I currently have a working version with mock data markers across the map. One thing that I plan on having done by Monday is making the markers dynamic so that they change size when the user zooms in or out of the map. I will also meet with Neville to connect this viewspots feature to the database which stores all the actual parking spaces. 

This week I also conducted usability testing for the webapp on 5 volunteers. The primary feedback was that they did not like typing in an entire address of their destination and would like a drop down that suggests addresses. Additionally, some testers wanted the map to update the starting point based on where the user drove. I might look into working on this in the next week if time permits. Tomorrow, Neville and I will work on latency testing to see the time difference between a sensor being occupied and it being reflected in the user’s request.

I will be helping Kanvi prepare for her presentation this week and am on schedule according to the gantt chart.

Neville 04/23 report

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.

Kanvi Status Report 4/16

I built 2 more modules this week and loaded all of our code onto them. We will order more hardware this week and build enough to make two full testing spots. I also worked a bit on the front end “view spots” page and figured out that it’s not too hard to draw a polygon onto a google map once we have defined coordinates for our modules. This week we will drop pins on a map wherever we decide the final locations of our modules and then load those coordinates into our database to finalize the mapping to those locations as well as the view spots webpage.

Team status report 04/16

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

Neville 04/16 report

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.