Posted on

Carolyn’s Status Report 3/14/26

I finalized our parts list based on our design and put in most the the parts orders.  I also reviewed our feedback from design presentation and worked on filling the gaps that were addresses.  This primarily consisted of doing research to justify some of our design choices, or deciding they were unjustified and removing them.  I have also been working on the laser cutting file for our design.  This has been going through much iteration, But I believe the work is worth it as it is the whole structure of our project and without a proper structure the mechanical components will not function correctly.  Part of this process has also been maping out the exact measurements needed to satisfy all out use cases.

We are generally on schedule but we need to be making significant progress leading up to the demo.

If the acrylic comes in time I hope to print out the pill box design and assemble it.

 

Posted on

Jahnvi’s Status Report for 3/14

This week  I focused on planning the software side of our project which is the app for the system. I relooked at the main features we need the app to support namely medication setup, scheduling, reminders, dose logging and displaying the next scheduled dose. A major part of this week was comparing the different languages and framework options for the app. Initially, I was considering using Flutter. However, after weighing development speed and ease of use as well as what would fit our capstone timeline best, I decided that Typescript with React Native and Expo is the best choice for our project. This kind of stack would allow the app to support cross-platform development and do all the things it need to be able to do.

I also planned the order in which the app is built so that I can focus on the features that are most important. I created a personal schedule in order to stay on track for the interim demo. I also outlined the MVP around the core workflow which is medication setup, home screen, next dose display, reminders and dose logging.

Based on this, the first thing I will start building is the basic app structure. I will begin setting up the project on VS Code, creating the main screen skeletons and building the medication setup flow.

In terms of the overall schedule, I think there is enough time for our team to build all individual components as assigned in order to have something concrete for the demo.

Posted on

Team Status Report 3/14/2026

Our biggest risk at this point is whether our software end will be able to mesh well with our hardware design. We have spent a significant portion of our past few weeks focusing on the hardware aspects that we weren’t able to expand thoroughly enough on the software portion of our project, a point our professor kindly pointed out to us. Currently, our software lead is focusing on expanding on the software mapping that was done in the design presentation but left out in the paper so that we have a clearer idea. There has also been more brainstorming and ideas presented during our meeting so that we have a much more clear/solid plan for how to tackle the wireless connection between the app and the hardware/device by using WiFi + MQTT. We will continue to communicate after hardware is completed with inner-communications and try to start early (so a bit before the interim demo, we should be trying to connect our separate but working systems together so we can deal with bugs earlier than later).

No huge changes were made, except for the hardware end- instead of piling all the signals control to one microcontroller, some signals will be handled wirelessly from the other microcontroller by adding on the initial packet that originally only contained the counter/servo information. This would make it easier to debug if we divide between the two so that we won’t be creating an overly complex hardware design system on just one microcontroller. No costs will be incurred due to this change, though.

No changes have occurred to the overall schedule, except we will individually will be working on getting done with a prototype of our respective areas by the end of the week so we can start debugging or helping others who are more behind.

Posted on

Jieun’s Status Report for 3/14/2026

This week has been hectic due many time conflicts, with it following right after spring break, however a new personal schedule has been made to tackle all objectives before heading into our first demo. We were told that we needed to get our individual portions working, and therefore so far there is a working servo code, as attached below. I also worked on organizing and helping to order the main hardware parts which we will need for testing later. I will be continuing to work out the bugs as well as make a final decision on the design between the two microcontrollers: originally, our plan was to make it only have the main ESP32 handle all hardware signals, with just counter calculation being done in the other ESP32. If we run into issues regarding the complexity of the packets being sent due to ESP-NOW in the near future, this split will be undone and the potentiometer reading will be directly inputted into this RX ESP32. I’m moving forward into researching whether stepper motors can be addressed in the same way and going to move into individual testing. Overall hardware design is, however, similar to last week’s photo/design.

I am currently a bit behind as I don’t have the parts that we need to build the actual prototype yet and working with, as noted last week, a significantly weaker servo motor and potentiometer/ESP32s from either loans or personal collection. However, I will be catching up through lab work in the upcoming days.

I already am researching about the stepper motors, and starting on the code for it, but hope finalize coding and to be able to start testing with our ordered parts when they arrive. By the end of next week, I should have a completed hardware prototype in one way or another with the corresponding code.

Posted on

Team Status Report for 3/7/26

The most significant risk to our project currently is the possible mechanical errors of the retractable door.  This is the most mechanically complex portion of our project.  We need a sliding door on each compartment that will let only one pill fall down at a time.  The timing and force need to be accurate to be implemented properly.  To make sure our design will be functional, we are going to make two prototypes of sliding doors before implementing it in our pillbox.  The two designs we will look at are the lead screw + nut design and the timing belt design.  We will see which one works most reliably and then look at which is easiest to implement.  Based on the results, we will choose one design for all the sliding compartment doors in our pillbox.  Our contingency plan in the case we are not able to get the sliding doors to allow only one pill to drop at a time is to have the user place all the pills for one day/time together in one compartment, so when the day/time comes, all the pills in a particular compartment can be dropped into the collecting tray.

One change we have made to the design of the system is that we are no longer basing on average pill sizes and are instead using pulsing to ensure that only a singular pill drops at a time.   Originally we were going to base it on average pill sizes so a specific sliding door knew how much to retract based on the pill size contained in the compartment.  We realized this adds too much complexity in the setup of the pills for the user.  Additionally, we no longer believe this will aid in ensuring only one pill is dropped at a time since there will still be variation within each group of pill sizes.  We believe pulsing is a more robust solution for all the varying pill sizes.

Originally the size of the pillbox was made to accommodate the largest average pill size we were looking at.  Now, the size of the pillbox has been updated to accommodate a 90-pill supply of the largest pill size.  The width of the pillbox was also limited in the amount of tabletop space that the pillbox takes up to be comparable to unautomated pillboxes on the market.  The cost of this change is that the pillbox will now take up more vertical space.  The more vertical our design, the higher the risk of tipping over; to mitigate this, we will have a weighted base and anti-slip base, which will be a high-friction rubber or silicone pad.  Additionally, we will have keyhole slots on the back of the pillbox so it can mount to the wall (still “on a shelf” but optionally fixed.)

Another change is we will use Wi-Fi + MQTT via a broker instead of Bluetooth, as our design study showed it to be more reliable for its remote caregiver access and clean sync model.  The cost of this change is that it creates an additional requirement for the user to have Wi-Fi, as well as requiring more infrastructure like brokers and authentication. However, we would assume that if a user were to want to be a user of our product, which requires electricity (we do not plan for a battery design), they would also have access to WiFi.

Below is our updated schedule.  Primary tasks of each person have reminded fixed, but individual tasks have been adjusted according to design changes.

Part A: Global Factors, written by Carolyn

Our pillbox is for older adults who have trouble managing multiple prescriptions.  A challenge faced worldwide as we face aging populations.  By operating in both online and offline modes by storing schedules locally and providing alerts on the pillbox itself we are ensuring our product can still be used in locations with unreliable internet connection.  Which is a common global concern.  Additionally, we are designing the physical interface and guided workflow to be as simple and intuitive as possible for the user to make the devices accessible for those who are not technologically experienced.  Furthermore, prescription pill access can vary based on locations.  Certain users may have to travel far to access their nearest pharmacist.  We do our best to accommodate this by supporting high-capacity storage.  Which should limit pharmacy visits to once per month ideally.  This allows the device to remain useful in areas with limited healthcare infrastructure.

Part B: Cultural Factors, by Jahnvi

Medication routines are often heavily shaped by cultural beliefs, specifically norms regarding elder care.  In many cultures older adults rely heavily on family members for there medication needs.  Which is why Magic Pillbox supports and allows for caregiver involvement, specifically through the app where issues and taken status are logged.  Furthermore, many elders show distrust of advanced technology.  Respecting this preference, we ensure that our pillbox is fully operational offline, except for setup steps, which should have to be carried out no more than once a month typically so they can be carried out by a caretaker if needed, instead of the primary elderly user. This allows the primary user to have minimal interaction with the app if desired.  We use audible and visual reminders on the box itself for this.

Part C: Environmental Factors, written by Jieun

In consideration of environmental factors, our pillbox is extremely careful in trying to minimize the material used, as we do aim to build our main body with plastic, which has already been flagged as a potential environmental harm in terms of disposal should the product be defective, etc. By carefully discussing and simulating the design as much as possible before creating the main prototype, we can minimize the plastic material used in total. This applies even after initial prototyping; should our product or a similar design ever make it into the real market, minimizing the overall size also minimizes plastic and electronic waste. We will also be avoiding including designs that can create choking hazards should there ever be an improper disposing of items (which we will, of course, try our best to never let happen in the first place by including instructions and also being careful on our own end). The one cup holding that can be separated from the main device is designed and will continue to be looked at so that it’s large enough to not be a potential choking hazard but not too large as to incur greater waste.

Posted on

Jahnvi’s Status Report for 3/7/2026

This week I worked on feedback based on our design presentation. We were asked to think of better ways to connect the pillbox and phone as well as look into more edge cases. The biggest change that we made to our design was switching from Bluetooth to home wifi using a REST API on the ESP32. I thought this change would be more straightforward and reliable for communication. Along with this, I also clarified online vs offline mode behavior. In online mode the app and pillbox stay synchronized with schedules and logging. In offline mode, the device continues to operate using a cached schedule and on device LEDs and buzzers. This allows dosing to be supported even when there is loss in connectivity.

Additionally, for multi-med doses, the device dispenses them into a single tray. If an error occurs, the entire dose is retried to avoid confusion. This was another edge case consideration.

We are a little behind schedule as we needed to already have the parts to build the box as well as have the app in the works. I think post spring break, we will use the week to catch up with our timeline and be on track in the coming weeks.

Posted on

Jieun’s Status Report for 3/7/2026

For this week, the main focus was figuring out how to manage the signals  between the 2 ESP32s by the ESP-NOW protocol. There was also research done to see if the ESP-NOW protocol was enough to handle the proposed signals from our design review, which was another crucial part to this week’s update: I wanted to follow the feedback we got as well as write out the full report with the new updated information. I created a new updated diagram with our proposed design in order to better fit what we now want to create as our pillbox, along with corresponding datapath. Based on this, it is clear that the ESP-NOW is not enough, but it would be useful for individual testing as part of our prototype process. I am and continuing to look at the alternative Bluetooth option provided for the ESP32 Nanos. It was also important to gather the material I do already have in my possession for simulation and testing with first the fundamental proposed materials that we have for our overall project on the electrical end.

Progress is behind on ordering the parts, but that will be handled as soon as we are back online from break. The time-heavy portions would be the mechanical and coding parts for both hardware and software, so actual manufacturing/combining of all parts is set later as a priority in comparison.

I will start by creating a prototype with just the electrical components (some of which aren’t going to be official parts), starting with a basic servo (as depicted below) connected to a ESP32 so that the servo-testing can commence with wireless connection using the ESP-NOW protocol first, then shifting over to the bluetooth feature already included on the ESP32 Arduino Nano which I already have in my position to see if there would be a greater efficiency than the simpler ESP-NOW protocol which can’t handle complex data packets.

Here is the image of a personal ESP32 Nano Arduino with a test-use servo (no where close to the 20kg, but the connection works regardless).

updated datapath:

updated diagram:

Posted on

Carolyn’s Status Report 3/7/26

This week, I focused on refining the mechanical dispensing system and updating several core design elements.  I fleshed out our sliding door feature on the pill box.  I came to two possible solutions that will be most reliable lead screw + nut design and timing belt design.  After reevaluating our sliding door feature I wanted to pivot away from casing on average pill size.  Originally we did this so a specific sliding door knew how much to retract based on the pill size contained in the compartment.  Yet it would not account for all the possible pill sizes negating our use case, as well as I believe not being much more accurate as there is still variation in the pill sizes in each size group.  Instead I proposed pulsing would be better fit for handling all the different pill sizes accurately.

Since we had gotten rid of the average pill size casing we now needed to accommodate all possible pill sizes, so the pill box size needed to be adjusted accordingly.  An additional constraint that I added based on the feedback of the professors was to limit the size of the pill box based on the size of pill boxed currently on the market.  The most valuable space that our pill box would take up is table top space, so I specifically limited the width of the box on the table based on market research.

Another piece of feedback we received was to account for humidity causing pills to stick together, to counteract this I added airtight compartments and silica gel packets in each compartment to the design.

Based on the design updates we made I updated the individual tasks in our schedule.

I also made our parts list along with specific vendor links.

Using the constraints on pill box size identified above I conducted a design trade study to identify the ideal height of the pill box.  Illustrated in the graph below.

Finally for our design report I was responsible for writing the quantitative design requirements, design trade studies and project management sections.  I reviewed and edited my partners sections before the final submission.

We are on schedule for everything except ordering parts.  Now that I have accumulated the parts list I will start putting in the orders soon.

In the upcoming week I hope to make prototypes of each of the sliding door designs to identify the best solution to implement in our pill box.

Posted on

Jahnvi’s Status Report 02/21

This week I designed the full app layout and created visuals for the design presentation. The app flows like: sign-up/login to guided medication set up to homepage showing next dose and quick status. The app also has a logs and calendar feature to review taken vs pending doses and adherence history. Added a lightweight motivation progress tracking feature and defined notification behavior. Additionally, I identified some key risks with our system and mitigations for them. This touched upon multiple pills dropping at the same time, no pills dropping due to low pill count and weight sensor drift. Also, I refined our key user use cases and distilled them into 5 clear, testable use case requirements that the pill box must support. Lastly, I presented our updated design in the capstone design presentation.

We are slightly behind schedule because our design plan changed a lot over the past few weeks. This next week, our priority is to finalize and lock the design so we can start ordering parts and building immediately. I am aiming to begin app development soon, while we can catch up on the items we are behind on. We definitely need to get back on schedule so tasks dont pile up later

Posted on

Carolyn’s Status Report for 2/21/26

I have been working to update our design based on the feedback we have received from our design presentation.  We need to figure out how the user will reset the device when there is a misdropping of a dose.  I will continue working through this with our TA and prof during our upcoming meeting.  For now, we will set an alarm in the app if a dosage was dropped incorectly which will instruct the user to take the dose out of the tray for it to be readministered.  I also made a diagram of our proposed pill box design.

We are mostly on schedule.  Yet we are a bit behind schedule for ordering the parts our project will need.  I didn’t realize how much we would tweak our plan after every meeting and presentation, so the exact parts we need have been continuously changing.

Next week, I plan to make updates to the laser-cutting file design for the box and print it out.  So we can have the physical pieces as soon as possible.  As well as finalize parts lists and put in orders.