Author: dcabahug

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.

This week, the team made substantial progress toward a fully integrated end-to-end system. The most significant milestone achieved was completing the upload hardware-to-software-to-web-app pipeline: the dash cam now captures footage on the Raspberry Pi 5, transmits pothole detection metadata via the Blues Notecard over LTE, triggers a Cloud Function to receive and process the data, and displays the results live on the web app. This validates the core data flow of PotSpot across all three subsystems.

On the dash cam side, the team switched to the AI camera module as an interim solution, as the global shutter camera requires a lens to operate correctly. The software camera and inference pipeline were fixed, including a retrain of the YOLOv12n model for better detection accuracy, and the upload pipeline to the cloud backend was completed. Integration testing on real dash cam mock footage has also begun in preparation for the demo. On the web app, light and dark mode support was added, allowing users to select their display preference. The team is currently on schedule with the project timeline. Next steps include integrating live GPS polling into the detection pipeline and conducting in-vehicle testing by powering the Raspberry Pi 5 from the car’s cigarette lighter socket.

Project Status

This week, the team made significant progress across all three subsystems. The primary effort went toward completing and submitting the design proposal, which documents the full system architecture, component trade studies, and validation plan for PotSpot.

On the hardware side, Dylan successfully brought up the Raspberry Pi 5, confirming that the single-board computer boots correctly and is ready for peripheral integration. Concurrently, Dylan began fine-tuning the YOLOv12n model on the annotated pothole dataset sourced from Kaggle. On the backend, Gio completed the Cloud Functions implementation, establishing the storage-triggered ingestion pipeline that writes pothole metadata to Cloud Firestore upon successful image upload. Kevin completed working user authentication on the web app using Firebase Authentication, enabling role-based access for both regular drivers and city administrators. Next steps include integrating the GPS transponder with the microcontroller, continuing YOLO model training and evaluation, and connecting the frontend dashboard to live backend data.

Global, Cultural, and Environmental Considerations

A was written by Giovanni, B was written by Dylan, and C was written by Kevin.

Part A: Global Factors

PotSpot is designed primarily for Pittsburgh, but the underlying problem it addresses, degraded road infrastructure and the burden it places on drivers and municipal governments, is a global one. Pothole damage affects drivers in virtually every country, and the manual reporting systems that currently exist, such as Google Maps and Waze, impose the same friction on users whether they are in Pittsburgh, London, or Nairobi. The crowd-sourced, hands-free architecture of PotSpot is not inherently Pittsburgh-specific. The core system is deployable anywhere with LTE coverage, which covers the vast majority of urban and suburban areas worldwide. For users who are not technologically savvy, PotSpot is designed to minimize the interaction burden: after a one-time setup taking under ten minutes, the device operates entirely autonomously. There is no app to navigate, no button to press while driving. This makes the system accessible beyond technically literate populations. That said, the system does currently assume access to a vehicle with a cigarette lighter socket and reliable LTE connectivity, which may limit applicability in regions with poor cellular infrastructure or lower rates of personal vehicle ownership. These are factors the team has considered and that future iterations of PotSpot could address through offline buffering and alternative connectivity options.

Part B: Cultural Factors

Cultural factors play an important role in how PotSpot would be received and used across different communities. In the United States, driving culture is deeply embedded in daily life, and the frustration of vehicle damage caused by potholes is a widely shared experience that transcends demographic lines. PotSpot taps into this shared concern by offering a passive solution where drivers do not need to change their behavior or adopt a new habit to contribute to the platform. However, cultural attitudes toward data collection and surveillance vary significantly across communities and regions. PotSpot’s dash cam continuously records road footage, and while the system is designed to process and discard this footage locally rather than transmitting raw video, some users may be uncomfortable with a device that records their surroundings at all times. This concern is particularly salient in communities with heightened sensitivity around surveillance, whether due to cultural values around privacy or historical experiences with monitoring. The team has addressed this partly through the edge-processing architecture, which ensures that only pothole metadata, not video footage, is ever transmitted to the cloud. Transparency in how the system handles recorded data will be important in building user trust across diverse cultural contexts. Additionally, the administrative role assigned to city government in PotSpot assumes a civic structure where a designated municipal authority is responsible for road maintenance and repair, a structure that is common in the United States but may differ in other governance contexts where road maintenance is privatized, community-managed, or handled at a different level of government.

Part C: Environmental Factors

PotSpot’s environmental footprint is modest relative to the scale of the problem it addresses. The device draws power from the vehicle’s existing electrical system, adding a small but non-zero load during operation. The Raspberry Pi 5 draws approximately 11–12 watts at peak, which represents a negligible increase in vehicle fuel consumption or battery draw. The system uses a rechargeable battery as part of its UPS, and the team has selected components with weight and power efficiency in mind throughout the trade study process. On the broader environmental side, PotSpot contributes to a meaningful environmental benefit: by enabling faster identification and prioritization of pothole repairs, the system can help reduce vehicle damage and the associated resource costs of repairs. More importantly, potholes contribute to vehicle misalignment and tire wear, which increase rolling resistance and reduce fuel efficiency. A road network that is better maintained through tools like PotSpot would, at scale, reduce fuel consumption and emissions across the vehicle fleet using those roads. The system’s cloud infrastructure runs on Google Cloud Platform, which has made public commitments to operating on carbon-free energy. While the team has not conducted a full lifecycle environmental analysis of the hardware components, the relatively low bill of materials cost and component count suggest a limited manufacturing footprint compared to purpose-built municipal sensing infrastructure.