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 81% accuracy

Progress

My progress is on schedule.

Schedule

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

Christine’s Status Report for 4/12

Progress

  • Implemented Chunk Upload Protocol (PR): Successfully developed and integrated the chunk upload protocol. For detailed information on the implementation and updated flow, please refer to the PR description.
  • Added Match Log (PR): Developed and added a match log feature to track and record relevant data, enhancing our ability to monitor and analyze system performance and matches.
  • Integration Test with the Team: Collaborated with the team to conduct integration testing.
  • Currently on track ✅

Verification

  • Watchlist Management: Added manual tests and Jest automated integration tests to cover both the happy path and edge cases, such as invalid input and missing API keys.
  • Watchlist Query Requests: Implemented manual tests along with Jest automated unit and integration tests to handle cases involving matched plates, unmatched plates, and invalid inputs.
  • Image Upload: Added Jest integration tests for the end-to-end image upload process to ensure comprehensive coverage and reliability.
  • To-do:
    • Chunked Image Upload: Add Tests for Edge Cases (#14):
      • Develop and execute tests for various edge cases to ensure the robustness of the chunk upload protocol, including:
        • Scenarios where chunks are missing or uploaded out of order.
        • Handling invalid requests, such as those with missing fields in the /uploads API.
        • Managing duplicated chunks to prevent errors and ensure data integrity.

All tests are integrated with our CI/CD pipeline, ensuring continuous verification and validation of the system as changes are made.

What’s Left to Do:

  • Implement API key for dash cam communications
  • Add tests for chunked image upload edge cases
Posted on

Team Status Report for 4/12

Validations Done

  • We conducted five in-vehicle tests to confirm that the car cigarette lighter reliably powers the unit for 30-minute sessions.
  • In real-world testing, we deployed the dash cam in a vehicle for a 30-minute drive, during which the driver continuously called out the license plate numbers observed. During the 30-minute session, the driver identified 25 license plates while driving. All 25 were correctly detected by the dash cam system. In addition, the dash cam detected an extra 117 license plates that the driver was unable to observe while driving.
  • To evaluate end-to-end system latency, we conducted 10 field tests and record timestamps at key stages. Average on-board detection latency is 123ms, OCR latency is 134ms, and network handshake latency is 469ms.

Validations To Do

  • In the lab, we will verify that the unit’s weight is less than 1.5lbs using a scale.
  • We will time the initial setup process with five participants, ensuring that the average setup time is under 10 minutes.
  • We will verify that the system’s startup and shutdown scripts execute within 30s of a power change through five simulated tests and five field tests, ensuring that no file corruption occurs during the process.
  • We will test the opt-in switch functionality through 10 separate activation/deactivation cycles to confirm that the system reliably transitions its ALPR setting within 1s.
  • We will verify that data at rest on the dash cam is erased upon shutdown, that non-match data on the server is deleted immediately, and that matched data is retained for 21 days.
  • We will evaluate the chunk image upload latency through real-world road test.

Risks

  • Since we are now in the testing phase, we find calculating our performance data quite challenging. It involves a lot of manual work as we need to look through footage to identify additional license plates that the dash cam caught.

Changes

  • We modified the image uploading pipeline due to a hardware limitation with I2C bandwidth. Initially, we planned for two parallel threads on the dash cam: one for uploading chunked images upon server request and another for ongoing inference and license plate number queries. However, our hardware supports only one active I2C communication at a time, preventing simultaneous uploads. To address this, we now pause inference and plate number query during image uploads, resuming them afterward. With an average upload time of 500ms, the impact on real-time detection is minimal. This approach also makes sure we prioritize plates on watchlists, as the chance of detecting another watchlist plate immediately after is very low.
  • We removed loop recording since it’s not the main focus of the project and it’s challenging for development and testing. Similarly, we decided to remove text formatting as current performance metrics looks good and it’s not the main focus of the project.
  • For security compliance, we’ve added an API key to the dash cam communication APIs. This ensures only authorized devices can access the system (send detection query / upload images). We can implement rate limiting to prevent API abuse. If necessary, we can trace back activities to specific dash cams.
  • Since we have limited bandwidth, we decided to cut the server load testing to conserve both budget and effort. This allows us to better focus on the integration and presentation.

Schedule

Posted on

Andy’s Status Report for 4/12

Verification and Validation Update:

As we transition into the verification and validation phase, we are aligning our testing approach with our core engineering design and use case requirements. I am mainly in charge of the dashcam circuit components so my individual testing are more oriented with the dash cam power supply system.

Our dashcam power system is designed to draw power from the car’s cigarette lighter, which is converted by an adaptor to 8.4V 2A for the UPS(Uninteruptable Power Supply). The UPS then regulates this input to provide a stable 5V 5A output to the Raspberry Pi, while also managing seamless switching to its internal battery when the car is turned off—ensuring a safe shutdown process for the RPi.

Tests Completed:

  • Power Regulation Test: Verified that the adaptor consistently provides stable output (8.4V ± 0.3V and 2A ± 0.2A) under both nominal and surge input conditions to the RPi UPS module.
  • UPS Power Supply Test: Verified that the UPS consistently provides stable output (5V ± 0.3V and 5A ± 0.4A) under both nominal and surge input conditions from the simulated power supply from car. Also I tested and verified that the UPS consistently provides stable output when the power supply simulated from the car is off, which means the UPS switched to its battery for backup power supply.

After verified the system works during simulation test in the lab, I tested the system on a car with actual car cigarette lighter.

  • In-Vehicle Test: Validated system stability in a real car environment with varying RPMs and load conditions. Continously measured the voltage for 5 min while another driver is driving the car under normal driving condition.

Verification Approach:

  • Instrumentation: Use multimeters, current clamps to monitor real-time voltage and current waveforms.
  • Simulation: Use voltage generator from ECE labs

Planned Tests:

  • Endurance Test: Run the complete system for an extended period to test long-term reliability, focusing on consistent voltage and system uptime.
  • Integration Test: Connect with RPi to conduct end-to-end testing for the entire system while continously measure the voltage and current to check for abnormal circuit behaviors.

Summary of Work This Week:

  • Cigarette Lighter to Adaptor Simulation Testing:
    • Used a wire-to-car-cigarette-lighter converter to simulate a car’s power source.
    • Connected our adaptor to a breadboard to measure voltage and current under standard conditions.
    • Confirmed that the adaptor correctly regulated the voltage from the car cigarette lighter.
    • Simulated transient input spikes ranging from 10V to 20V, which can occur due to vehicle alternator behavior or load switching.
    • Verified that our adaptor provided clean, regulated power even during input fluctuations.
  • Raspberry Pi UPS Power Test:
    • Used the stabilized adaptor to power a Raspberry Pi UPS HAT.
    • Disassembled the RPI and UPS HAT for isolated testing.

Next Steps and Schedule:

  • Continue full integration testing with the RPI in-vehicle.
  • Monitor long-term stability under varying driving conditions.
  • Begin logging power behavior during startup and shutdown phases.

Progress:

This week, I made progress by completing the majority of the circuit-level testing. I verified the power regulation behavior of our adaptor and UPS module, both in simulation and in a real vehicle environment. With these components confirmed to be working, we are ready to move forward with full system integration using the car cigarette lighter as the actual power source.

Additional tests, including endurance and thermal testing, are planned to further ensure reliability under extended and realistic conditions.

 

 

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