Posted on

Team Status Report for 4/4/2026

The most significant risk is the integration of hardware, mechanical, and software. We weren’t able to fully integrate it all in time for interim demo, focusing instead of finishing critical individual parts. Though it still fits in our timeline, this means that we need to stay extremely on pace till the final presentation. We will first remedy the missing parts we discovered during the implementation process, taking time over carnival to do so, and then we will move forward into the integration and testing process.

For testing, we will be first testing individual processes, running trials on each component (ie. schedule signal generation from software app, sensor detection integrity/accuracy from the circuit’s end, and door opening accuracy for mechanical, etc.). We will be putting all of our individual testing results into a google spreadsheet and calculating the average accuracy. As of right now, the idea is to organize our results into quartiles so we know which aspect to focus debugging/improving first.

Changes made are that we are currently working with a web app for software for now, stepper motor is no longer being used as it is not compatible with the ESP32, additional power sources were needed as the servos drew way too much power for one breadboard supply to handle, and we require more acrylic due to the newer design being larger than expected. These costs are being mitigated by being more cautious with our calculations before implementing them to conserve material (nothing should break).

Our schedule is around the same.

Posted on

Jieun’s Status Report for 4/4/2026

This week, I have gotten the servos to work and waiting on getting our new power modules in order to have enough power for all 7 servos to work with incorporation with the app. The motion sensor is now fully implemented with the servos as well as the LED indicator. I also created some rudimentary files with the ESP-NOW protocol as I realized that one Arduino is certainly not enough due to the limitations on the GPIO/Digital pin allocation. Moving forward, there will be two Arduinos with the main arduino programmed with the still-testing/developing Bluetooth module IDE code.

For testing, I put into my code print statements showing when the pill is supposed to be dispensing. This will be first tested individually with the two type of sensors we are using: first, for the motion sensor, it will be tested by having various pills fall in front of the sensor and marking whether or not the serial monitor prints out that it was dispensed. This trial test will take place at least 50 different times so that a percentage of correctness can be calculated. It has already been briefly tested a total of 20 times in one trial run, with 12 out of 20 hitting correctly. Sensitivity will be adjusted, and hopefully with the weight sensor implemented, the overall accuracy can be improved on whether a pill dropped is correctly detected or not.

Progress is behind on the strain gauge end- we’re still waiting on the part arrival but will be working Monday which is when we expect to have them. Otherwise, everything is on track though it would be impertinent to fast forward a bit on the integration as currently we don’t have the mechanical part integrated either.

I hope over carnival I am able to finish the full hardware implementation with all 7 servos, which shouldn’t be too difficult considering how one set of motors is fully working, along with the weight sensing mechanism, which is the bigger challenge but also isn’t as difficult as our final step: integrating the hardware with the software app.