This week I helped prepare the final presentation. Additionally, I helped finalize what our product would look like and do real work testing. We also ran survey testing for the accuracy of the pothole severity and also user testing. Our progress is perfectly on schedule and we will be good to be complete in time. In this week, I will be working on the final demo and final video
Dylan’s Status Report for 4/25/26
This week, I worked on the final presentation as well as making final adjustments for the final demo. We are on schedule and next week is the final demo.
Some new tools that I continued to work with were the Raspberry Pi and the YOLO computer vision framework. Some new knowledge that I gained this week was learning how to fine-tune model performance based on test results and understanding how different environmental conditions like lighting and texture affect detection accuracy. My learning strategies included analyzing test outputs, reviewing documentation on model tuning, and hands-on iteration with the system to improve reliability before the final demo.
Team Status Report for 4/25/2026
Currently, the only significant risk that could jeopardize the success of our project is just not doing the final assignments. To mitigate these risks, we are starting working on these assignments days early and with a clear focus on our project. In terms of making changes to the existing design of the system, we have continued with our current system and are in testing phase. This week, we have been focused on completing our testing phase and then started to work on final assignments.
Here are the specific unit test and overall system tests carried out on our system:
1. Computer Vision Detection Unit Tests: We tested our YOLO-based pothole detection model using different sample road images and videos. These tests ensured we are able to accurately detect potholes and assign severity on them against our own labeled data sets. We learned that our model performs better when the potholes are clearly visible and centered in our frame but confidence levels dropped when the lighting/texture was off.
2. GPS Metadata Parsing Tests: We solo tested the GPS data from both the Raspberry Pi and Notecard pipeline such that it was able to correctly attach GPS latitude and longitude to each pothole detection. What we learned is that GPS detection is a more fragile part of our system. When we tried testing inside, the module could not detect any location and then once we moved outside it was finally able to see a satellite and send coordinates.
3. Backend API Unit Tests: We tested the backend endpoints responsible for receiving pothole detection data and writing to Firestore. These tests checked whether the API correctly handled different types of requests. These tests were mainly for error handling. We learned that the backend needed strong validation because the edge device and cloud upload system may sometimes send incomplete or inconsistent data.
4. Scalability Tests: In order to test scalability for our Firebase DB, we utilized their built-in Firebase Local Emulator Suite to run 1000+ tests for simultaneous requests. What we found is that our Firebase DB can handle 9000 requests in around 2 minutes with a 100% success rate. The average duration for the Cloud Function upload was 236.87 ms.
5. Frontend Map Display Unit Tests: We tested whether pothole data retrieved from Firestore appeared correctly on the user-facing map. These tests checked that each pothole marker was placed at the correct GPS location and displayed the correct severity. We learned that the frontend needed to handle empty or incomplete data gracefully instead of assuming every pothole record was valid.
6. Overall System Testing: After unit testing each individual component, we did end-to-end field testing by taking a user and allowing them to drive around Pittsburgh and we found that the core pipeline worked. The computer vision model could detect potholes and then send all metadata to Firebase to be visualized on the frontend.
Kevin’s Status Report for 4/25/2026
This week, we focused on unit testing and user testing our product against different test cases. I contributed to unit testing our web app and how it performs against scaled data inputs. I had to determine how our web app would be able to handle the scale of the number of potholes in Pittsburgh. I also contributed in field user testing our product. We needed to find out from different users how hard it would be to set up our product and then determine how minimalistic invasive to the user’s driving experience. This progress is on track with what we scheduled. In the next week, I hope to help wrap up all of the final tasks needed for this class including the final poster, demo, and report.
Team Status Report for 4/18/2026
This week, the team made strong progress across hardware integration, software development, and system testing as we move into the final phase of the project. Overall, we remain on schedule and are preparing to complete final testing and deliver our demo next week.
On the software side, the computer vision model was fine-tuned using real pothole data, improving detection accuracy. A live dashcam preview feature was also implemented to support real-time debugging and validation of system outputs. In parallel, backend and cloud infrastructure work continued, including development and debugging of cloud functions and database integration. Field tests were conducted to verify that data from the dashcam pipeline is successfully transmitted, stored, and displayed in the web application.
On the hardware side, significant effort was devoted to integrating and debugging the GPS transponder with the Raspberry Pi and Notecard/Notehub system. While initial connectivity worked directly with the Raspberry Pi, additional challenges arose when integrating with the full hardware stack, which were actively debugged and resolved. The vehicle charging component was also completed, ensuring reliable power delivery within the car environment.
The team also collaborated on final presentation materials and conducted user testing to validate system functionality and usability. These efforts provided valuable feedback as we refine the system for the final demo. Looking ahead, the team plans to finalize hardware packaging (including the dashcam enclosure), complete remaining testing, and prepare polished demo materials.
Throughout the week, team members gained experience with tools such as Raspberry Pi, GPS transponders, Notecard/Notehub, Google Firebase, and Google Cloud Run Functions. Key learning outcomes included deeper understanding of embedded and distributed systems, cloud backend development, and the importance of consulting official documentation when working with hardware. The team also emphasized hands-on experimentation and iterative learning, enabling rapid progress while maintaining system cohesion.
Overall, the project is progressing well, with all major components coming together in preparation for final delivery.
New Tools, Knowledge, and Learning Strategies
To accomplish these tasks, the team had to learn several new tools and concepts across both hardware and software domains. These included working with Raspberry Pi systems, GPS transponders, and Notecard/Notehub hardware, as well as cloud technologies such as Google Firebase and Google Cloud Run Functions. On the software side, the team gained experience in deploying and debugging cloud-based backends, handling real-time data pipelines, and improving machine learning model performance. On the hardware side, the team developed a deeper understanding of embedded and distributed systems, particularly how multiple components communicate and operate together in real time.
To acquire this knowledge, the team relied heavily on hands-on, iterative learning. Much of the learning occurred through direct experimentation, building, testing, encountering issues, and refining solutions. Team members frequently consulted official documentation for hardware and cloud services, especially when troubleshooting integration issues. Informal learning strategies also played a key role, including reading forum posts, searching for solutions online, and watching tutorial videos to quickly understand unfamiliar tools and concepts. Additionally, the team adopted a “learn while building” approach, allowing members to make progress on the project while simultaneously developing the necessary technical skills.
Overall, these learning strategies enabled the team to quickly adapt to new technologies, overcome integration challenges, and successfully bring together all components of the system as the project nears completion.
Dylan’s Status Report for 4/18/2026
This week, I fine-tuned the computer vision model on real pothole data to improve detection accuracy. I also added a live preview of the dashcam feed for development and debugging purposes, allowing real-time visual verification of the system’s output. I contributed on the final presentation and helped conduct user tests. We are all on schedule and we hope to finish all testing and demo next week.
Some new tools that I got introduced to were the Raspberry Pi (RPi) and GPS transponders. Some new knowledge that I have learned is more about distributed and embedded systems, specifically how our hardware components communicate and work together in a real-time pipeline. My learning strategies included hands-on experimentation with the hardware, reading online documentation and forum posts, and watching tutorial videos to get up to speed on unfamiliar components. This helped me move quickly while still understanding how each piece fits into the larger system.
Gio Status Report for 4/18/2026
This week, I continued to work on the GPS transponder with Kevin and debugged the hardware connections. We started by just connecting it on the RPi, but then had some small issues connecting it onto the Notecarrier. I completed the charging portion of our project which connects our product to the car reliably. I worked on the final presentation and helped conduct user tests. We are all on schedule and we hope to finish all testing and demo next week.
Some new tools that I got familiar with was Google Firebase, Google Cloud Run Functions, Notecard, RPi, and GPS transponders. Some new knowledge that I have learned is how to write cloud systems and debug problems in our cloud backend. This mainly includes writing the Cloud Functions, but I also learned how to reset the triggers for these functions. This was especially important when we accidently deleted our database causing our functions to be pointing at a invalid DB instance. The learning strategy that I learned is how to properly plan without needing everything laid out. This allowed me to move fast while ensuring that the different parts of our project worked.
Kevin’s Status Report for 4/18/2026
This week, I continued to work on the GPS transponder and debugging the hardware connections. We initially got it to work when connected to the RPi, but we needed to have it connect to the Notehub that is on top of the RPi. I did further web app for the entire pipeline by doing field tests with our dashcam and seeing if it shows up in our DB and our web app. I am also working with the team to complete the final presentation slides/information. The progress is on schedule and we are currently in the final phase of our project. In the next week, we hope to finalize the box of our dashcam and then start working on final demo materials.
Some new tools that I got familiar with was Google Firebase, Google Cloud Run Functions, Notecard, RPi, and GPS transponders. Some new knowledge that I have learned implementing this product is to check official documentation of hardware since that was the main point of challenge for me. The learning strategy that I gained doing this project is to learn while implementing. This allowed me to learn what I did wrong and what I needed to fix to do it right.
Dylan’s Status Report 4/4/2026
This week, I mainly worked on the computer vision (CV) side of PotSpot. I spent time retraining the model on better quality data to improve our detection accuracy. Unfortunately, due to family concerns, I was unable to complete testing this week. In the next week, I hope to finish CV testing and run benchmarks on our test data to verify our model’s performance. This is on schedule with our proposal.
In terms of testing, I plan to benchmark our CV model using our collected test data to verify detection accuracy and severity classification. Once our full pipeline is robust enough, I want to validate that what our model detects in the field matches real-world conditions, and cross reference our detections with manual in-person comparisons.
Gio Status Report for 4/4/2026
This week, I worked on testing. I finished writing all the test files needed to test latency, with my Firebase Emulator suite. I also worked on making sure that the GPS could be properly connected and making sure our interim demo would be good. Additionally, me and Kevin spent some time making sure that everything we want to send via the Notecard, could be sent. Initially, we realized this was not the case, but after trying different ways to send data, we found a solution. This week I want to test our backend as well as full plug in the RPi.
This week, I worked on the verification of our backend. I wrote some unit tests for our backend functions as well as ran a load test on that. For this load test I ran a burst of requests on a cold invoke, meaning there was no prior functions running. In this 2 minute and 30 second test, I had 8500 upload requests to simulate a high traffic scenario and we had an average of 236 ms upload duration which was well under our time. Even with higher loads then, we will be under our requirements for upload speed.