Author: ziyaoz

Validations Done

• We conducted five in-vehicle tests to confirm that the car cigarette lighter reliably powers the unit for 30-minute sessions.
• In real-world testing, we deployed the dash cam in a vehicle for a 30-minute drive, during which the driver continuously called out the license plate numbers observed. During the 30-minute session, the driver identified 25 license plates while driving. All 25 were correctly detected by the dash cam system. In addition, the dash cam detected an extra 117 license plates that the driver was unable to observe while driving.
• To evaluate end-to-end system latency, we conducted 10 field tests and record timestamps at key stages. Average on-board detection latency is 123ms, OCR latency is 134ms, watchlist query latency is 469ms, and image upload latency is 7332ms.

Validations To Do

• In the lab, we will verify that the unit’s weight is less than 1.5lbs using a scale.
• We will time the initial setup process with five participants, ensuring that the average setup time is under 10 minutes.
• We will verify that the system’s startup and shutdown scripts execute within 30s of a power change through five simulated tests and five field tests, ensuring that no file corruption occurs during the process.
• We will test the opt-in switch functionality through 10 separate activation/deactivation cycles to confirm that the system reliably transitions its ALPR setting within 1s.
• We will verify that data at rest on the dash cam is erased upon shutdown, that non-match data on the server is deleted immediately, and that matched data is retained for 21 days.

Risks

• Since we are now in the testing phase, we find calculating our performance data quite challenging. It involves a lot of manual work as we need to look through footage to identify additional license plates that the dash cam caught.

Changes

• We modified the image uploading pipeline due to a hardware limitation with I2C bandwidth. Initially, we planned for two parallel threads on the dash cam: one for uploading chunked images upon server request and another for ongoing inference and license plate number queries. However, our hardware supports only one active I2C communication at a time, preventing simultaneous uploads. To address this, we now pause inference and plate number query during image uploads, resuming them afterward. With an average upload time of 500ms, the impact on real-time detection is minimal. This approach also makes sure we prioritize plates on watchlists, as the chance of detecting another watchlist plate immediately after is very low.
• We removed loop recording since it’s not the main focus of the project and it’s challenging for development and testing. Similarly, we decided to remove text formatting as current performance metrics looks good and it’s not the main focus of the project.
• For security compliance, we’ve added an API key to the dash cam communication APIs. This ensures only authorized devices can access the system (send detection query / upload images). We can implement rate limiting to prevent API abuse. If necessary, we can trace back activities to specific dash cams.
• Since we have limited bandwidth, we decided to cut the server load testing to conserve both budget and effort. This allows us to better focus on the integration and presentation.

Schedule

Risks

• Chunked image upload: The chunked image upload process is fairly complicated because we’re implementing it from scratch. While we considered S3 multipart upload, it wasn’t suitable for our file sizes. This approach introduces more moving parts, including chunk splitting, metadata tracking, individual uploads, and image assembly. While this complexity increases the potential for issues (e.g., missing chunks, incorrect assembly), we’ve developed a solid design for the image upload protocol this week (details in PR description) and got the basic structure in place. The focus next week will be on thoroughly testing and debugging to minimize risks and ensure reliability before integration.
• Power supply integration: Integrating our uninterruptible power supply (UPS) with car cigarette lighter power sources presents potential challenges, as the UPS currently operates reliably only from stable stationary power outlets. We have procured an adapter and an additional cigarette lighter wiring adapter specifically for testing purposes. Before any on-road implementation, we plan extensive lab testing to verify functionality, stability, and safety under simulated automotive conditions. This cautious approach aims to mitigate risks associated with unstable voltage, unexpected power fluctuations, or hardware incompatibility when connecting to a vehicle’s power system.

Changes

• GPS module: We changed the GPS module from Adafruit Automate GPS to Sparkfun GPS RTK according to Professor Tamal’s recommendation. 
• Image upload protocol: We realized that Blues Notehub’s 8KB file size limit requires us to use chunked uploads for images (~45KB). Originally, we implemented S3 pre-signed URLs for full image uploads, but that approach wouldn’t work with the size limitations. As a result, we’re implementing the chunked image upload process from scratch. 
• Partial match instead of message queue: Instead of implementing a message queue in the watchlist query server for asynchronous processing, we are prioritizing local filtering (partial matching) on the dashcam for now since this approach can more directly reduce bandwidth consumption and server load. By performing partial matching directly on the dashcam, we can simplify server-side operations, minimize data transmission, and enable faster, more efficient processing at the edge. The dashcam will locally store a synced watchlist and perform partial matches (e.g., comparing the first few characters of license plates) before sending only the relevant matches to the server. We still need to figure out the best way for the dash cam to sync with the server.

Schedule

Pics!

Risks

• We have identified a new risk related to our power source. During our weekly meeting, we discussed using a UPS to address the circuit issue in the dash cam system. We need to finalize which UPS solution to adopt, since it must be compatible with the RPi5 and ideally support power input from a car’s 12V cigarette lighter. We also decided that, as a fallback, we could mitigate sudden power loss by installing a manual switch to perform a clean shutdown. This ensures the RPi can complete its shutdown process and minimize the risk of data corruption.

Changes

• We re-evaluated the scope of our ALPR accuracy. Previously, we considered accuracy on a per-frame (per-image) basis, but through experimentation, we realized that assessing accuracy per car provides a more practical measurement. If an average of three images is captured for a single vehicle, we consider it a missed detection only when all three images fail to detect the plate correctly. Shifting to a “per-car” approach more accurately reflects real-world conditions and helps us measure performance in a way that aligns better with our actual use case.
• We updated the use-case requirement of ALPR accuracy from 90% to 80%. Based on experimentations and literature review, we find 80% accuracy to be a more realistic requirement for U.S. real-world dataset end-to-end accuracy due to license plates’ varied and complicated designs.
• We modified the image upload flow in the Central Server to use direct S3 uploads instead of routing through API Gateway. Initially, the system validated and forwarded image uploads via API Gateway and AWS Lambda before storing them in S3. However, this approach introduced inefficiencies due to API Gateway’s payload limits, added latency, and increased costs. To optimize performance, we implemented pre-signed S3 URLs, allowing dash cams to upload images directly to S3. When a license plate is detected, the watchlist query layer checks against a DynamoDB-stored watchlist; if a match is found, an AWS Lambda function generates a pre-signed URL and sends it to Blues NoteHub for direct upload. Once the upload completes, an S3 event triggers another Lambda function, logging the match in RDS and sending alerts via SNS. This change removes API Gateway as a bottleneck, improves system efficiency, reduces costs, and enhances security by restricting upload access to authorized clients with temporary URLs.
• We updated the Web App access layer in the Central Server by replacing an EC2-based backend with AWS API Gateway and Lambda functions. Initially, we assumed an EC2 instance would be more cost-effective, but upon further analysis, we found that law enforcement officers access the system from multiple geographic locations, requiring a more scalable solution. API Gateway now serves as the system’s entry point, with Lambda functions dynamically handling officer requests, interacting with DynamoDB for watchlist storage and RDS for match history retrieval. This adjustment improves scalability by automatically adjusting to traffic loads without manual intervention. While API Gateway introduces some cost, it remains minimal, estimated at $3.50 per million requests, and offers greater flexibility compared to EC2. Given that officer interactions are a small portion of total traffic, this approach balances scalability and cost-effectiveness while ensuring efficient and reliable access to the system.

Schedule

Special Questions

A was written by Andy, B was written by Vicky, and C was written by Christine.

• Global Factors: Our crowdsourced ALPR (Automatic License Plate Recognition) system is designed with global factors in mind to ensure its effectiveness and ethical use across different regions. One of the primary considerations is legal and regulatory compliance. Laws governing ALPR technology vary significantly across countries and even within regions. To address these concerns, we are implementing privacy-focused features, such as not storing license plate information and our data retention policy, ensuring compliance with different legal frameworks. Another key global factor is technological accessibility and infrastructure. The system needs to function reliably in various environments, from developed cities to other areas with limited connectivity. To accommodate this, we are designing edge-processing capabilities so that the dash cameras can locally process images and only upload essential metadata, reducing bandwidth usage. Additionally, the license plate recognition system is trained with real world data that will be optimized to work in diverse conditions, from bright urban environments to low-light or rainy conditions in rural settings.
• Cultural Factors: On one hand, PlatePatrol harnesses community empowerment and civic engagement by transforming everyday dash cams into a crowdsourced public safety network, resonating with America’s tradition of grassroots participation and innovation. On the other hand, the continuous collection and processing of vehicle data raise deep-seated privacy concerns and fears of surveillance in a society that values individual freedom, while historical issues of biased enforcement heighten anxieties about disproportionate targeting of minority and economically disadvantaged communities.
• Environmental Factors: The PlatePatrol system promotes environmental sustainability by leveraging existing dash cams instead of deploying new fixed surveillance cameras, reducing hardware waste and energy consumption. It utilizes AWS Lambda for serverless computing, ensuring resources are used only when needed, minimizing energy waste. Furthermore, by digitizing and streamlining law enforcement workflows, PlatePatrol reduces reliance on paper-based documentation, cutting down waste and promoting an eco-friendly approach to public safety operations.