Team Status Report for 2/21/26

What are the most significant risks that could jeopardize the success of the
project? How are these risks being managed? What contingency plans are ready?

At our Design presentation, we received helpful feedback from the audience that exposed additional risks in our product.  The first was what will the pill box do when the wrong pill is dispensed?  We had already established that we would use the weight and motion sensors to make sure the correct pills are dispensed.  So when we know the wrong pill/number of pills were dropped, we send a warning to the user through the app that that dosage is incorrect.  Yet we still need to think about the next steps.  What will the user do with the pills? How will the box be reset? We plan on having it so that an alarm will be set up on the app within a set amount of time (for now, we aim to have the user set the time in the app as medications vary in terms of within how much time it should be taken in), warning the user or their caregiver to take the pills and reset/re-allocate the pills as necessary.  Another question we received was how we will test if our pill box works, since our target audience is elderly people with dexterity issues.  We plan to contact some elder care facilities to see if any volunteers would be willing to test our product.  Or if the staff at the facilities can give us feedback on our project as well.

• Were any changes made to the existing design of the system (requirements,
block diagram, system spec, etc)? Why was this change necessary? What costs does the change incur, and how will these costs be mitigated going forward?

We have made the change of going from using a FPGA and ESP32 microcontroller to using two ESP32 microcontrollers for two main reasons: firstly, we did not want to overcomplicate the process as the communication between two microcontrollers would be a challenge in itself to have an almost perfect accuracy rate, and secondly, for bluetooth, there is a more reliable ESP-NOW protocol available for communication between two ESP32s, which would allow for cleaner and less error-prone connections. This would actually lower the technical cost of our project as a FPGA is much more costly than an ESP32 Arduino Nano (which is the specific microcontroller we wish to use for this project for both size and price).

• Provide an updated schedule if changes have occurred.

Our schedule remains the same as a whole.

Leave a Reply

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