Christine’s Status Report for 2/22

🟢 Progress This Week

Design Presentation Preparation

    • Finalized slides for the Design Review Presentation and helped Vicky prepare.

Database Design

  •  Designed the database schema for both the central server (DynamoDB + RDS) and web app backend.
  • Defined table structures for:
    • Global watchlist (DynamoDB)
    • Match history & notifications (RDS)
    • Officer authentication & access logs (RDS)
    • Personal watchlists (DynamoDB)

Central Server Implementation

  •  Set up API Gateway endpoint for /detections, forwarding plate detections to an SQS message queue.
  • Configured DynamoDB tables (global watchlist).
  • Set up RDS tables for match history & notifications.
  • Added Lambda function to listen to SQS, process messages, and query the global watchlist for matches.
    • Notification back to dash cam will be integrated in the future after we know more about Blues.

🔜 Next Steps

  • Design Report (⏳ Priority)

    • The big focus for next week.
  • Web App Backend – Authentication
    • Set up backend folder structure (microservices-based, MVC pattern).
    • Implement authentication (Auth controllers, models, DAO layer).
    • Ensure REST endpoints for authentication are accessible for the frontend.
  • Continue Implementation for Central Server
    • Test end-to-end for POST /detections.
    • Start implementing the match upload layer.

📌 Overall Status

Currently on track.
Making good progress, but next week will be heavy on implementation and documentation.

Vicky’s Status Report for 2/22

Personal Accomplishments

Progress

My progress is on schedule.

Schedule

  • Single-board computer bringup and testing
  • Camera module bringup and testing
  • ML models deployment and benchmarking
  • Design report

Team Status Report for 2/15

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.

Andy’s Status Report for 2/15

This week, I focused on finalizing the Web App API design with Christine and discusses together with Vicky. I reviewed the initial API structure and refined the endpoints to align with the backend logic and data requirements. The finalized API includes endpoints for:

  • Managing watchlist entries (Add, Remove, Retrieve).
  • Handling authentication & authorization using JWT-based security.
  • Retrieving real-time alerts for law enforcement officers.

I also finilized the tech stack for the web application implementation and designed the block diagram for the web application:

I worked on the initial version of the frontend using React.js + TypeScript with Ant Design. The draft includes:

  • A login page with JWT-based authentication.
  • A dashboard that allows law enforcement to view and modify the police officer’s individual watchlist entries, and add new license plates to the system.
  • A page to display founded alert

Progress

My progress is on schedule.

Schedule

  • I discussed with my teammates and went over the suggestions from the proposal presentation. We reviewed some updated use cases, which require modifications to the frontend.
    • The workflow for adding new plates to the watchlist.
    • The way alerts are displayed to officers.
    • The watchlist page should also include a list displaying recent match history of founded license plates
  • Backend implementation
  • Dashcam circuit design

 

Christine’s Status Report for 2/15

🟢 Progress This Week

Central Server Architecture Refinement

  • Shifted OCR processing from central server to onboard dash cam after faculty & TA feedback.
  • Refined layered architecture with API Gateway, Lambda, S3, and DynamoDB for scalability.
  • Updated central server design to reflect this change.
    • Before: OCR was centralized.
    • After: ALPR & OCR runs on the dash cam; the central server focuses on match verification & notifications.

API Design & System Components

  • Defined RESTful resource structure for plates, matches, and notifications and esigned API endpoints for central server:
    • Detection upload
    • Match storage & retrieval
    • Police portal access
  • Researched AWS-based load testing approaches for handling 314K concurrent requests.

Web Application Enhancements

  • Drafted design document outlining:
    • Vision & Key Features: Watchlist management, real-time alerts, match history search.
    • Use Cases: Detailed core flows for authentication, watchlist updates, and search.
    • Database Considerations: Decided on DynamoDB (watchlists) & RDS (match history).
  • Defined the interactions between web app backend and central backend.

Presentation Preparation

  • Began preparing slides for the upcoming design review presentation.
  • Drafted content covering architecture, security, scalability, and use case breakdown.

🔜 Next Steps

  • Design Report  🫠

  • API Gateway Setup & Testing
    • Configure routes for core API endpoints.
    • Manual testing to make sure API Gateway is properly set up.
  • Database Schema Design & Setup
    • Implement schema for DynamoDB (watchlist storage) and RDS (match history).
    • Ensure indexing and query optimization.
  • Lambda Integration for Message Queueing
    • Implement Lambda function to process incoming detections asynchronously.

⚠️ Challenges & Open Questions

Legal Compliance & Scope Definition

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).

Privacy & Data Security

  • Encrypt all stored & transmitted data (end-to-end encryption).
  • Require officers to justify searches (case number, reason) to prevent misuse.

📌 Overall Status

Currently on track.
The project has been demanding, especially since we aim to design a distributed, scalable system that can efficiently handle high loads. However, we have made a lot of progress on the design side, and we feel confident to start the implementation phase.

Vicky’s Status Report fot 2/15

Personal Accomplishments

  • ML End-To-End Pipeline Design:
    • Updated ML flow: Frame Acquisition -> License Plate Detection -> License Plate OCR -> Text Formatting -> Transfer OCR Detected Text to Handshake with Cloud -> Transfer Cropped License Plate Frame with Time and GPS Info to Cloud if Applicable
  • ML License Plate Detection:
    • Experimented with frame preprocessing using CV, results undesirable
    • Finetuned a Yolov11n model on Kaggle dataset, achieving 90.4% mAP50 and 65.5% mAP50-95
  • ML License Plate OCR:
  • Dash Cam Design
    • Finished dash cam v1.0 block diagram design
  • Hardware Purchase
    • Raspberry Pi 5 as the SBC
    • Raspberry Pi Camera Module 3 + cable
    • Blues Notecarrier Pi + Notecard Cellular + GPS&Cellular antenna

Progress

My progress is on schedule.

Schedule

  • RPi 5 bringup and testing
  • Camera module bringup and testing
  • License plate detection model deployment and benchmarking
  • License plate OCR model training, deployment, and benchmarking
  • Design report

Team Status Report for 2/8

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

 

Christine’s Status Report for 2/8

🟢 Progress This Week

Cloud Computing & Central Server Architecture

  • Researched AWS services (API Gateway, S3, SQS, EC2, Lambda, DynamoDB, RDS, SNS) and their interactions.
  • Designed a layered architecture with AWS services for image uploads, ALPR processing, and watchlist queries.
  • Explored SQS for asynchronous processing and caching strategies to handle high loads and avoid bottlenecks.
  • Documented the complete system flow for implementation.

    Web Application Design

  • Finalized the tech stack with Andy:
    • Backend: Node.js with Express.js
    • Frontend: React with Ant Design
    • Storage: DynamoDB (real-time watchlist), RDS (structured match history)
  • Designed core use cases:
    • Authentication (JWT-based login system)
    • Watchlist management (add, remove, view plates)
    • Notification center (email alerts via SNS, UI-based alerts)
  • Designed REST APIs with interfaces

🖊️ Progress

I’m currently on track.

▶️ Next Steps

API Design & Review

  • Design API endpoints for the central server, focusing on data ingestion, ALPR processing, and watchlist matching.
  • Review API endpoints for the web portal based on team feedback and refine where needed. Know issues:
    • Each user should have their own watchlist –> update /watchlist to support look-up by user ID

Database Design

  • Decide between DynamoDB vs RDS for different use cases.
  • Design database schema for central server watchlist storage & web portal authentication.

Use Case Design

  • Finalize Use Case Details
  • Define the full flow for each core use case (authentication, watchlist management, notifications).
  • Add alternative flows to ensure edge cases are accounted for.
  • Send finalized use case flows to Andy for UI design adjustments.

System Architecture Documentation

  • Create a block diagram for the central server.

    🚧 Challenges & Open Questions

  • Potential performance trade-offs in database selection (DynamoDB vs RDS) for different use cases. 
  • EC2 vs Lambda for ALPR layer.

Andy’s Status Report for 2/8

  • Discussion on System Design and Hardware Finalization
    • I worked with the team to finalize the system architecture and determine how data flows between the dashcam, backend, and law enforcement web portal. We discussed the core functionality of the system, which includes adding license plates to a watchlist, receiving real-time alerts when a match is found, and allowing law enforcement to view details such as image, GPS location, and timestamps.
    • As part of the hardware selection process, we discussed the performance of different boards to perform YOLO detection and OCR on accurate license plate recognition and their latency for performing these tasks.
  • Learning & Developing with Node.js, Express, React.js
    • I spent time learning and working with Node.js, Express.js and React.js with online resources about their flow and structures. I also learned to use these tech stacks by building a sample website including image uploading, location access, API communication functionality using these tech stacks.
  • Web app research. 
    • I conducted research on popular tech stack choices for building web applications, including Python Django, FastAPI, and Node.js with Express for backend development. I compared their performance, scalability, and ease of integration with real-time communication tools. After evaluating the pros and cons, I found that Node.js with Express.js is well-suited for our system due to its event-driven, asynchronous nature, making it ideal for handling multiple concurrent connections. Additionally, Socket.IO was chosen for WebSocket-based real-time push notifications, ensuring that law enforcement officers receive instant alerts when a match is found. However after discussion with Vicky and Christine, we found that any socket based real time notifications will need to maintain a list of all live communications between server and the frontends, which is not scalable and very difficult to deal with session reconnection and authentication. Thus we decided to utilize the amazon SNS email notification service to send an email to the web portal of law enforcement departments including a link for them to log in and check the matched report. This will make the notification in real time and does not need to maintain a huge number of live socket communication. It would be a pub-sub based service where individual police will “subscribe” the license plate they are watching and our server will send email to all “subscribers” upon a match for a license plate. 
    • For the frontend, I explored different UI frameworks, including raw HTML/CSS and React.js, and concluded that React.js with TypeScript would be the most scalable and maintainable choice. React’s component-based architecture enables efficient development, and TypeScript adds type safety, reducing potential runtime errors. To enhance the UI, we selected Ant Design for a clean, professional look.
    • For security and authentication, we agreed to use JWT-based authentication for user login and authorization, ensuring secure access to watchlists after discussion. 
  • By next week, I hope to finalize the technology block diagram for the website including backend service and frontend and be able to integrate together with the block diagram of the dashcam system and server system. Also, I should work together with Vicky to finalize hardware selection and finish ordering parts so we can start to wait parts and build the dashcam embedded system. 

I am currently on track of my timeline.

Vicky’s Status Report for 2/8

Personal Accomplishments

  • ML Strategy:
    • Drafted the following edge + cloud ML flow: Frame Acquisition -> Frame Preprocessing -> License Plate Detection -> Transfer Cropped License Plate to Cloud -> License Plate Preprocessing -> License Plate Classification -> OCR -> Text Formatting
  • ML Dataset Selection:
    • Identified a license plate detection dataset from Kaggle
    • Web-scraped platesmania.com to build a US license plate OCR dataset, as an ideal dataset wasn’t readily available
    • Chose the OpenALPR dataset for end-to-end testing
  • ML Model Selection:
    • Benchmarked FastALPR from GitHub on RPi 4
    • Decided to fine-tune YOLOv11n for plate detection
    • Chose to train an OCR model specifically for US license plates
  • Hardware Selection:
    • Based on latency benchmarks, finalized the dash cam hardware:
      • Raspberry Pi 5 as the SBC
      • Raspberry Pi Global Shutter Camera with a 6mm wide-angle CCTV lens for improved field of view
      • Adafruit GPS breakout module for geotagging plate captures

Progress

My progress is on schedule.

Schedule

  • Draw out the technical block diagram for the dash cam
  • Order dash cam components
  • Augment US license plate dataset
  • Prepare the design presentation and report