Posted on

Andy’s Status Report for 3/1

This week, I focused on solving the dash cam circuit issue, worked on rpi5 and camera module bring up, started web app backend implementation, and worked on the design report.

Since the RPi5 must shut down gracefully when the car’s engine is turned off, ensuring a stable interim power supply is crucial. I compared several available modules based on output voltage, run-time capacity, size constraints, and ease of integration, with the goal of finding a solution that meets both our technical and cost requirements.

I collaborated with Vicky to bring up the RPi5 and Camera Module 3, verifying that the drivers and interfaces worked correctly on our target hardware. We tested that the camera is working by taking test images to see if it meets the resolution. And we started thinking how to implement the loop recording and ALPR calling function on the rpi camera.

On the software side, I began implementing the backend for our web application.

Lastly, I spent time writing and refining our design report.

Progress:

overall the progress is on time, but the web app backend implementation could go a little faster as there are still many functionality not implemented yet. But luckly next week is the spring break and I plan to make some progress during the week. But overall, I am on progress

Schedule:

  1. Finalize the UPS module and purchase.
  2. Test the UPS module
  3. Finish deploy ML on edge
  4. Blues module bring up and GPS test
  5. Web app backend
Posted on

Team Status Report for 3/1

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.
Posted on

Andy’s Status Report for 2/22

This week, I focused on the UX/UI design and implementation of the webapp, and the circuit design for the dash cam:

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

  1. A login page with JWT-based authentication.
  2. A dashboard that allows law enforcement to view and modify the police officer’s individual watchlist entries, add new license plates to the system, and check the recent history of matched list.
  3. A page to display founded alert.

For the circuit, it is used to help the rpi5 conduct the safe shut down process because the power supply on car will stop as soon as the car is shut off, but our rpi5 requires an additional period of time to execute the shut down process or the video stored or the board itself could be damaged.

For this week, I had a initial plan and circuit desig using LTspice, but more design and discussion is required.

In case this does not work, I also did research online and found a module called UPS hat for rpi seems could be utilized to solve our problem.

https://www.waveshare.com/ups-hat.htm

Progress
My progress is on schedule.

Schedule:

  1. Start backend implementation from the interface with cloud server
  2. Continue on dashcam circuit design
  3. Design report
Posted on

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

 

Posted on

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

 

Posted on

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.