Month: February 2025

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.

Risks

• A risk we anticipate is that the power source circuit or the UPS hat does not work as we desired. For example, the voltage dropped too quickly that is not long enough for the rpi to execute its shut down process, or the circuit overheats because of the capacitor. To mitigate this risk, we could
  • Add more element in our circuit, for example a cooling device
  • Add a button connected to the rpi for the user to manually control the rpi to execute its shut down process

Changes

• We originally planned to use DynamoDB for the web app backend since it’s easier to set up and works well for flexible data storage. But after thinking more about security, especially tracking access logs, we decided that a hybrid approach might be a better fit. We want to use RDS for better logging and auditing to improve security and accountability, while DynamoDB will handle personal watchlists for fast lookups. This balances performance with the need for structured access tracking. (updated web app database schema)
• During last week’s status report, we identified the need for a circuit to support the dash cam because the car’s power supply shuts off immediately when the engine is turned off, while our RPi5 requires additional time to properly shut down to prevent data corruption or potential damage. After designing a preliminary solution, we determined that incorporating a supercapacitor would be effective, as the shutdown process takes approximately five seconds. While researching, we also came across a pre-made module called the UPS HAT for the RPi, which addresses a similar issue. However, we would like to discuss in next week’s meeting whether our custom-designed circuit or the UPS HAT would be the better fit for our overall design. (UPS hat)

Schedule

Risks

• Power supply: RPi 5 needs 5V5A to function with peripherals and RPi 4 needs 5V3A. In-car usb ports can only provide 5V2A max. In-car cigarette lighter ports can provide 12V10A on average, but the supply is not stable and there can be current spikes. Market voltage regulators seem to be able to provide 5V5A max and 5V3A when at load. Our mitigation plan is to test if the power supply is enough for RPi 5. If not, we will switch to RPi 4.
• Proper RPi shutdown: If we directly connect the in-car power source to the RPi board, each time the ignition turns off, the board will be forced to shut down, which damages the board in the long run. Our mitigation plan is to research the capacitor and circuitry so that RPi begins the shutdown process when the ignition turns off.
• Edge computing: We updated our ML flow to do all the work on edge, and this means higher computational demands on dash cams, requiring optimization to ensure real-time processing. Our plan is to use lightweight models optimized for edge devices.
• Legal compliance & privacy risks: The system involves license plate recognition, law enforcement access, and data storage. Unauthorized access and misuse can lead to legal issues and breaches of privacy laws. We researched legal considerations but need to define the project scope—we cannot implement everything.
  • What we will support:
    • Controlled officer access with authentication & audit logs
    • Watchlist justification (officers must provide a case number to track plates)
    • Data retention policy (match records auto-expire after 90 days)
  • What is out of scope:
    • Full identity verification system for officers
    • Integration with external law enforcement databases
    • System-wide hacking/data abuse protections (beyond standard security measures)
• System scalability: The system needs to handle 314k concurrent requests, which can overwhelm the infrastructure if not optimized. For the central server design, instead of using a traditional EC2-based architecture, we’re leveraging API Gateway with Lambda and DynamoDB for scalability. To validate the system’s ability to handle high loads, we will conduct AWS-based load testing to optimize performance and identify potential bottlenecks before deployment.

Changes

• User requirement: We modified our processing speed requirement to capturing 2 frames of each legible license plate, given that these frames tend to capture similar results in field testing. This reduces the load on edge devices.
• To improve network connectivity and GPS tracking, we switched to using Blues Notecarrier and Notecard instead of other modules. Reasons for Change: 
  • Seamless cellular connectivity for real-time data transfer
  • Built-in GPS module for accurate location tracking
  • Lower power consumption compared to traditional LTE modules
• Based on faculty and TA feedback, we moved OCR processing from the central server to onboard dash cams to improve system efficiency, effectively reducing the number of frames that need to be transferred. This change reduces server load by distributing computation to edge devices but introduces an increased processing burden on the dash cams.

Schedule

Special Questions

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

• Public Health, Safety or Welfare Factors: PlatePatrol aims to improve public safety by providing law enforcement with real-time alerts on vehicles linked to crimes, enabling faster response times and aiding investigations. By leveraging a crowdsourced ALPR (Automatic License Plate Recognition) network, the system extends vehicle tracking beyond fixed cameras and dedicated patrol units. This has the potential to enhance law enforcement coverage, making it easier to locate stolen vehicles, track suspects, and respond to incidents more efficiently. However, it also introduces risks to public welfare. Without strict access controls, officers could misuse the system for unauthorized tracking. Additionally, if not properly secured, the system could be vulnerable to hacking, exposing sensitive vehicle and officer data. To mitigate this, we enforce JWT-based authentication with short expiration times, require officers to provide justification for adding plates to their watchlists, and implement data retention policies that automatically remove records after 90 days. These measures help prevent misuse, but the system still depends on law enforcement agencies to uphold ethical standards and enforce oversight. For real-world deployment, additional safeguards would be needed, but for the sake of prototyping, we would focus on the core functionalities of an end-to-end system.
• Social Factors: PlatePatrol will primarily target law enforcement officers and public safety agencies responsible for trying to prevent crimes taking advantage of track vehicles. PlatePatrol is designed to offer an affordable solution to take advantage of crowdsourcing to fix the gap in the modern day automatic license plate recognition system that plays a role in protecting community safety. Being able to be placed on normal vehicles can help with license plate detection in urban environments which are less covered by existing solutions and have a high vehicle density. PlatePatrol also provides regulations and options to promote responsible technology use and protect data security and user privacy. Overall, our system prioritizes public safety and responsible technology deployment, ensuring that law enforcement officers can effectively serve their communities while maintaining transparency and ethical data practices.
• Economic Factors: PlatePatrol addresses the economic inefficiencies and coverage limitations of traditional ALPR solutions by leveraging affordable dash cams and a decentralized data collection model. Current ALPR systems rely on specialized, high-cost cameras installed on law enforcement vehicles or fixed infrastructure. PlatePatrol reduces the dependency on government-funded installations while expanding coverage to a broader geographic area, including roads and regions that were previously uneconomical to monitor. From a production and distribution perspective, PlatePatrol (~$300) is significantly cheaper than traditional ALPR systems (~$50k), leading to a more distributed and economically viable model. On the consumption side, law enforcement agencies can access license plate data at a lower cost, improving operational efficiency and public safety without requiring significant infrastructure.