Smart Dose

Front of our PCB
Back of our PCB
Finished PCB
Our Node Red Dashboard
Early Scheming
Early Scheming
Early Scheming
Full Assembly in Solidworks
Finished assembly

Inspiration

We were inspired to make a smart pill dispenser due to having relatives that could really use to be reminded to take their medication and monitored accordingly. This led to discussions on how pill boxes are a pain to load every week and merged with some absolutely terrible Nickleback lyrics to blossom into the awesome build idea that is Smart Dose.

What it does

Smart Dose at its most basic is an easier way to take your medicine on a schedule, without manually loading a pillbox.

Conventional smart medicine dispensers either require preloading by the user, or are giant bulky countertop units that you can't travel with. We're trying to bridge that gap with a "simple" PEZ dispenser style design. This won't work for all medications, but provides a clean solution for hard pills.

Smart Dose enables healthcare providers to control the schedule around addictive or controlled medication.

Smart Dose provides an interface to healthcare providers to choose when a device dispenses. This is incredibly helpful for patients on judgement impairing substances

Smart Dose provides more independence for the elderly, while giving peace of mind to those who care for them.

Smart Dose's internet connectivity can be used to track pill dispenses over time, and optionally alert via the webapp if a user has stopped taking their medication. This automates a roll of traditional senior caregivers monitoring patients who might forget their medicine or dosage and provides functionality that a traditional loaded pill dispenser does not.

How we built it

Smart Dose Consists of a custom PCB with drivers for individual solenoids to operate Pez style dispensers and open a door locking solenoid. We started by gathering features and requirements around sensors. From here we mapped pins on the microcontroller, determined power requirements, developed a CLI, developed boost and buck circuits for the power we needed, designed the PCB, wrote a custom bootloader and OTAFU implementation, and then used node red and MQTT to give it a web app dashboard for control.

Our final sprint wound up rewriting a lot of the application itself as well as the overall node red flow to get basic functionality working in time for submission.

Challenges we ran into

Circuit Challenges

As typical for a build we hit snags along the way. Our biggest setbacks were related to us not testing circuits via breadboard before we implemented them in Altium for the PCB. As a result we had to use a perfboard for the inductor driving circuits with some extra GPIO pins we pinned out. We're definitely grateful to our previous selves for adding those.

Additionally, the footprint for one of our inductors turned out to be wrong resulting in solder mask covering the pads. Two boards had to be reworked, the soldermask scraped off and the inductor hand soldered on. This proved to be fairly difficult with how much heat the large pads could sink and the bad connection gave us trouble all the way up to the demo.

Mechanical Challenges

Neither of us had a lot of mechanical design experience. In fact, we didn't realize there was an entire subset of design in the category of mechanisms. As a result, bringing the device into reality via rapid(or in the case of the UPenn 3dprinters not so rapid) prototyping was a definite push. Given that this was the first semester working with Solidworks and/or laser cutters for both of us we were really happy when the mechanism worked. That being said, it's still not exactly travel sized and only works with a gravity feed.

Software Challenges

Neither of us have much javascript experience so working with node-red and its desire to make everything and anything a string was an exercise in patience. We wound up opting to put a lot of the functionality back onto the board.

Additionally, due to the complexity of the project and the amount of time given we weren't able to properly implement the RTC on the device with a full on schedule.

Ordering the right parts for the Job

The solenoids we wound up with did happen to have the right throw, but unfortunately are huge. This definitely made some of the mechanical design a bit harder and prevented us from packing into a smaller form factor. We also realized later on that locking solenoids are items people sell off the shelf. A quick order from amazon saved us an incredible amount of 3D printing.

Our IR sensors that we had planned to use to track the number of pills either via distance or broken beam turned out to not work in such a tight space. We're simply using software to track pill count for the time being, but had a number of ideas to implement this if we had more time.

Accomplishments that we're proud of

We're really proud of the mechanism and the fact that it actually dispenses multiple pills only jamming on occasion. It feels awesome to control it from the web, and we know that the device works as a proof of concept.

Although we didn't have time to implement the logic behind locking and unlocking the device, the fact that Node Red has a b-crypt node that let us push the hashed password to the device felt awesome to implement.

What we learned

We learned that iterating early and often helps. If we had more mechanical prototyping experience earlier in the semester, we would have been able to pump out prototypes earlier to test with the devboard instead of wrestling with stubborn printers towards the deadline.

We also learned that somehow the Hackathon finishing sprint still accomplishes an incredible amount of the project. With the next project hopefully we can plan more of these pseudo sprints earlier.

What's next for Smart Dose

All the functionality!

We had a hard time preventing feature creep on what should have been a relatively simple idea. Using some sort of linear pot or simple linear encoder on the pill stacks would help us keep track of pill counts and implement our early idea of using an IR sensor.

Additionally actually having the time to flesh out a fully structured schedule around a prescription and leverage the RTC on the microcontroller would make the device immediately usable from a software perspective.

From there, the feature creep explodes as ideas for adding vital checking sensors to the device, fingerprint scanners for authentication, and bluetooth for connectivity outside of wifi all come into play. Bluetooth is probably highest priority, but requires a mobile app.