Posted on

Team Status Report for 4/26

Risks

  • We are still working on writing a simple webapp wrapper for demo purposes.

Changes

  • Instead of using a breadboard for connecting the opt-in switch and debug LED, we soldered a protoboard so that the dash cam is more compact and installable in a car.
  • While implementing the wrapper web app, we identified an opportunity to improve how Plate Patrol notifies external services of license plate matches.
    Currently, matches are simply logged to the match_log table, “as if” notifying services. However, for true backend-to-backend integration, a more robust, real-time communication mechanism is needed. After evaluating options, we decided to implement webhook notifications, aligning with industry standards for real-time event delivery. To support this, we updated the Watchlist Management APIs (now better described as Webhook Registration APIs) to allow external services to dynamically register and unregister for plate match notifications. This enables third parties (such as dashcam users and security partners) to opt-in and receive instant alerts when plates of interest are detected — without the need for constant polling or manual monitoring.

Testing

Schedule

Posted on

Vicky’s Status Report for 4/26

Personal Accomplishments

    • Final Demo:
      • Wrote a demo script with pure inferencing, no recording and no server communication
    • Dash Cam Bringup:
      • Soldered a protoboard to connect switch and LED to the dash cam

Progress

My progress is on schedule.

Schedule

  • Final video and report
Posted on

Vicky’s Status Report for 4/19

Personal Accomplishments

    • Dash Cam Bringup:
      • Improved the image upload pipeline by adding auto retry on failure
      • Included API Key for GET and POST requests to add security
    • Dash Cam Verification:
      • Verified that the dash cam’s weight is 0.77lbs
      • Verified that the system’s startup script executes within 33s of a power change, recording starts within 41s of a power change, and shutdown script executes within 332ms of a power change
      • Verified that the system reliably transitions its ALPR setting (opt-in/out) within 1s (instantaneous)
      • Verified that the data at rest on the dash cam is erased upon shutdown

Progress

My progress is on schedule.

Schedule

  • Final poster, report, and video
  • Inference demo script

Tools and Knowledge Learned

The learning strategies that are most helpful to me includes: online videos for dash cam bringup, forums for specific debugging questions, and ChatGPT for conceptual questions.

Posted on

Vicky’s Status Report for 4/12

Personal Accomplishments

    • Dash Cam Bringup:
      • Added a dip switch and software script to allow users to opt in or opt out of the ALPR mode
      • Refactored GPS code to make it nonblocking when GPS signal is not detected and debugged GPS connection issues on power on
      • Implemented sync match image chunk upload and experimented with async match upload using thread
        • Both HTTP GET and HTTP POST use the same I2C address, so I have to implement a locking mechanism
        • This results in a traffic jam that we think is not worth for implementing async chunk image upload
        • So we decided to stop further inferencing when we are uploading a match image
    • Dash Cam Testing:
      • Added an LED to indicate the stage of the dash cam for easier road testing, LED is ON during setup, LED flashes slowly during recording, and LED flashes faster during inference
      • Wrote a pure recording script to record real-road footage for future demos
      • Worked with Christine and Andy to conduct a 30 minute road test under rainy setting
    • Dash Cam Verification:
      • Verified that the dash cam records continuously in 1-minute clips for 10 minutes in a stationary setup
      • Verified that the dash cam records continuous footage under five separate real-driving tests of at least five minutes each
    • ALPR Verification:
      • Benchmarked the YOLOv11n model using a curated set of 386 real-world images sourced from the Kaggle-based dataset, achieving 90.4% mAP50
      • Benchmarked the PaddleOCRv3rec component on the scraped dataset from platesmania.com, which includes 4,000 cropped synthetic U.S. license plate images and 1,000 cropped real-world images, achieving 93% accuracy
      • Benchmarked the end-to-end ALPR pipeline by passing 5,000 full-frame, real-world images from platesmania.com through the system, achieving 79% accuracy, with 17% false positive and 4% false negative

Progress

My progress is on schedule.

Schedule

  • Road tests
  • Dash cam pipeline fixes (API key integration, etc.)
  • Scripts for demo purposes
Posted on

Vicky’s Status Report for 3/29

Personal Accomplishments

  • CI/CD:
  • Dash Cam Bringup:
    • Integrated HTTP GET code to end to end script and got cache working to reduce the number of requests
    • Integrated Andy’s UPS auto shutdown code to end to end script
    • Integrated Sparkfun GPS-RTK module via USB serial to acquire GPS coordinates in the end to end script
      • I2C connection was unsuccessful due to address conflict with the UPS module
      • UART connection was unsuccessful for unknown reasons
    • Added logging to end to end script, with auto ALPR on when power on and board shutdown when unplugging the cable
    • Improved end to end script to only run OCR on horizontal detection boxes with >0.5 confidence and only send GET requests when recognized plate length is between 2 and 8 to reduce the number of requests
    • Assisting Blues engineer to debug the GET json error
  • Dash Cam Testing:
    • Set up the dash cam to be installable on a car with a phone holder
    • Worked with Christine and Andy to road test the dash cam in real world setting and validated ALPR and GET request capabilities

Progress

My progress is on schedule.

Schedule

  • Central server integration and testing
  • Opt-in switch module bringup and testing
  • End-to-end pipeline debugging
Posted on

Team Status Report for 3/22

Risks

  • Communicating between the dash cam and the central server is a challenge. We are trying to send a web get request from Notehub to our AWS public http endpoint. We are able to get expected json response using manual curl as well as copying the link into web browser. However, when we set up the route in Notehub and get it this way, we always receive {‘result’: 503, ‘body’: {‘err’: ‘hub request error: response from web service does not appear to be JSON {not-json}’}}, and central server also doesn’t receive any GET requests. We tried setting up another public api route, which we are able to web get with Notehub, indicating that the route setting should work. We are adding more logging on the central server side, posted the issue on Blues forum, and contacting other teams also using Blues.

Changes

  • Blues Notecard doesn’t support running cellular and GPS at the same time. If one is in continuous mode, the other one needs to be in periodic mode with at least 5 minute interval. Since 5 minute interval is rather long, we are planning to purchase an additional GPS module. In the mean time, we will use the GPS location obtained by cellular data for geolocation tagging.

Schedule

Posted on

Vicky’s Status Report for 3/22

Personal Accomplishments

  • Dash Cam Bringup & Testing:
    • Worked with Andy to connect Blues Notecard to Notehub
    • Worked with Christine to send HTTP GET requests to central server
      • Debugging why parsing the server response as json fails, current workaround is to take it as plain/text then decode it
    • Finalized Adafruit Ultimate GPS as the separate GPS module
    • Wrote launcher script to automatically run camera recording and detection at power on
    • Debugging the end-to-end pipeline

Progress

My progress is on schedule.

Schedule

  • Order GPS module
  • Central server integration and testing
  • Opt-in switch module bringup and testing
  • End-to-end pipeline debugging
Posted on

Team Status Report for 3/15

Risks

  • Communicating between the dash cam and the central server will be challenging, as we need to determine how they communicate and how the dash cam locates and uploads images. Since we’re no longer building a web app, Andy can focus more on integration, and we plan to implement this in blocks to manage complexity and reduce risks.
  • Determining how images and metadata are stored on the dash cam is an issue we talked about and need more discussion on tradeoffs. We discussed storing the information about the license plate number that we sent on dash cams so we do not send them again in recent times. The benefit of this would be to reduce flushing to end users, but this introduces more computational complexity on Raspberry Pi and might cause unconfident images only being sent once that are not enough for human verification. We also need more discussion on if we should store temporary images on RAM and send them to the server directly, or we should always store them to SD card first and send from SD card.

Changes

  • Based on feedback from our design report, we decided to switch to an API-first approach instead of a full web app, as it better aligns with our system’s intended use. Since law enforcement agencies likely already have their own software, exposing an API enables seamless integration rather than requiring them to adopt a separate interface. Moving forward, we plan to expose a single POST endpoint for adding plates to the watchlist. To ensure security, external services will be required to use an API key to access the endpoint, and we will implement audit logging to track who added what. If a match is detected, we will log the event as if notifying a tip line—without actually sending notifications. This keeps the system lightweight and secure while still preserving important tracking data.
  • Based on dash cam bringup experimentations, we found writing raw footage to SD card to be the performance bottleneck, limiting the frames per second the dash cam can capture. To address this issue, we decided to store raw footage at 480p, while still having the dash cam inference on higher resolution (2304*1296) frames.

Schedule

Posted on

Vicky’s Status Report for 3/15

Personal Accomplishments

  • Dash Cam Bringup & Testing:
    • Setted up Python virtual environment to run detection and OCR models with streaming Camera Module 3 input
    • Deployed and benchmarked ML license plate detection model on RPi 5, PyTorch format achieves around 370ms latency per frame, ONNX format achieves around 350ms latency per frame, and NCNN format achieves around 160ms latency per frame with streaming camera input
    • Deployed and benchmarked ML license plate OCR model on RPi 5, Paddle format achieves around 120ms latency per frame with streaming camera input, and ONNX format was deployed unsuccessfully
    • Wrote the end-to-end pipeline, with the main thread recording footage in 1 minute 480p20 clips, and the inference thread inferencing 2304*1296 resolution images and storing cropped license plate results at around 3fps

Progress

My progress is on schedule.

Schedule

  • GPS module bringup and testing
  • Network module bringup and testing
  • Opt-in switch module bringup and testing
  • End-to-end pipeline debugging