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/29

Risks

  • Chunked image upload: The chunked image upload process is fairly complicated because we’re implementing it from scratch. While we considered S3 multipart upload, it wasn’t suitable for our file sizes. This approach introduces more moving parts, including chunk splitting, metadata tracking, individual uploads, and image assembly. While this complexity increases the potential for issues (e.g., missing chunks, incorrect assembly), we’ve developed a solid design for the image upload protocol this week (details in PR description) and got the basic structure in place. The focus next week will be on thoroughly testing and debugging to minimize risks and ensure reliability before integration.
  • Power supply integration: Integrating our uninterruptible power supply (UPS) with car cigarette lighter power sources presents potential challenges, as the UPS currently operates reliably only from stable stationary power outlets. We have procured an adapter and an additional cigarette lighter wiring adapter specifically for testing purposes. Before any on-road implementation, we plan extensive lab testing to verify functionality, stability, and safety under simulated automotive conditions. This cautious approach aims to mitigate risks associated with unstable voltage, unexpected power fluctuations, or hardware incompatibility when connecting to a vehicle’s power system.

Changes

  • GPS module: We changed the GPS module from Adafruit Automate GPS to Sparkfun GPS RTK according to Professor Tamal’s recommendation. 
  • Image upload protocol: We realized that Blues Notehub’s 8KB file size limit requires us to use chunked uploads for images (~45KB). Originally, we implemented S3 pre-signed URLs for full image uploads, but that approach wouldn’t work with the size limitations. As a result, we’re implementing the chunked image upload process from scratch. 
  • Partial match instead of message queue: Instead of implementing a message queue in the watchlist query server for asynchronous processing, we are prioritizing local filtering (partial matching) on the dashcam for now since this approach can more directly reduce bandwidth consumption and server load. By performing partial matching directly on the dashcam, we can simplify server-side operations, minimize data transmission, and enable faster, more efficient processing at the edge. The dashcam will locally store a synced watchlist and perform partial matches (e.g., comparing the first few characters of license plates) before sending only the relevant matches to the server. We still need to figure out the best way for the dash cam to sync with the server.

Schedule

Pics!

Posted on

Andy’s status report for 3/29

This week, I successfully tested and brought up the uninterruptible power supply (UPS) module. Activities included setup, initial testing, installation, and integration with the Raspberry Pi 5 (RPI5).

Initially, powering via cable was unsuccessful due to lower-than-expected voltage, so I instead installed and powered the module directly through the RPI pins.

I brought up the UPS module connected to the RPI, wrote a script to detect battery charging and discharging states through if the direction of current flow, and modified this script to safely initiate an RPI shutdown sequence when power from the car is disconnected. This is very important for our project because we want to protect the board and the storage card for our system but the power supply from car shuts off right when the car is turned off by the driver. I also tested the script and if the safe RPI shutdown process was executted correctly when the power supply to the UPS is off.

Additionally, I reviewed the UPS documentation to investigate if automated restart of the RPI could be achieved when power returns. Currently, the UPS module lacks direct support for this function.

Next week, I plan to explore alternative solutions to automate restarting the system and eliminate the need for manually toggling the UPS module. Also next week I plan to test the safety and stability of the car cigarette lighter-to-UPS power supply adapter.

Progress:

Overall, progress is on track. I integrated together with Vicky on rpi modules and they are currently working. All team members conducted a initial road testing with our dash cam system to test the end-to-end functionality. We currently used a portable power supply for the power supply source for the UPS module before we could safely use the car cig-lighter power supply adaptor. The end-to-end system tested to be working as we could receive API calls on our AWS server from our dash cam.

Schedule:

  • Explore alternative solutions to automate restarting the system and eliminate the need for manually toggling the UPS module.
  • Test the safety and stability of the car cigarette lighter-to-UPS power supply adapter
  • Interim Demo
Posted on

Christine’s Status Report for 3/29

✅ What I Did This Week

Chunked Image Upload

  • After discussing with Vicky, we realized that Blues Notehub’s 8KB file size limit requires us to use chunked uploads for images (~45KB).
  • Initially researched S3’s multipart upload, but it requires larger file sizes, so we decided to implement the logic from scratch.

Overview of Chunked Upload Protocol (details in PR description):

  • Splitting: Dashcam splits the image into ≤8KB chunks, each containing metadata (image_id, chunk_id, total_chunks, and data).
  • Uploading: Chunks are uploaded individually to the backend via API Gateway → Lambda → temporary S3 bucket.
  • Tracking: Lambda tracks received chunks in DynamoDB to monitor progress.
  • Assembly: Once all chunks are uploaded, a Lambda function assembles the image and stores it permanently in S3. Temporary chunks are cleaned up afterward.

Progress on Implementation:

  • I’ve set up the skeleton for the entire process: splitting, uploading, tracking, and preparing for assembly.
  • Still need to write the Lambda function for assembling the image and test the full workflow.

Improved Observability

  • Added more logging using CloudWatch X-Ray to monitor API Gateway usage in real time.
    • Tracks failure rates and latency to help identify performance bottlenecks.

🚧 What I’m Working on Next Week

  1. Interim Demo
  2. Finish Implementing Chunked Upload
    • Write and test the Lambda function that assembles image chunks into a complete image.
    • Debug and test the entire process end-to-end.
  3. Integrate Chunked Upload with Dashcam System
    • Work on integrating the chunked upload process with the dashcam system.
    • Coordinate with the team to ensure everything works smoothly.

📌 Overall Status

  • On Track: The chunked image upload is the most complex part of the system, but we have a solid design in place. While there’s still work left to finish and test the implementation, I’m confident we’re moving in the right direction.
Posted on

Andy’s Status Report for 3/22

This week, I focused on the bring-up of the Blues module with the Raspberry Pi 5, as well as the setup and testing of the Blues Notehub system.

After successfully initializing the Blues Notecard chip on the Raspberry Pi 4, I migrated the setup to the Raspberry Pi 5. The migration was successful, and the chip was fully set up and operational on the new platform.

In parallel, I configured Blues Notehub, which serves as the cloud interface to receive and process requests sent from the Blues Notecard chip. I verified successful communication between the chip and Notehub by sending and receiving test requests.

Additionally, I collaborated with my team to integrate the request-sending flow. We successfully sent requests using a demo URL, confirming the proper functionality of the system pipeline. We also worked together to connect and send requests to our central server via the AWS API. While the request was sent, we encountered some errors during the process, which we plan to debug and resolve in the upcoming week.

Progress:

Overall, progress is on track after I have shifted my focus from the web app to assisting Vicky and Christine with dashcam and server implementation. We are having a little issue with integrating the Blues LTE service with communicating with the AWS server, but we believe we could fix this on time.

Schedule:

  • Test GPS with Blues
  • Test UPS HAT with uninterupting power supply
  • Get Blues to be able to communicate with AWS
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

Christine’s Status Report for 3/22

✅ Progress This Week

  • Finished the initial implementation of the match upload layer (PR Link)
    This layer handles the ingestion, processing, and storage of detected license plate matches. The flow is as follows:

    • Dash cams upload images via pre-signed S3 URLs

    • An S3 event triggers a Lambda function to:

      • Extract GPS and timestamp metadata from image EXIF

      • Store the metadata in the match_logs table in DynamoDB

    • Architecture: S3 → S3 Event → Lambda → DynamoDB (match_logs)

  • Documented the full flow in the PR description, covering:

    • Pre-signed URL generation

    • Upload handling via S3 and Lambda

    • Metadata extraction and logging

    • All changes are fully covered by tests

This gives a scalable and decoupled foundation for matching plates to images and metadata.

🚧 What I’m Working on Next Week

  • Dash Cam Integration

    • Begin integrating the new match upload layer with the dash cam system

    • Revisit existing endpoints (/detections, S3 upload) to determine required changes

    • Prioritize approaches that minimize friction for the dash cam side

    • Coordinate with others for schema consistency across services

  • Observability Improvements

    • Expand CloudWatch logging:

      • Currently tracks S3 and Lambda activity

      • Will add API Gateway request logs, performance metrics, and error tracking

    • Goal: improve visibility into API usage, failure rates, and overall latency

📌 Overall Status

Currently on track. The core functionality for match upload is complete and tested. Integration with the dash cam system will be the main challenge next week.

 

Posted on

Christine’s Status Report for 3/15

Progress This Week

  • Completed Watchlist Management Layer (PR)
    Implemented an AWS Lambda function for managing the global watchlist, integrating DynamoDB for storage and API Gateway for HTTP access. The system now supports adding, retrieving, and removing plates via secure API endpoints. All changes are covered by manual tests and automated Jest tests with CI/CD.

  • Redesigned API Interface Based on Design Report Feedback
    Based on the design report feedback, we adopted the “tip line” approach instead of a full web app. I redesigned the API interface to expose a POST endpoint for law enforcement agencies to add plates. See the team status report for detailed changes.

  • Refactored for API-First Approach (PR)
    Removed the web app dependency (no more officers) and restructured watchlist management endpoints (/plates) to work with API keys. /detections now only checks for plate matches without officer tracking, and /plates requires an API key for modifications. The refactor simplifies external service integrations and is fully covered by automated tests.

In Progress

  • Match Upload Implementation (Draft PR)
    Implemented a Lambda function for extracting metadata, logging matches, and attaching images to S3. Integrated DynamoDB for match tracking. Currently testing and debugging before deployment.

Overall Status

  • The project is on track with API refinements complete and match upload nearing finalization. Here’s a list of API endpoints ready for integration.
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