Explosive Schedule Reminder by Keith and the Rest: Final Documentation

Introduction

This project was a 7-week challenge to create a device that can provide assistance to a person living with a disability. We collaborated with Community Living and Support Services (CLASS), a local Pittsburgh nonprofit, to gain insight into the existing stage of assistive devices, proper methods and practices when working with clients that live with disabilities, and also to connect us to Keith, our client for the project.

Keith, our client, was a machinist who suffered a traumatic head injury, resulting in headaches, reduced mobility in his left side, and forgetfulness. Beyond that, he is a lovable grouch and has an appreciation for cheesecake. We documented our initial interview with Keith here.

What we built

Keith’s Explosive Schedule Reminder is a handheld phone-sized device that reminds him of his schedule. A screen on one side displays his upcoming scheduled event and a buzzer inside beeps when event is five minutes away from starting.

When Keith is at CLASS, he goes out for a smoke break. After he’s done, he’s having trouble remembering where he is supposed to report to. He grabs his reminder device and reads a display screen that says Math Class along with the location, time, and instructor. With this information, he is able to easily navigate back to the class on his own.

How we got here (prototype and process)

a. Prototype

 

These two prototypes were designed to help answer the design question: What form and user-experience considerations are suitable for Keith’s device?

The first prototype was created using a white board material and blue LCD screen, which cycles through Keith’s schedule every few seconds. The second prototype is fixed to a chipboard, and reads out a class description, as well as vibrating.

The first prototype was specifically intended to show Keith what the device we were making would look like, so that we could further understand what limitations he might have towards adopting this new device. Size, readability, and usability were paramount. The second prototype was intended to show Keith what alert features we could incorporate, between audio and haptic feedback.

Our strongest piece of feedback from Keith was that he didn’t particularly care about the device itself, but wanted it to be red and read “explosive” on it. It was a frustrating critique session because Keith wasn’t very enthusiastic about the device, but we were able to ascertain that he could not read the LCD screen due to low contrast, but did not mind the size and shape of the device we were making for him. The feedback gave us a direction to move forward, but was demoralizing due to Keith’s disinterest. We hoped that by customizing the device to his preferences, he may be more excited about his device. Something we got from Bill was that the vibration motor wasn’t as important as an audio feature. Keith may not carry the device on his person at all times, and also may be wearing too many layers to feel a vibrating motor. We decided to limit our scope and focus on audio instead.

b. Process

Initial ideation was inspired by Bill’s sharing of Keith’s schedule at CLASS:

We found out that Keith had a pretty static schedule (with the only variations being instructors or irregular meetings off campus like with CMU). However, we also discovered that Keith keeps his schedule crumpled up in his pocket. This inspired us to make a device that he can’t lose or destroy, which he can keep on his person to remind him of his schedule, as well as reading it out when a scheduled item is close. Here is the very initial ideation sketch we made:

Some process drawing on the scale and form:

Whiteboard sketching of early idea

We initially conducted all tests and prototyping with a sound shield for the Arduino Uno, hence the scale and lack of real prototypes in the first stages of the project

Working with the e-ink display upon switching from the LCD after Keith’s feedback:

Soldering pins to the Adafruit board after receiving it late in the process:

Bhairavi soldering pin heads onto the Adafruit board

The craft and creation for the housing of the device was the largest challenge outside of electrical components, as we want the appearance to be appealing to Keith.

Solidworks model

Progress tracker:

This is the chart we used to track our process. Unfortunately, we did not actually receive parts until Monday the 24th, which lead to a lot of technical difficulties in the final phases of our project. We planned throughout the project to add a voice feature to the device to remind Keith of his classes, like his Alexa does at home. However, given our size limitation, we sought out an Adafruit board and music-maker in order to achieve this. We hinged our entire project on this, and the fact that we received the board so late, as well as frying it the night before, caused us to end up incorporating a buzzer and Arduino Micro instead. This decision was made out of desperation, and ideally we would have had more time to actually work with the final parts together.

4. Conclusions and lessons learned

Our largest realization through the making of this process was that Adafruit parts are not reliable, and that we should’ve had more contingent plans in place instead of putting our final prototype together the week before. We experienced a lot of extraneous circumstances that prevented our final product from being as successful as initially intended, but ironically had stumbled upon a product that might’ve done Keith more good on accident.

One of the most repeated pieces of feedback we got with our device was that Keith does not need to keep his device on him at all times. It could, instead, live in his cubby all day and serve as a location to ground him. If he forgets where to go, he will always know to return to his cubby to look at the device’s screen. From both critique feedback and Keith’s own admissions, we realized the primary feature of the device should be the screen, rather than the voice reminders. If we continue with this line of feedback, we might consider investing in a larger screen so that Keith can read the screen from a longer distance, as well as having a pop-up stand that allows the device to stand up on its own. Additionally, we could consider installing a re-chargeable battery and a button to toggle between voice/buzzer states and a muted state. These are all features that are dependent on the primary function of the device, which change based on what role it might have in Keith’s life.

Something that we learned pretty early on was that Keith was a client that was pretty content with his life. His schedules and habits weren’t bothering him, and he wasn’t particularly enthusiastic about making any big changes. This made interviewing him difficult, as we didn’t have a great grounding point for him to focus on ideating or considering making changes. Something promising brought up during our final critique was how our “final” device felt more like a late-stage prototype. This final device could very well be a device that Keith incorporates into his life for a few weeks and gives us concrete feedback on, which we can then respond to and adjust for the next stage of the device. This could be a good step to take for Keith, or any candidate that perhaps needs something physical to actually try out, rather than just imagining, which we were having him do previously.

The one particular strength of our final prototype was the visual design, which was something we’d identified early on as a feature that posed extremely high value to Keith in his decision to actually adopt any new technology. Creating any device to “assist” in someone’s life is by definition rather invasive, so we saw making that transition as personalized and meaningful as possible as a primary goal for whatever our device ended up being. As such, we spent a lot of time talking to him about his preferences in terms of color and decoration. In the final critique, we discussed possible expansion points for this project, and whether it had any standing as a product on mass production. IoT and such. The device can be applied to a variety of settings that choose to stay phone-free, such as summer camps or hospitals. A head administrator can hard code schedules into a series of devices using a master device or app and assign them to people. For settings specifically like CLASS, customizability for each device is paramount and can be maintained in this model.

One last concluding tidbit to this story is the fact that Keith loved his device. He was absolutely blown away by it, even though it was not necessarily to the fidelity that we had hoped we would be able to present. It just goes to show how much customizability matters when creating personalized devices, and would likely increase the device’s effectiveness tenfold (if we actually got it to work).

5. Technical details

a. Schematic and block diagram

Original Block diagram:

 

Final Block Diagram

Block Diagram of final project

Schematic of our final project.

 

b. Code

// Keith's Explosive Schedule Reminder
// Team Members: Ethan Xu, Bhairavi Chandersekhar, Caleb Sun
// Code displays upcoming event information for Keith on an Adafruit ThinkInk e-display, as well as buzzing 5 minutes before an event

#include <RTClib.h>
#include <Wire.h>
#include "Adafruit_ThinkInk.h"

#define EPD_CS      9 // white
#define EPD_DC      10 // purple
#define SRAM_CS     6 // brown
#define EPD_RESET   8 // can set to -1 and share with microcontroller Reset! // RST blue
#define EPD_BUSY    7 // can set to -1 to not use a pin (will wait a fixed delay) // BUSY blue

#define buzzerPin 18

RTC_DS3231 rtc;
char t[32];
int h;
int m;
int d;

// 2.13" Monochrome displays with 250x122 pixels and SSD1680 chipset
ThinkInk_213_Mono_BN display(EPD_DC, EPD_RESET, EPD_CS, SRAM_CS, EPD_BUSY);

void setup() {
  pinMode(buzzerPin,OUTPUT);
  Serial.begin(115200);
  while (!Serial) { delay(10); }
  Serial.println("Adafruit EPD full update test in mono");
  display.begin(THINKINK_MONO);
  rtc.begin();
}

void testdrawtext(const char *text, uint16_t color) {
  display.setCursor(0, 0);
  display.setTextColor(color);
  display.setTextWrap(true);
  display.print(text);
}

void loop() {
  //setting up RTC module
  DateTime now = rtc.now();
  sprintf(t, "%02d:%02d:%02d %02d/%02d/%02d", now.hour(), now.minute(), now.second(), now.day(), now.month(), now.year());
  h=now.hour();
  m=now.minute();
  d=now.day();

  if((h==9) && (m==25) && (d=="Tuesday")){
  bitClear(DDRD,5);
  bitClear(DDRB,0);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  display.clearBuffer();
  display.setTextSize(3);
  // spaces in testdrawtext are for center-aligning text; have to be done manually
  testdrawtext("    Math       at 9:30AM     Room 111   w/ Genevieve", EPD_BLACK);
  display.display();
  }
  //delay of 5 seconds is to serve as safeguard against e-ink display frying if updated too quickly
  delay(5000);

  if((h==10) && (m==55) && (d=="Tuesday")){
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  display.clearBuffer();
  display.setTextSize(3);
  testdrawtext("    Lunch      at 11:00AM    Room Main   w/ Courtney", EPD_BLACK);
  display.display();
  }

  delay(5000);

  if((h==11) && (m==55) && (d=="Tuesday")){
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  display.clearBuffer();
  display.setTextSize(3);
  testdrawtext(" Stress Mgmt   at 12:00PM    Room 111   w/ Michelle", EPD_BLACK);
  display.display();
  }

  delay(5000);  

  if((h==12) && (m==55) && (d=="Tuesday")){
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  display.clearBuffer();
  display.setTextSize(3);
  testdrawtext("    Music      at 1:00PM     Room 111    w/ Maggie", EPD_BLACK);
  display.display();
  }

  delay(5000);

  if((h==13) && (m==55) && (d=="Tuesday")){
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  digitalWrite(buzzerPin,HIGH);
  delay (300);
  digitalWrite(buzzerPin,LOW);
  delay (200);
  display.clearBuffer();
  display.setTextSize(3);
  testdrawtext("  Wii Games    at 2:00PM     Room 111      w/ Bill", EPD_BLACK);
  display.display();
  delay (5000);
}
}

c. Design files

Keith Stl Files