Table of Contents
Add Headings and they will appear in your table of contents.
Introduction
Reflecting on the trajectory of this capstone project, the process was a rigorous journey—from moving from a proposed idea in the middle of first semester of an AI sign language-learning software to our discreet, personal safety weareable. The global perspective we were forced to understand was that engineering is a social endeavor; it requires balancing user empathy with technical constraints and reality. One of the most significant lessons we learned was that a perfect idea left in the Notes App might as well be no plan at all. Perfectionism often leads to stagnation. Time management was a persistent challenge, particularly when balancing highschool responsibilities, miscalculating our project trajectories, dealing with shipping dates, and unforeseen malfunctions increasing the amount of time to fix a problem. I realized that addressing engineering tasks with high priority and setting aside a large amount of time are the only ways to mitigate the unpredictability of hardware troubleshooting. I learned in this project the most about the field of software engineering and that to be a successful engineer means less to be proficient in CAD or coding and more to be proficient in resilience and project management.
Problem Statement
Domestic abuse victims often face significant barriers when seeking help. Even if they have some mobility, 71% of victims' report that abusers monitor their communication, restrict their movements, and/or manipulate them in a manner that prevents them from reaching out in an indiscreet manner. Current safety tools are either too visible, inflexible, or too dependent on established infrastructure or law enforcement, leaving victims without discreet, reliable, and comfortable ways to signal for help.
Reflection on the Elements
Element A:
Through extensive background research, patent research, data collection, and market analysis, this phase of our project has illustrated a glaring need to fill a niche in the market with a discreet, independent, and reliable safety device tailored to the needs of those currently in abuse situations. Survey findings and contextual research have confirmed the demand and social value of a product that enables victims to communicate safely and confidentially without dependence on established infrastructure, as well has helped us identify that such products should be distributed in domestic abuse shelters or be bought online. Interviews have helped facilitate two potential designs: one that is court-mandated for abusers and one to protect the general public. Our problem was clearly defined and we were ready to focus on design ideation and prototyping.
Element B:
From working closely with experts, analyzing products and patents as well as providing an engineering project proposal, we generated various key insights into what criteria we should include in our product design. Dr. Matta, a licensed clinical psychologist suggested to incorporate several levels of contact into our design as to ensure that individuals in high-risk situation are comfortable in using our product. Additionally, one product we were suggested to study is the Apple AirTag which provides preexisting infrastructure for location tracking services by itself. Consumers, too, helped us in the design of our discreet personal safety device; the vast majority of customers (72.5%) believed that haptic feedback (vibration) would be most useful for confirming that trusted contacts/authorities were contacted. Moving forward into Element C, we have assessed the weight of previous criteria and generated new criteria for our project, enabling us to make a well-informed decision when comparing our initial designs and new ones generated due to this element. We have proved the validity of several designs over others: the beaded bracelet, discreet ring, airtag case, and probation bracelet.
Element C:
In this element we generated many key findings. Using a matrix comparing similar solutions, we have identified a universal obstrusive lack of independence from existing infrastructure for products in the panic button market; they often require a working bluetooth connection or proximity to a stationary console. Key feedback from our presentation of solution design requirements include the incorporation of panic button into highly mobile existing infrastructure such as an airtag(Cameron Shaeffer, electrical engineering) as well as ensuring that our design includes variable inputs(Dr. Matta, clinical psychologist), enabling victims that do not feel comfortable with contacting authorities and trusted contacts at the same time. Additionally, we have decided to research further into the legal efficacy of our product. We also analyzed data from our consumer survey to add another criteria: feedback via vibration. Using this input we devised a second matrix, analyzing which criteria weighs greater, comparing our initial concept designs to products on the market, and finally choosing the discreet panic ring as the solution we intend to primarily pursue.
Element D:
In this phase, we distilled twenty of our primary concepts for a discrete, wearable, personal safety device into five of our most viable options. These five included the integration of an SOS signal into a keychain charm, the incorporation of a special device into a credit card, the attachment of an SOS signal onto a clothing item, a bracelet, and a discreet "panic ring". These designs were filtered after further research into three feasible prototype designs: two variations of a bracelet, and a ring. After creating a 3D-printed mold, research into materials (namely into flouroelastomers which are present in Apple Watches), and specification of electrical components such as Linear Resonant Actuators, ESP32 Microcontrollers, Adafruit GPS modules, etc., we determined the most viable option to prototype for the current state of our project to be a watch-like in size bracelet and focus minimize the size of our components in the coming months. Michael Wilk, an electrical engineer at Tesla who primarily manages quality control for Tesla batteries, provided us with key insight into minimizing component size as well as handling other engineering challenges we have been pondering: how to increase the independence of the device from existing infrastructure (e.g., cellular connection and Bluetooth) and increase battery life. He recommended a blend of 3.3V LiPo batteries for the main GPS and microcontroller, and for the discrete aspects (haptics, LEDs, etc.) to be powered by an ultracapacitor, a PCB-compatible battery hooked up to a gyroscope sensor, and to also focus on purchasing more low-draw components. The next step in our project is to minimize the size of our prototype through this input and to gather more research into communications engineering, specifically into understanding how third-party companies like Chipolo have attached themselves to the "Find My" network through the MFi program and how attaching our product to this infrastructure could potentially increase the device's independence.
Element E:
The integration of these STEM principles serves as the ultimate validation of our problem statement: that personal safety requires a discreet, reliable, and scientifically grounded intervention. By applying human physiology to the design, I substantiated the need for a haptic-feedback wearable and the appeal of a discreet panic button design. Our design decisions were never arbitrary; they were strictly dictated by the mathematical limits of signal reliability and the engineering constraints of miniaturizing a mechatronic system into a ring form factor. Additionally, we didn't just pick a random ring size; the dimensions were mathematically forced by the physical volume of the ESP32 and the haptic motor. We didn't guess if the battery would last; we used power consumption modeling to prove that an 800mAh 3.7V lithium polymer battery was the most viable option. We ensured that the probability of a message failing was low enough to be trusted via signal reliability calculations.
Element F:
The comprehensive review of Project Aegis confirms that the design is not only technically feasible but carries significant market merit and ethical integrity. We identified and mitigated several potential failure points—such as false triggers and power management—and have refined the product to prioritize the high-stakes reality of its users. Our competitive analysis reveals a clear path to market disruption, offering a high-reliability alternative at a price point that significantly undercuts current industry standards and makes it viable for distribution in domestic abuse shelters freely. Additionally, the inclusion of a sustainable product development cycle ensures that the device remains responsible from manufacturing through to technological obsolescence. As we move forward, the focus remains on perfecting the "handshakes" between cellular networks and potentially getting a 3rd party attachment to the "Find My" ecosystem to eliminate dead zones. Project Aegis is confident that with continued iteration, this device will serve as a standard-setting tool in the realm of personal security.
Element G:
Overall, the building process of Element G was largely a success. However, our circuit design in Fritzing did not accurately reflect what eventually became our hardware prototype as we had to replace the bare-bones SIM7080G module with something more suitable to the 3.7V Lithium Polymer battery voltage. It took several days, too, to figure out how to "warm up" the GPS, and realized later that our wiring was slightly faulty. Our discreet personal safety device would yield real evidence of meeting its requirements as a reliable, independent of existing infrastructure panic button due to its lack of connection to the internet and how it operates via satellite triangulation. If we had to estimate the efficacy of this product, we believe that the device's latency will land somewhere within mere milliseconds. Additionally, if we had to guess further about the device's efficiency and battery life, it would land somewhere within 8-10 hours when used to its full capabilities. We hope in future iterations, too, we are able to cut down on data usage of this device to meet our affordability standards of <100$ as a one-time production cost per manufacturing of this device.
Element H:
The formulation of this testing plan represents a massive effort to lessen the gap between theoretical engineering and life-safety application. By focusing on the four critical vectors of GPS precision, database security, haptic feedback, and cellular propagation, we intend to create a device that prioritizes the user's physical safety and digital privacy above all else. These specific tests were selected because they represent the "primary failure points" of any emergency wearable; if the GPS fails to lock or the security is breached, the device ceases to be a tool for protection and becomes a liability. We expect these tests to yield results that confirm a high-speed system response, specifically demonstrating that an SOS signal can travel from a physical button press to a secure cloud server and then to a target handset in under 30 seconds. This expectation is rooted in the high-performance capabilities of the SIM7080G module and the optimized interrupt-driven logic of the ESP32, both of which were chosen for their industrial-grade reliability.
While this plan is comprehensive regarding technical performance, certain criteria, such as long-term battery degradation and structural durability (e.g., waterproof ratings or impact resistance), are not included in this current cycle. These were omitted primarily because the current project phase focuses on electronic and logical validation rather than mechanical environmental hardening, which would require specialized industrial equipment beyond the scope of a high school senior project. By narrowing the scope to the core communication and security pipeline, we can ensure that the fundamental technology is flawless before moving toward physical "armor" testing. The next logical phase is Element I, where we will transition from this theoretical plan into the actual execution of these procedures. During that stage, we will gather the empirical data needed to prove that Project Aegis is not just a concept, but a functional, secure, and life-saving reality for those in the Inland Empire and beyond.
Element I:
Overall, the designed prototype proved to work moderately well, performing with flying colors 2 out of 4 of our pass/fail tests. The specific design criteria that were met were GPS precision, GPS boot-up time, and number of satellites caught by our GPS. Additionally, information on our database was encrypted, entirely protected by backend ways, and the website communicated perfectly with our database. However, the device was unable to send an electric signal to our haptic motor driver as well as send a SMS message with a Google Maps URL embedded. In truth, this reveals plenty of the shortcomings of our project, but also leaves room for optimism; all the software components were working virtually perfectly, and all issues seemed to be on the hardware aspect and the inability to acquire the resources to reiterate this prototype in a way that passes all the tests, due to the expensive nature of acquiring more batteries and development boards to test, as well as our time constraints. The viable solution is proven in the software, and must be iterated more times in the future to make entirely viable. At this time, testing the durability of our product as well as water-proofing it is secondary to the overall efficacy of the device. Above all, we look forward to the next stage in our engineering process: presenting our project to a broad audience and receiving external feedback in Element J.
Prioritized Recomendations
Dedicate significant initial research to selecting a problem that maintains its relevance and personal interest over a long-term development cycle
Do not be afraid to be constantly networking; there are plenty of individuals with a unique, valuable perspective that could benefit your project
Understand GitHub repositories early to manage codebase iterations
Conduct exhaustive reviews of component datasheets and power requirements prior to buying them to prevent hardware incompatibilities
Cultivate a foundational understanding of web technologies such as HTML to better integrate hardware data with user interfaces
Leverage AI-assisted design tools, especially in the PCB layout process
Follow a strict "Breadboard-to-Perfboard" workflow to validate circuit logic
Focus on creating a functional product as early as possible to maximize the amount of real-world stress testing and refining
Anticipate unforeseen technical hurdles and allocate specific "buffer time" in the schedule to diagnose and resolve emergent hardware or software conflicts
Attain an extensive knowledge of how to properly solder joints
Conclusion
The engineering design process for Project Aegis has been a rigorous journey from conceptualizing an AI language-learning tool for deaf communities to a discreet safety solution for domestic abuse victims to validating a complex mechatronic prototype. Through the integration of STEM principles—ranging from mathematical power consumption modeling to the ergonomics of haptic feedback—this project successfully bridged the gap between theoretical research and functional application. While technical challenges such as hardware incompatibilities and GPS signal latency provided steep learning curves, the core objective remained intact: proving that an independent, secure, and reliable communication tool for high-risk individuals is a technical reality. Moving forward, the focus will shift from electronic validation to "Element L," where the project transitions into its final evaluation and reflection phase, marking the culmination of a year-long commitment to systemic safety.
For those embarking on their own engineering design journey, success lies in front-loading research and embracing iterative failure. We highly recommend dedicating significant time to selecting a problem with long-term personal resonance and maintaining an assertive troubleshooting mindset. Key technical lessons include the necessity of a strict "Breadboard-to-Perfboard" workflow, the value of early version control via GitHub, and the critical importance of exhaustive datasheet reviews to prevent component mismatch. In the future, Project Aegis aims to evolve by transitioning to flexible PCB designs and zirconia ceramic housings, ultimately seeking 911 permits and grant funding to provide these devices to domestic abuse shelters at no cost. The ultimate takeaway from this process is that engineering is not merely about building a product; it is about the persistent refinement of a solution until it meets the high-stakes needs of its intended users.