-
Project architecture
Inspiration
The inspiration for this project goes as follows:
Doctors need a way to regulate the medicine (pill) consumption of patients, especially in situations such as Alzheimer's disease where patients could forget to take pills reliably.
An ideal solution would both remind patients to take their medicine, dispense the medicine, and send regular reports to practitioners automatically
What it does
Our solution automatically dispenses pills to the patient at regular intervals as set by the practitioner through a easy-to-use portal that can be opened in the practitioner's browser.
The patient gets a SMS notification via Twilio when they are supposed to take a pill. There is only one dosage of pill available at a time so as to avoid confusion.
The practitioner will receive regular updates regarding the number of pills prescribed to the patient and the number that they have taken via fax and email.
How we built it
We used a combination of hardware and software to create our solution (which you know because of the makeuoft rules). First: everything runs off of a Raspberry Pi (getting WiFi set up in the uoft mschva2/PAEP environment was a challenge in and of itself and warranted the brief trial of multiple other development boards).
More specifically, we built a server with a functional REST API and Django database. The Django database provides the option to add (up to 21 in the demo) medicine types to be dispensed every hours for different patients. In order to do this, when the database is updated, Django calls a callback that registers various cron tasks corresponding to when each pill is dispensed. In addition to this, there is an algorithm in place here (the code that registers the cron jobs) that ensures that there are no collisions in the timing of the release of the pills, while still keeping multiples of exactly one hour in between the dispensing of each pill.
When the cron jobs are triggered, they make a call to the Twilio Rest API, sending the patient a reminder to take their medicine while simultaneously running a compiled C executable that drives a stepper motor to spin to a specified position given a saved previous position. The C program reads from a photo transistor to determine if the patient has taken their medicine before the pill gets shuffles away back into the enclosure and saves the previous slot and status of taken/not taken to a file. The python that has triggered the C code, at this point as waited a specified amount of time and reads from the file that was written to by the C program with data from the device. The python script then sends a POST request to the REST API attached to the Django database with the data collected from the mechanism.
The database stores this data and a cron job scheduled for midnight every day makes another POST request to the database what retests that the database creates a host of .txt files that can be parsed into emails and .pdf's by a .jar file that is also run in a cron job. The .jar file then sends the parsed information to the practitioner's email and the pdfs via Twilio to the practitioner's fax machine with a daily report of the patient's medicine history.
Challenges we ran into
One of the biggest challenges, and not easily surmounted without loose paper (which we didn't have because no one brought any), was communication between parts. Since each of us specialized in a separate part of the development line, with code written in Java, C, Python, and even Assembly at points, there were many, many different APIs that we all had to keep track of. As we rapidly added functionality, the APIs continued to change, causing a cascade effect through the different parts of the application. On top of this, each of us was constantly developing out code, each of which preformed instrumental parts tasks
Accomplishments that we're proud of
We are particularly proud of our ability to implement such a complex solution in such a short time period. Especially with so many moving parts and the fact that, as uoft students, all three of us are in out first year. Furthermore, we had to cope with not sleeping, which made it nearly impossible to communicate ideas as quickly and effectively as we normally would.
What I learned
One of the biggest things that we earned as a team is that writing things down and drawing diagrams of our solutions of the interactions between the different APIs made it significantly easier and faster to develop out solution as there was significantly less room for confusion.
What's next for IOT-Automatic-Pill-Dispenser
- Primarily, and something that we are nearly 100% prepared to implement, is the integration of the Google assistant API. We have all of the REST endpoints set up in order to integrate the assistant for the practitioner and for the patient, but failed to create a reliable http tunnel from the Pi to the internet in order for the Google assistant to make GET requests to the Pi with completed intent statements.
- We would add a pill tank that would integrate with the pill dispenser to make the solution longer term and more practical for the field
- We would make it easier to input data, yes, easier than entering it into a Django database from the provide web page
Log in or sign up for Devpost to join the conversation.