Our three biggest concerns and risks are:
Risk1: ensuring the pills are dispensed with no waiting at the scheduled dose time.
Mitigation: For the timing, we are aiming to manage it through having our system simply start a couple of minutes ahead of the arranged consumption time.
Risk2: defining the caregiver’s goal in a way that does not create a reliability dependency
Mitigation: Missed dose handling will first prioritize on device alerts to the user, and only use a caregiver notification when a phone connection is available. We aim to research even further on prior medical reports/data that is available to the general public, etc., so that we can get an accurate measurement of how often our target audience requires consumption, so we can have an exact number of pills our device should be supporting in total.
Risk3: ensuring the device continues to dispense, alert, and log doses even when the phone/app is unavailable.
Mitigation: for the separate functionality of our device, we are going to research further into having an offline server (though this might be another obstacle on its own as none of us has strong server creation experience ) for our device as well as experimenting further with our microcontrollers and FPGA along with more basic circuit additions (such as a button or LED) to see whether we can simply store data and coding that functions without an outer signal.
Design Changes:
As mentioned previously, the system may need to have additional circuit elements, such as a button, buzzer, and LED, in order to have the offline functionalities that we wish to include in our new and finalized MVP, which we aim to have by the end of the weekend. There shouldn’t be a big change in total costs, as those materials are extremely cheap, so there are no worries about cost mitigation on this so far.
Schedule Update:
Our schedule still remains the same, except for the additional goal of having a finalized MVP by the end of this weekend (so by the end of 2/8/2026).
