Month: March 2026

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.