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!

Leave a Reply

Your email address will not be published. Required fields are marked *