Category: Team Status Reports

Team Progress

This week our team worked together to complete the Design Review Report. After discussing with the course staff, we narrowed our use case to be primarily for billiard players. This way, our use-case requirements and report could be more specific in defending in what we presented.

Risk Mitigation

Now that the ESP32 has arrived some risks shift from theoretical to physical. Soldering errors and damaged components during assembly are a concern, since short circuits and weak connections could cause further damage later on and become difficult to diagnose. To mitigate this we have spare components for most hardware pieces, so that we are able to isolate errors to components and switch them out if necessary. Another risk is that the software transfer protocol in the current version of the application doesn’t work with the ESP32, and we can mitigating this risk by adapting the firmware and software to the hardware based on our testing this upcoming week.

Changes

Narrowed our primary use case to billiard players. However, we still noted that CapSure has many other applications but aren’t directly supported by our requirements.

Weekly Prompt

Part A: CapSure is designed to help billiard players capture and review shots without having to record an entire practice session. This need is not limited to one location or type of player. Billiards is played recreationally and competitively in many countries, so the system should be simple enough to use without requiring advanced technical knowledge or expensive equipment.  The recordings can be transferred directly to a phone over Wi-Fi, which avoids relying on cloud services or a constant internet connection. This makes the product more practical in pool halls, homes, or other environments where internet access may be unreliable. Keeping the system lightweight and built around a standard baseball cap also helps make it portable and usable across different settings.

Part B: CapSure addresses the desire to preserve memorable shots while respecting social expectations of shared playing spaces. Players may have different attitudes towards being recorded, and our intended use therefore involves informing participants as they are recording and making footage easily able to be discarded. The outward-facing indicator makes active capture readily visible, while local storage and user-controlled export give the wearer control over whether footage is shared. CapSure’s accessible physical controls allow players to save a shot without handling a phone, limiting interruptions to the pace of play, which is important for etiquette during a billiards game.

Part C: CapSure’s environmental footprint is small but not zero, since it is adds a battery powered electronic device to a customer’s tech ecosystem which will eventually result in e-waste. The housing will also be a plastic filament which is not biodegradable and will end up in landfill. However, the low resolution and low frame rate capture keeps power draw minimal and extends battery health, and since we are not using cloud storage, there is no ongoing energy cost of remote data centers. Option of local battery disposal and recycling will reduce the impact even more, depending on the user’s region.

Part A was written by Clarence, Part B was written by Ankita, and Part C was written by Jayden.

Team Progress

After the Design Review presentation on Monday, our team worked on the Design Report and on preparing for the hardware’s arrival. Ankita planned the firmware implementation and explained how our firmware choices support continuous recording, clip preservation, and transfer to the phone. Clarence sourced the remaining parts we need for integration, including connectors, switches, buttons, and breadboards. He also arranged access to a 3D printer for the enclosure and began learning CAD. Jayden made the phone app more robust against failures the real board could cause. Interrupted downloads now resume, each clip is checked before the device is allowed to delete it, and the app now validates the network being used.

Risk Mitigation

The main risk is still the arrival of the ESP32-S3, since sustained recording and recording during a transfer can only be measured on the real board. To prepare, Ankita is reviewing the camera, microphone, PSRAM, and SD card interfaces and writing initialization code so testing can start immediately. Her first goals are to confirm memory and storage, capture a JPEG, and check the microphone before building the full recording pipeline. Dropped frames from SD card write delays or Wi-Fi activity remain a concern, and we plan to address them with buffering and by batching SD writes. On the app side, we updated our mock device to behave like the ESP32, so connection problems surface during development instead of at integration.

Changes

There were no changes to our requirements or hardware this week. The app now downloads each clip as a series of small chunks, so an interrupted transfer only has to redo the chunk it was on. This fits within our existing communication protocol, but the firmware will need to handle many small requests reliably. We also plan to replace the shared development Wi-Fi password with a separate password for each device, so one user cannot connect to another user’s hat.

Team Progress

This week our team made lots of progress on flushing out all the details of our hardware and communication protocol between the CapSure module and mobile app.

Risk Mitigation

Right now the most significant risk is probably the delivery time of the ESP32-S3 which is the most essential piece of hardware we need to begin testing and development. To mitigate this, we will read the documentation and begin writing preliminary firmware so that we instantly have code ready to program once it arrives. Another risk to figure out is the transfer of the footage from the SD card to the phone, as write delays or Wi-Fi transfers could cause dropped frames or gaps in the rolling buffer, which would compromise the footage that we intend to preserve. To manage this, we updated testing requirements to test simultaneous saving and downloading; if these tests fail, we will adjust buffer allocation and SD write batching.

Changes

We took the feedback from the professors and agreed to update our use-case and matching design requirement for the battery life of our system. CapSure will now aim to support over 5 hours of continuous use to better suit the wide range of use-cases our intended audiences will have. We also updated our system such that Wi-Fi is a separate switch from the button to preserve the last 60 seconds; this allows the user to use CapSure in situations where they do not have their phone.

Additionally, we updated our Gantt Chart for our Design Presentation to include Division of Labor as well as important deadlines.

 

Weekly Prompt

Part A) CapSure addresses public health, safety, and welfare by allowing users to preserve a preceding minute of what just occurred in front of them without need to anticipate an event or immediately take out their phone. While some use-case scenarios are more fun (ex: capturing a missed moment at a sports game), CapSure also promotes welfare by accommodating cases where a person may be alone and want to record their surroundings for safety. Since CapSure is hands-free and records without needing a human trigger, this can  reduce the distraction of actively filming and help users document unexpected incidents. To support physical well-being, our design targets a module weighing less than 100g and contact-surfaces below 43°C, to liit the added weight and heat exposure for the user during wear. Retrospective recording can also support psychological well-being by giving users a way to revisit important events. To address the safety of bystanders and avoid CapSure being used as a hidden camera, a visible recording indicator on an LED will be on whenever the camera is on. The user is also able to delete footage on the app easily after it is saved, in the case that a bystander requests so. Wi-Fi only activates when the user presses a separate button, and saved clips remain protected until the phone verifies receipt. By keeping recording and retrieval local rather than requiring internet access or a cloud subscription, CapSure supports users’ access to personal records while limiting ongoing costs and dependence on external services.

Part B) CapSure is designed to meet the need for capturing unexpected moments after they occur while also considering the privacy concerns created by wearable cameras. A user may want a record of an incident, conversation, or event, but the people around them may not expect or feel comfortable being recorded. Attitudes toward recording in public can also vary between communities and social settings. To make recording more visible, CapSure includes an LED that remains on whenever the camera is actively capturing, giving nearby people a clear indication that the device is in use.

CapSure also limits how much footage is retained. The system continuously maintains only the most recent 60 seconds of footage, and a clip is permanently saved only when the wearer presses the physical trigger. This avoids creating an all-day archive of everyone the wearer encounters. Saved clips are stored locally rather than automatically uploaded to a cloud account, and transferring a clip requires the user to deliberately enable Wi-Fi and initiate the transfer. These design choices allow CapSure to provide retrospective recording while reducing unnecessary collection and sharing of footage involving bystanders.

Part C) Market alternatives like action cameras ($500+), smart camera glasses ($300+), and standard dashcams ($300+) carry high financial barriers for everyday use. CapSure addresses these economic factors by streamlining the product life cycle across production, distribution, and consumption. In production, using low-cost, modular commodity hardware like an ESP32-S3, 3D-printed mounts and simple switches keeps the initial manufacturing bill of materials under $50 while allowing flexible design iterations to easily swap components such as larger SD cards or better microphones to match evolving consumer demands. For distribution, CapSure fits directly into the user’s existing tech ecosystem by mounting on hats they already own and offloading clips directly to the smartphone they already carry, eliminating the need for redundant displays or extra peripherals. Finally, for consumption, CapSure operates on a buy-once, zero-subscription model since no cloud storage is necessary, delivering a low-cost and accessible way to capture and store personal moments.

Part A was written by Ankita, Part B was written by Clarence, and Part C was written by Jayden.

Team Progress

After our Proposal Presentation where students and professors brought up good questions during the Q&A, we finalized our use-case scenarios and with that the quantitative requirements we want our project to achieve. We are now moving forward with the design phase where we are doing deeper research into hardware components, specifications, and software architecture.

Risk Mitigation

The most significant risk to our project is lack of research into parts leading to us ordering hardware that won’t be used or turns out to be insufficient to our project demands. To mitigate this, we are flushing out the design which will be presented in our Design Review deliverables next week.

Changes

No changes to the project plan or schedule were made.