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