Team B2: PlatePatrol

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.

Risks

• Compatibility of different models with RPi OS environment. We will carefully test models’ compatibility on board at every step to prevent integration headache at the end.

Changes

• User Requirement: The dash cam should be able to process up to 4 frames per second, assuming we want to process at least 5 frames of a visible passing vehicle. This update is necessary because processing all 30 frames is an overdesign.

Schedule