Our team’s design proposes a solution for regularizing Yale Cohen’s eating schedule. During our first discussion with Yale, we discovered that he has lived with an odd eating schedule for most of his adult life, and currently, he also has a problem with snacking.

Following our learning of Yale’s love of puzzles and etymology, we have created a device that powers on during mealtimes in Yale’s corrected eating schedule. If Yale puts the plate or bowl he ate his meal in on the device’s sensor during the this time, it will reward him with a puzzle or etymology related question. Essentially, we are creating a device that uses a reward system to entice Yale to eat at the times he defines as acceptable.

Our project can be divided into two main devices, the task sensor and the reward puzzle. For each of the two devices, we decided to build an ergonomic prototype and an engineering prototype.

Task Sensor

Ergonomic Prototype

This prototype was made to answer the question of how the device is interacted with.  This prototype was made with paper, pencils, and chipboard. The front-facing panel of the prototype contains the screen, which is simulated with stapled sheets of paper, small buttons, represented by small colored pieces of paper, and control knobs, represented by pencils. On the right of the device is a cardboard surface meant to represent where our client might put his finished plate or bowl after eating.

Still Images

Overall view of Device

Cardboard “Sensor Plate”

Close-up of paper “LCD Screen”

Moving Image

Gif of my mom interacting with the prototype

Process Images

Inserting pencil “potentiometers.”

Sketch of concept

Screenshot of work-shopping some display messages.

Reflection

The purpose of my creation of an ergonomic prototype of our device was to ascertain if the device would be confusing visually. I wanted to know if the overall parts of the design, the interactive interface component and the sensor plate were designed in a clear, distinct, and intuitive way;  additionally,  I wanted to do an investigation into what makes a strong component layout. After demonstrating my device to my mother, I found that my design of the interface and sensor as an integrated device was intuitive. The low flat surface of the sensor plate made it a clear surface onto which the user of the device could place their dirty plate or bowl after they eat. She also informed me that the LCD messages were clear in their meaning and sequence in response to recognizing whether or not the  user has eaten and in giving a puzzle as a reward.  However, she felt that while the layout of the buttons and knobs were visually appealing and organized, the amount of components as well as their close proximity to each other made for an un-intuitive interaction.  This point was reiterated within our Team’s discussion with Yale following our presentation on April 6.

All of the feedback I received was essential to improving the team’s design of our device. As such,  I do not plan on ignoring any of the feedback I was given. In response to the feedback, one of my primary concerns currently is improving and distilling the layout of the interactive components so that they are intuitive and easy for Yale to use.  The feedback I received in response to the prototype was expected and incredibly useful, and I hope to utilize it to move forward with our design in a positive direction.

Engineering prototype

The engineering prototype was designed to describe the placement and the functionality of the ultrasonic sensor to detect the positioning of the plate. The prototype consist of five (5) major components : arduino board, breadboard, buzzer, ultrasonic distance sensor (to sense the distance of the plate), and the 16 x 2 liquid crystal display(lcd).

Still Image

Overall circuit design

Buzzer

16 x 2 lcd

Ultrasonic distance sensor

Moving Image

The video shows how the circuit works: The sensor first senses the distance of the plates to the sensor. If the distance is less than 20cm, and the timing of the object is (in this prototype scenario) less than 10 secs, the buzzer buzzes and displays a message on the lcd to remind Yale to wash his plates.

Process Image

Design sketch

The videos below showed the critiques from two people.

/*
  LiquidCrystal Library - Hello World

 Demonstrates the use a 16x2 LCD display.  The LiquidCrystal
 library works with all LCD displays that are compatible with the
 Hitachi HD44780 driver. There are many of them out there, and you
 can usually tell them by the 16-pin interface.

 This sketch prints "Hello World!" to the LCD
 and shows the time.

  The circuit:
 * LCD RS pin to digital pin 12
 * LCD Enable pin to digital pin 11
 * LCD D4 pin to digital pin 5
 * LCD D5 pin to digital pin 4
 * LCD D6 pin to digital pin 3
 * LCD D7 pin to digital pin 2
 * LCD R/W pin to ground
 * LCD VSS pin to ground
 * LCD VCC pin to 5V
 * 10K resistor:
 * ends to +5V and ground
 * wiper to LCD VO pin (pin 3)

 Library originally added 18 Apr 2008
 by David A. Mellis
 library modified 5 Jul 2009
 by Limor Fried (http://www.ladyada.net)
 example added 9 Jul 2009
 by Tom Igoe
 modified 22 Nov 2010
 by Tom Igoe

 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/LiquidCrystal
 */

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

const int trigPin = 6;
const int echoPin = 7;
int const buzzPin = 10;
long duration = 0;
int distance = 0;


void setup() {
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Print a message to the LCD.
  lcd.print("hello, world!");
  
  // setting the trigpin as output and echo pin as input
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
   pinMode(buzzPin, OUTPUT); // buzz pin is output to control buzzering
  Serial.begin(9600);
}

void loop() {
  // set the cursor to column 0, line 1
  lcd.setCursor(0, 0); // Set the cursor on the first column and first row.
  lcd.print("Gd morning Yale!"); // Print the string "Good morning Yale!"
  lcd.setCursor(0, 1); //Set the cursor on the third column and the second row (counting starts at 0!).
  lcd.print("Time 4 breakfast");

// Clears the trigPin by setting it to LOW
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  // Sets the trigPin on HIGH state for 30 micro seconds
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(30);
  digitalWrite(trigPin, LOW);
  // Reads the echoPin, returns the sound wave travel time in microseconds
  duration = pulseIn(echoPin, HIGH);
  // Calculating the distance
  distance = duration * 0.034 / 2;
  // Prints the distance on the Serial Monitor
  Serial.println((String)"Distance: " + distance + " cm");




  if (distance <= 10) {

    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("Wash your plates");
    delay(5000);

    digitalWrite(buzzPin, HIGH);   // Buzz
    delay(60);

    digitalWrite(buzzPin, LOW);  // Don't buzz
    delay(60);

    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print("Reward 4 Today:");
    lcd.setCursor(0, 1);
    lcd.print("Word: Etymology");
    delay(5000);
  }
}

Reflection

From the prototype, I was able to discover that as a team, it is better we focus more on helping Yale to improve his eating habit instead of his ‘washing dishes’ habit. Which also means that the logistics of trying to detect whether he is washing his hands or washing the plates will be eliminated and hence, focusing more on the sensor positioning. One of the critique also suggested that it would be more fancy if we can incorporate ‘word pronunciation’ into the game. Also, a delay function might be needed so that it gives some timing before buzzing when a plate is detected.

Also, about the parts used, one unexpected thing I discovered was that 16 x 4 lcd is not among the parts on tinkercad, hence the game message on the lcd had to be shortened in length.

Moving forward, as a team, we agreed that instead of detecting whether the plate is washed or not, it is better we focus more on when Yale has finished eating and places his plate near the sensor before giving him a game to play rather than when he has finished washing his plates.

Puzzle Reward

Ergonomic Prototype

The prototype is part of the puzzle reward that Yale would get once he completes his task of eating at the right time.

For the puzzle reward, Yale expressed the different things he is interested in – math puzzles, logic puzzles, word puzzles. We realized that he is interested in various puzzles and it is very accessible for him by searching on the internet. This was why we wanted to prototype something that was more unique given that we are able to work with mechanical parts. We thought of making a mechanical puzzle that would allow him some variety and hope that with the prototype, we would be able to understand whether he likes mechanical puzzles and whether it would be a good reward for him.

The first part of this prototype is an ergonomic prototype to explore different ways to place the mechanical components like switches, potentiometers, buttons and LCDs.

Still Images

front view of prototype

side view of the prototype to see the knobs

side view of the prototype showing the switches

Moving Images

Video Link

Process Images

initial design sketch

brainstorming sketches

plan to prototype the switch component

Reflection

From the prototyping process of the ergonomic prototype, I realise that depending on the person using the device, there should be more distance between the potentiometer knobs. This is so that it would be less likely for the adjacent knobs to be affected when a knob is being moved. When testing out the prototype with two other people, I realised that one of them had a much easier time because her fingers were slimmer. The other person found it harder to be able to control each knob. 

Users like the front facing part of the box are very simple and contain elements that would change the LCD screen, which includes one knob and one button. Users like this simplicity and that all the switches and knobs were not in the way. Users also comment on how it is a good idea to change the color of the LED based on the configuration of the components, like whether the switch is on or off. This is so that users would not have to constantly rotate the box around when figuring the puzzle. A user commented that since more dexterity is needed for the knobs, it is a good idea to have it on the right side, which is most people’s dominant hand. This would be something we would have to talk to Yale about to confirm.

One point brought up was that the switches were slightly harder to work with and does require more effort. This is something concerning if students are already having problems with using the switches, it would be way harder for Yale to work with the switches.

Engineering Prototype

The prototype is part of the puzzle reward that Yale would get once he completes his task of eating at the right time.

The second part of this prototype is an engineering prototype to explore the potential of using a mechanical puzzle as a reward for Yale. It is also a form of exploration of the possibility of a mechanical puzzle since it is not something that is readily available in the market.

Still Image

overall layout

welcome screen

score screen

led lights as indicators

knobs and switches

Moving Image

interaction of switches

interaction of knobs

Process Images

user testing

lcd design flow sketch

#include <Adafruit_NeoPixel.h>
#include <LiquidCrystal.h>

#define PIN 13   // input pin Neopixel is attached to
#define NUMPIXELS      10 // number of neopixels in strip

Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);

// COLOR THINGS
const uint32_t  RED = pixels.Color(255, 0, 0);
const uint32_t  YELLOW = pixels.Color(255, 255, 0);
const uint32_t  GREEN = pixels.Color(0, 255, 0);
const uint32_t  BLUE = pixels.Color(0, 0, 255);

// SWITCH THINGS
const int SWITCH_ONE = 0;
const int SWITCH_TWO = 1;
const int SWITCH_THREE = 2;
const int SWITCH_FOUR = 3;
const int SWITCH_FIVE = 4;
const int SWITCH_SIX = 5;
int switchPins[] = {SWITCH_ONE, SWITCH_TWO, SWITCH_THREE, SWITCH_FOUR, SWITCH_FIVE, SWITCH_SIX};
const int NUM_SWITCHES = 6;

// POTENTIOMETER THINGS
const int POT_ONE = A3;
const int POT_TWO = A2;
const int POT_THREE = A1;
const int POT_FOUR = A0;
int potPins[] = {POT_ONE, POT_TWO, POT_THREE, POT_FOUR};
const int NUM_POT = 4;

// BUTTON/ QUIZ THINGS
/*
const int POT_PIN = A5;
const int BUTTON_PIN = 6;
int answer[] = [HIGH, HIGH, LOW, LOW, HIGH, HIGH, 0, 1, 2, 3];
*/
// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(7, 8, 9, 10, 11, 12);

void setup() {
  pixels.begin();
  
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Print a message to the LCD.
  lcd.print("hello, world!");
  
  // SETUP SWITCHES
  for (int i = 0; i < NUM_SWITCHES; i ++) {
    pinMode(switchPins[i], INPUT_PULLUP);
  }
  
  // SETUP POTENTIOMETERS
  for (int i = 0; i < NUM_POT; i ++) {
    pinMode(potPins[i], INPUT);
  }
}

void loop() {
  lcd.setCursor(0, 1);
  lcd.print(millis() / 1000);
  
  for (int i = 0; i < NUM_SWITCHES; i ++) {
    if (digitalRead(switchPins[i]) == LOW) {
      pixels.setPixelColor(i, GREEN);
    } else {
      pixels.setPixelColor(i, RED);
    }
  }
  
  for (int i = 0; i < NUM_POT; i ++) {
    int potLEDPos = i + NUM_SWITCHES;
    int potReading = analogRead(potPins[i]);
    if (potReading > 256 * 3) {
      pixels.setPixelColor(potLEDPos, RED);
    } else if (potReading > 256 * 2) {
      pixels.setPixelColor(potLEDPos, YELLOW);
    } else if (potReading > 256) {
      pixels.setPixelColor(potLEDPos, GREEN);
    } else {
      pixels.setPixelColor(potLEDPos, BLUE);
    }
  }
  pixels.show();
}

Reflection

The prototyping process of the engineering prototype was not very smooth for a few reasons. The first was because the simulation was very far from real time and it was hard to see the process of trying out different combinations. Without the tactile elements of turning a knob and flipping a switch, it felt less satisfying and also made the process longer and harder. 

One approach the user took when solving the puzzle was to guess every single combination. This was not ideal because it would not be a puzzle but more on a tedious task that takes more time than brain power. Given this suggestion, we plan to limit the number of guesses so that Yale would have to think of smart ways to solve the puzzle. With the limitations of the tinkercad software, it is hard to have multiple LCD screens, which is why labels should be made to explicitly specify the purpose of each button. One small comment on our initial prototype was that the maximum score was not displayed so the user did not know whether the problem was solved or not. In order to address this issue, we decided to add the maximum possible score and have the button reset the puzzle when full marks are achieved.

Final Thoughts

Overall, we feel that the prototyping process was very useful in terms of getting the ball rolling and getting a sense of the feasibility and desirability of our project. It was really useful to prototype the mechanical prototype because it was something that we were not sure would be a viable puzzle project to be used a a reward for Yale. When we met Yale over the week, we managed to show him the prototype and get some initial feedback before we move on. We think that this fail fast principle would work best in the long run and prevent us from wasting time working on something that would not meet the needs and solve problems that Yale is facing. 

The biggest challenge when prototyping remotely is that communication of ideas is harder. Anishwar and Zoe were working on ergonomic prototypes and since it was hard to verbally express how they would like their prototype to look like. Anishwar was not sure how exactly the mechanical puzzle worked which was why it was slightly harder to convey the entire idea through words and images. Similarly, the task idea of detecting a plate could be implemented in different ways. It was very difficult to convey the initial idea of the brainstorming to the person prototyping the product. When working remotely with the client, it was also harder to get a sense of whether the client likes the idea. Yale was very polite and constantly praised our efforts, which was encouraging but was not very useful in terms of getting criticism on how to improve our product. It was also hard to get him to interact with the ergonomic prototype to see whether there are any difficulties moving different components.

We decided to have each team member be in charge of a single portion of the project – Ola will be working on the code for the task sensor, Zoe will be working on the code for the puzzles and Anishwar will be working on the visuals of the prototype. This gives the team members more ownership but it is harder to keep each other accountable. Also, one risk we might face is that if one portion of the project is more time consuming, the amount of work done by each member might not be equal.

One thing we hope to do differently in the future is having more communication. Even though we would have video calls outside of class time, it was still very hard to communicate ideas through video calls. I think having the habit of quickly sketching is extremely important.

We (Leah, Abel, and Varsha) were paired with a retired English teacher named Jane. On March 25th at 10:00am we interviewed Jane to get an opportunity to learn more about her and find out how we can help her with any problems she has. The results of our meeting is detailed here.  After meeting with her and brainstorming, we came up with some prototypes that we believed could help solve some of her problems. Jane is interested in feeding birds, but she worries about pests eating the feed she leaves for them. Thus, we decided to make an automated bird feeder. Below is the details of our prototype, which we split into 3 different parts that each team member worked on.

Prototype

Our group split up the entire bird feeder and did prototypes for a part of the entire birdhouse. We split the bird feeder into:

1. The housing unit for food(looks like prototype)
2. The food catcher(looks like prototype)
3.  The electronics and circuit(works like prototype)

1. The Housing Unit

The “housing unit” of the bird feeder is the feeder and base. The final product is intended to be automated. When a bird lands on the base, the feeder will automatically open and dispense seed. The prototype was made out of cardboard due to a lack of resources, but the final version of the feeder is intended to be made of acrylic or some other waterproof material. This looks like prototype was designed to help answer the design question: what should the dimensions of the bird feeder be, and how should the dispenser open to deposit seed?

Process: 

I began making the prototype by getting some cardboard out of my recycling bin.

The cardboard material I used to make the prototype

As I stated earlier, the final product will be made of acrylic or some other waterproof material. After cutting the cardboard and taping it together, I realized the size was way too large, requiring me to rip the tape off and cut it smaller.

The original size of the side of the feeder (on the left) and the strips I cut from other pieces

After fixing the problem, the housing unit prototype was finished, and I showed it to my sister for her criticism.

My sister looking over the feeder and offering her feedback.

Finished Prototype

Below are the images of the finished prototype:

Overall view of the bird feeder housing unit

The lid of the bird feeder slightly opened

The dispenser of the bird feeder while opened

The movement of the lid and dispenser while opening:

Conclusion

Jane had no criticism for my prototype, but my sister had a lot to say about it. She brought up three key areas I could improve upon for the final project. She thought the lid I made was very flimsy. She was worried that a bird would be able to easily flip it open, so she thought I should attach a latch. Furthermore, she was concerned about how I would position the feeder in the garden. She wasn’t sure if I would place it on a pole, hang it on a branch, etc. She also told me that as long as the dispenser opened it didn’t matter how it did so, but she thought making it a sliding “door” would be easier. 

Ultimately, I got the answers to my questions. The size and dimension of the feeder was good, but the dispenser and lid could use improvements. I will be incorporating all of the feedback I received because everything my sister said is completely valid. There are a lot of changes I can make to the lid and dispenser to address her criticism and make the bird feeder better. Plus, I completely forgot to include the hook on the bird feeder. These are all important elements to it, so I will be making the necessary changes according to the feedback I received.

2. The Food Catcher

The bird food catcher is a dish that hangs off of the food housing unit to catch food that falls from the feeder when birds eat from it. The prototype I made used a paper plate in place of a catching dish, and some pieces of twine. It’s purpose is to catch the food falling off of the food housing unit and

  Process:

I started out with some common materials found around the house.

The materials I had to start out with- A paper plate, some twine, and some plastic rings

For the final version of the project, the food catching dish will be deeper and heavier, but similar in shape to the paper plate. The twine will also be stronger and instead of plastic rings, there would be hooks. The intent behind having hooks, is to make it easier for Jane to remove the dish to empty out the food.

To create these “hooks”:

Cutting a slit in the plastic rings to form hook-like structure

Then insert them:

I made a slit in the paper plate and fit the “hooks” in.

Then finally, after tying the twine to these rings, I had this initial prototype:

Initial prototype- only two points of contact with “hooks” and plate

At this point, I showed my prototype to my parents, who said that it was too basic and would not last 20 minutes outside in nature. Their main critique was that it was not durable and that I would have to use some very heavy duty materials for it to be actually usable by Jane. Another major concern was how it would handle the wind. If the wind blows too much the plate would tip over and the accumulated food would fall out. This would destroy the purpose of the automated birdhouse, since Jane’s initial problem was that the spilled food was attracting pests.  My reason for showing this prototype to my parents is that they have some experience designing and building products that are used in the real world. I wanted advice regarding the design of this dish and the question of whether this would be usable by Jane to be answered. The prototype critique gave me some ideas about how to attempt to fix these issues and all of the advice given was integrated along with these ideas in fixing the prototype.

The first thing that I wanted to integrate is more support for the dish. This initial version of the prototype had 2 contact points with the hooks on the plate. When bought out in the wind, the plate would tip sharply to the side. To attempt to fix this issue, I added 2 more contact points to the dish. This seemed to make the dish more stable and move in a more circular pattern when there was wind, rather than tipping over. In order to counter faster winds, there will be a heavier dish that is not that easily tippable in place of the paper plate. In addition to that, usability of the plate for Jane needed to be improved. In the first prototype, there were only “hooks” attached at one end of the twine so that Jane could clean out the dish very easily. Then, it occurred to me that there might be a time when Jane might need to unattach the entire dish and  put it back on. So, i attached hooks to the other end of the twine as well. Overall, the prototyping critique was very useful in improving my prototype and it surprised me how much could be change in such a simple prototype.

Attached it to an existing bird feeder I already had for testing purposes

How the new prototype looks while hanging

The new prototype hanging off a tree

Final prototype, hanging off of the tree, moving in a circular motion in the wind instead of tipping over

3. The electronics

The “works like” prototype we envisioned was created in Tinkercad. It is supposed to function as an automated bird feeder. It will dispense food when a bird lands on a pressure plate. If food has already been dispensed, another pressure plate will be triggered and will prevent more food from being dispensed.

We built a prototype with Tinkercad that consists of an Arduino, two switches, motor and a breadboard. Since Tinkercad does not have pressure pad sensors, we used regular sensors to mimic the functionality. The prototype will spin the motor only if one switch is active at a time. In practice, this means that the motor would spin if only one pressure plate is active. The motor spinning will cause the bird feeder to dispense food.

After we showed Jane this prototype, she seemed to like the idea and didn’t have any critique for it. I do plan on improving the prototype by adding a delay before the switch triggers the food functionality. Currently, the motor will spin once the switch is activated. Another critique I have is what happens when the feeder runs out of food. The motor will spin if a bird is standing on the pressure plate and no food is detected on the pressure plate. So, if food runs out, it is possible for the motor to keep spinning if a bird stands on the pressure plate indefinitely. This could drain the power source of the device.

One surprise I encountered while prototyping was the lack of a pressure plate on Tinkercad, so I had to substitute the functionality with a regular flip switch.

Animation of the prototype in action

The final prototype in TInkercad

The final prototype code

Drawing of the initial prototype

Prototype to test the motor spinning

Moving Forward

The prototyping process was very constructive. We received a lot of helpful feedback for our prototypes that we can use to improve our product. We are already planning our next steps. For the works like prototype, we plan on implementing a timer so that the food doesn’t dispense immediately once the pressure plate is pressed. This will improve the functionality because currently the food is easily and quickly emptied. The looks like prototypes will be drawn out using CAD, with the necessary changes made to improve functionality. In the event that we finish the automated bird feeder with time to spare, we plan to build a system that notifies Jane when the nectar in her hummingbird feeder needs to be replaced, depending on the temperature and humidity. Jane has multiple kinds of bird feeders, and it is very important to always leave out fresh nectar in order to attract hummingbirds.

Through this process, we learned that prototyping remotely can be challenging since we are unable to physically interact with the prototype. This is a significant part of the process since you have to be able to feel and use the device in person to critique it thoroughly. Additionally, we are unable to physically put each person’s contribution together. Thus, it is difficult to conceptualize and demonstrate how the pieces will fit together when designing the product and receiving feedback on the prototypes. We are making the best of this situation with extensive communication and collaboration. Many pictures and physical demonstrations over video call make it easier to work on. We are continuing to work on our automated bird feeder, and we will be using plenty of communication to create the best product possible.

Progress of device 3D rendering

Exercise Companion

Introduction 

Our team is trying to create a personal useful device for an elderly person that may improve a certain aspect in their daily routine  or bring more positivity in their life. Our client is Fredrick and he enjoys exercising, however, he wishes that his daily exercise could be varied in order to make it more interesting everyday.

Click here to view our interview with Fredrick

Patricia’s Prototype

Design question

How can a device be easy to use for Fredrick and fulfill the purpose of making his exercise routine more interesting?

Final Prototype 

Full view of prototype

One of the “LCD screens” shows a face that changes expression on completion of an exercise

Interacting with the prototype

Description

The device  reflects the look and interaction of the final device we would like to build. It simulates:

1. A LED strip/ring that would show the progress of the overall completion of a category of exersizes
2. A button to shuffle order of exercises in a category
3. 2 LCD screens. One for that mimics a face and anthropomorphizes the device and one that has the title of exercise.
4. A speaker that would announce each exercise 

The device should be on a smaller scale so that it’s easy to hold in one’s hand and to carry around. Appearance wise, it should be be simple and also have only the essential interactive touch-points such as the one button.  The first level of feedback the user should receive is sound, the exercise that is announced. Then sight is secondary where the user is able to see the LED progression and check the description on the back LCD screen if needed.

Process

The white exterior was made from paper plates

I did not have enough LED lights so I used one to represent the ring of lights

The button is from another project and the black plastic film (representing the LCD screen) is from trash bags

Our team members coming together to draw and combine the best aspects of each of our designs

Reflection

I talked to a friend that was close to me in proximity what he thought he could do/use with the prototype without any context at first. He said that there was obviously a button to press and something would happen. Then after I explained to him what the purpose of the device was and about the project he said the device made sense. I did not really receive much feedback from him, and this could be because I told him that it was made for an elderly person and involves his daily exercise routine, so perhaps he was not able to relate.

During our video call feedback with Fredrick, I felt like I was able to receive much more feedback that changed the design of the product.  He is very straightforward in his feedback and so he told us that he did not need a countdown/timer for each exercise routine, he wanted to be able to take his time. Therefore, instead of our LED strip/ring being a timer function, it would just show the progression of the entire exercise routine. Fredrick said he really appreciated these extra features. Also, he wanted a voice recognition feature that would signal to the device to move onto the next exercise instead of clicking the button every time. This was very helpful for us and allowed us to improve our device to his needs.

Fredrick was able to answer some of the questions that I had, for example, if he wanted to be able to add/delete exercises from the routine or add sets and reps. He said that he did not need to do that and he would vary the sets and reps by himself. I think he prefers to have space for his own freedom when using tools like this. We also wanted to confirm with him if he liked the idea of anthropomorphizing the device with a little LCD face that changes from time to time to encourage him to do the routine. He stated that he liked this idea, and so we will continue to pursue this.

Aadya’s Prototype

This prototype is a looks-like prototype. The design question this prototype was aiming to address was:

How might the visual appearance of the exercise companion motivate Frederick during his workout session?

The Final Prototype

The prototype of the Exercise Companion

Device sized for portability

The Description

I built this prototype using the materials I had available such as carboard, markers and a box cutter. I created the prototype to have a friendly face like front which could house an LCD screen that could display the name of the exercise for Frederick. A strip of LED lights could indicate Frederick’s progress during a workout session. The prototype also has two speakers on the sides which would announce the name of the exercise so that Frederick wouldn’t have to constantly look at the device to know which exercise to do next. The prototype also has a physical button on the top which could allow Frederick to switch to the next exercise.

Reflection

I tested the prototype with my roommate to get feedback on it and iterate. I provided her the context of the prototype and asked for her feedback. As I spoke to my roommate, she mentioned that it would’ve been useful to have the number of exercises completed in the workout aside from the visual progress bar displayed as it would be motivating for her. She also mentioned that she preferred a smaller form factor for the device in case she wanted to travel with it. Overall she felt the visual appearance of the device would make her feel more accountable as she did her exercises due to its anthropomorphic appearance.

Testing out the looks-like prototype

Z’s Prototype

Overall View of the Prototype

The potentiometer on the left is for selecting the sets of exercise. The other is for the contrast of the LCD screen.

Short stimulated interaction

Description 

This is a behave-like prototype designed to help answer the design question : will the user find the device easy to use.

The major components of this prototype is a potentiometer, a button, and a LCD screen. The LCD screen represents the TFT screen that shows the name and the image of the exercises.  Fredrick can use the potentiometer to choose one of the three sets of exericese by turning it to the leftmost, middle, and rightmost positions. The device moves to the next exercise when the button is pushed.

Process

Wiring the LCD screen

Leon is interacting with the stimulation

The next step is to include TFT screen that can display high-quality image for each exercise and the “face” of the device.

Reflection

In the in-person prototype feedback session with my friend Leon I have learnt that the prototype is not easy to use without verbal explanation yet. Even though there are only one potentiometer and one button to manipulate, more information should be given on the screen. In addition, the range of angle for selecting sets is too small such that the options for the set only show up when the tip of the potentiometer is pointed precisely to certain angles. Moreover, when the name of the exercise is too long for the screen to display, the text scroll to the right. However, according to Leon the text will be more readable if it scrolls to the left. To better display all the information, tft screens will be used. Finally, when Leon tried to go to the next exercise by pressing the button, he found out that sometimes the device would skip exercise. This bug was fixed by checking the state of the button in every so often to prevent over counting.

In the discussion with Fredrick, we have gained a better idea about how Fredrick would like the device to behave. Fredrick mentioned that he did not want the device to have a timer feature because he does not like to rush through an exercise. This means we will not include such feature anymore even though we thought it’s a common and important feature for a workout device. In addition, he would prefer exercises that require similar postures to be put next to each other in the sequence of the exercises. This imposes more challenge software-wise, but no doubt makes the exercise routine more efficient. Finally, we were glad to found out that Fredrick appreciate the idea of LED ring as reward to finish each exercise in the set.

Moving Forward 

Our conversation with Fredrick after each being able to think about the problem and bring a solution was extremely helpful. Through this talk, we were able to receive key aspects of the design that was beneficial to Fredrick. It was difficult to test out the prototypes due to the limited people physically around you. Some members of the team were able to receive constructive feedback while other feedback was “too positive”.  It is difficult at times to ask people who are not used to critiques to give feedback on your work, because unless there is something significantly unsatisfactory about the design, they would usually say that the work is good and not much more. Next time in my prototyping process, I would want to ask more people whether that be meet them in person or virtually to ask for feedback. This is a good reminder for us in the future to conduct more research onto prototypes to gain more insight into the problem and thus create a better solution.

Important new decisions we made together as a team after talking to Fredrick, was to include a voice feedback system, where Fredrick could signal to the next exercise with his voice. Also, knowing that he does not need to time each exercise; he would rather prefer a progression bar for the entire routine of exercises.

Since we already have a clear vision about the device as a group before developing the prototypes, and because Fredrick has given positive feedback about the prototypes, we have decided to stick with the original design of a cube-shape design. However, we still have to determine the details of the design, such as the dimensions and layout of the electronics. Because the developments of 3D rendering and software/hardware are going in parallel, communication and collaboration are crucial. Finally, an interactive diagram and storyboard will be created as an instruction for actually creating the device.

Our project is a remote-controlled moss dispenser that will help Beth to clean up and beautify her yard. This post is our ideation process being prototyped along with the feedback we got from our prototypes. Here is a link to our ideation process.

Interview with Beth

Prototypes

Looks-like Prototype

This prototype was designed to answer the following questions:

• Are the shape and size easy to work with? Is the space allocated effectively (are tank and blender big enough)?
• Where is the extra space in the device and what can we put there?

This looks-like prototype was built with cardboard and tape. The leaf-blower is represented with a vacuum and the blender and moss-dispensing tank is slanted downward.

Overall view of the car from the side

Front view of attached cordless leaf blower, while getting feedback from my sister

A door opens in the back when user presses button on remote control to dispense moss mixture.

Slanted tank allows the moss to be dispensed through door with gravity

Original sketch to plan out what materials I would need

Gathering materials to build

Process of putting together inside of car, too much space underneath the tank makes the robot bulky.

The process of explaining the very specialized purpose of robot to my sister allowed us to brainstorm more about the project overall. First, she said that the robot was very bulky, yet she wondered if the blender space was big enough. You would have to keep refilling the blender with ingredients which would make the remote control useless. Beth said that she can cover about 9 square feet per blender of moss mixture. This is important feedback; we have to have a large enough blender space so she doesn’t have to keep bringing the robot back to her.

I was concerned about the size and weight of the leaf blower especially, and I was surprised with how much space it would take up. Beth mentioned that it would have to be super strong so that would add to the weight. My sister and I also noticed that the leaf blower might be getting rid of the leaves ineffectively since we weren’t really controlling the direction of the blower. These problems helped us decide on a moss dispenser when Beth told us that we should focus down onto either a leaf blower or a moss dispenser.

My sister and I also discussed how the wheels might have a hard time getting through Beth’s garden’s terrain so we explored a different type of wheel, or at least they would have to be bigger. Beth mentioned that her yard is quite muddy, so she agreed that the wheels have to be durable and powerful. We will be designing the wheels with this in mind.

Looks-like Prototype

This prototype was designed to answer this question: “How will all the pieces go together, is it feasible?”

This is a 3-D model of our idea made in Fusion 360. It includes a model of the leaf blower, blender, tank (the tank is inside the car though) and the car itself.

full view of the 3D model

close up of the blender

model next to 5’5 person

how the blender and tank would be connected by hose

original thoughts on the body of the car

thoughts of the blades for the blender

I asked my mom to look over the prototype and she asked me these questions, ones I hadn’t thought about.

• How is the bowl washed?
• Can it travel all 3 acres with its maximum battery power?
• If not, is there some indicator that it will die? (So it doesn’t stay stranded in the middle of the acres)
• Can the tank hold the amount of moss mix needed to lay throughout the acres? If not, is there an indicator that the tank is empty?
• Will it charge?

Thankfully, the design already has a built in washing method. It can simply “blend” water and let it run out through the tank. I didn’t have an answer to her next question because I’m still not sure which motors we are using and how much weight it will be carrying at maximum capacity. Knowing these two though I can definitely do those calculations to figure out if the battery is enough. It would be interesting to see some indication that the car is on low battery, but I couldn’t think about an effective solution to that. Similarly, the suggestion for an indicator that the tank is empty would be a nice touch, but I also couldn’t think about a solution to that. We are going to integrate a charger when we figure out what battery we will need.

I will be trying to integrate indicators for low battery and a low fuel tank. I think those features a very nice for something like a remote controlled car. If its too far away for you to see those situations visually, those indicators solve that problem. All of the feedback was very helpful and none of it will be ignored.

During the prototyping process, I did encounter surprises. First and foremost, I usually model in Solidworks. I was surprised to see that Fusion 360 is actually more different than I expected and had to learn a couple things before I could start modeling.

Controller Prototype

process 1 – physical mockup

process – initial idea 1

How ir sensor and controller work in tinkercad

process – initial idea 2

final render

render – where does the ir sensor goes

render – some fun fillet!

This controller was designed to control both the robot and the blender. It is going to use IR sensor to communicate with the robot and use mix, dispense, and move around the robot as user press the buttons.

I made three initial controller sketches including the final one. Since I am fairly new to 3D modeling Fusion 360, I ended up with the idea of referring to nintendo controller since it is not only simple to reference to but also ergonomic for the user to use. Then together as a group we figure out what are the functions that we need on the controller.

I showed this controller design to my friend and immediately got the feedback that the design is overcomplicated, which was also reflected in Beth’s feedback. Since Beth is going to be working in the woods and possibly need to carry/move other stuff, having a controller that takes up both hand just seems impractical. So for the next iteration, I will be going back to my original prototype of one hand-controller and make sure the placement of the buttons are comfortable and easy to use.

Another feedback I got from my friend was that she preferred the use of joystick in one of my initial sketches since there could be more refined control. However, after talking to my teammate, we realize that it would not be practical since the band wheel we are using does not allow moving 45 degree.

Moving Forward

We thought the prototyping process was very successful since we got a lot of good feedback from everyone. Our client was very impressed with our prototyping given what we gathered from our initial conversation with her.

Beth had also let us know that it seemed like we should focus on a remote controlled car that either leaf blows or dispenses moss. She mentioned that the leaf blower would have to be quiet so as to not disturb neighbors, yet it would have to be strong enough to blower wet leaves. This seemed like a task that was a little out of scope for the class, so we decided in building the RC moss dispenser.

We discussed having  the moss dispenser in backpack form versus remote controlled but ultimately we chose a remote controlled robot for the final project since it seemed as the complexity of the backpack wasn’t much compared to the RC version.

We discussed on Wednesday evening as a team about the final design, which involved solving various issues on how it would work in real life. One huge problem was figuring out how the dispensing would work. After some time, we found a solution with a hinge and servo motors.

Brainstorming ideas for door mechanism on Zoom whiteboard

Overall drawing to get on the same page

If we were to ever do this again, we would like to have spent more time initially figuring out how most of this stuff would work in real life.

Overall, we’re really glad we had a prototyping process since we found and solved some very crucial problems and also narrowed down the vision of our final product.

Previously, Team Lynne interviewed Lynne to get a sense of what device would help her in her daily life. (Link to the interview documentation: https://courses.ideate.cmu.edu/60-223/s2020/work/interview-with-lynne/) We concluded that the best remedy for her arthritis pain in the hands were to rest her hands when not working and doing daily tasks. We came up with a device, a foot keyboard with four arrow keys, that will work both as an entertainment device as well as a device that would assist her when using her computer. We came up with different variations on its form and this post documents the question we answered: looks-like, feels-like, and/or behave-like of the foot keyboard for Lynne.

Sue’s Prototype

This prototype was designed to help answer the design question: How would the user experience be if the Foot Keyboard had IR sensors as user input?

The prototype was meant to approximately look-like and behave-like a Foot Keyboard with infrared sensors as “keys”. The components were all cut from cardboard and could be assembled by fitting tabs and slits together. Two different arrangements of IR sensor keys were tested (keys in a diamond shape and aligned in a row) and the entire prototype could be converted to and from a ramped form. The IR sensor experience was simulated by pressing keys on a keyboard when the user hovered their foot over the center of a key.

Images of Final Prototype

The main components of the Foot Keyboard are the main body housing the four keys, wall attachments to enclose the keyboard, and fold-away pieces to incline the keyboard.

Tabs of the back pieces can be fit together to add an incline to the keyboard

Shown are the individual pieces laid out. These pieces could be laser cut in a similar pattern from wood.

With the keys aligned in a row, the user could easily move their feet side to side to “press” the four keys.

Prototype Development and Feedback Process Images

An initial cardboard prototype lacked stability and failed to answer questions about possible laser-cut patterns.

Creating a mini “proto-prototype” out of paper gave insight on the shape of the pieces on a smaller scale

During the feedback process, we simulated the user playing Pac-man using the Foot Keyboard by pressing the laptop arrow keys when the user hovered over a key.

I received both in-person feedback from my mom and online feedback from Lynne.

My findings from my mom are the following: The row alignment for the keys and a ramped keyboard is more comfortable for the legs. Pushbuttons seem better than IR sensors due to their physical feedback that a button has been pressed. The built-in Simon Says game is not very fun. A cover will be more effective than the walls in keeping Lynne’s dog from the keyboard.

Feedback from Lynne was as follows: The size of the keys can be reduced to fit her small feet (size 4.5 – 5) and buttons should have texture, possibly in the form of engravings, so the keyboard can be used more easily without looking at the keys. A full cover over the keyboard will prevent Mendy from chewing on her toes. She is optimistic about playing Simon Says, as she likes “fast and rapid” memory games.

Moving forward, we will be taking almost all of the feedback into consideration. For example, we will shrink the key size, use pushbuttons for the keys, and align the keys in a row. We will be continuing with having Simon Says as the built-in game, taking Lynne’s optimism over my mom’s feedback.

Hojung’s Prototype

These two prototypes focused on the structure of the buttons and were designed to help answer: What button layout/structure would be the most comfortable for the user?

This prototype was meant to approximately show look-like and feel-like for the Foot Keyboard. Two different prototypes were made with differently structured buttons, one flat and one angled, to test out comfortability when in use. The components of the prototype were made with cardboards and sponges to simulate a button press. The arrangements of the arrows were in a line to decrease the movement between each press. The buttons were placed on a 1 inch raised platform designed to incase the Arduino and its wires.

Images of Final Prototype

Foot Keyboard with flat button design compared to male shoe size 8

Foot Keyboard with flat button design simulated

Foot Keyboard with angled button/gas pedal design compared to male shoe size 8

Foot Keyboard with angled button/gas pedal design simulated

Detailed: Use of two sponges to simulate button press for the flat button design

Detailed: How one flat button design works individually

Detailed: Use of one sponge to simulate button press for the angled/gas pedal design with a hinge made out of black paper

Detailed: How one angled button design works individually

Prototype Development and Feedback Process Images

Initial design plan during the team meeting session

Blueprint and measurement of the individual buttons and the base

Initial placement of the sponge on the flat button design: center sponge placement ended with unbalanced distribution of weight making the button wobbly

Initial placement of the sponge on the flat button design: center sponge placement ended with unbalanced distribution of weight making the button wobbly

The two options of the foot keyboard button layout were tested by my dad who is familiar with arduino and designing. The first option, the flat button design was met with many critiques but a comment that came up often was, “It’s uncomfortable.” Specifically, the flat button design creates a situation where the user has to lift up the whole leg in an uncomfortable foot position, unnatural to the resting positions, which creates tension in the leg. In addition, because the button is big and the gap between the buttons were wide, the user is required to move the leg side by side in a wide range of motion creating an unnecessary amount of work. The second option, the angled design, was met with a better initial impression. It was the most comfortable out of the two shown designs, however, the gap between the button and the size of the button also created the same problem as before. My dad suggested that a more rectangular design resembling the gas pedal on cars would do the trick to easing up unnecessary movement between the buttons. 

The two options of the foot keyboard button layout were shown to Lynne. Lynne was happy with the design of the two options, but was leaning towards the angled button since it looked more comfortable. In addition, she mentioned that the scale of the button might be too big for her tiny feet size of 4.5 – 5. Lynne also mentioned that the device will be used when she is on a recliner, which suggested that we as a team needed to think about the angle of the button if used with an angled platform design shown in Achilles’s prototype. 

Overall, with the critique and suggestions, it is prominent that the size of the button should be reconsidered and made smaller in addition to leaning towards the angled button design of the foot keyboard. The critique was as predicted, and it provided great feedback on improving the design of the button.

Achilles’s Prototype

This prototype was designed to answer the question, how would this device look like? 

Fusion 360, a 3D modeling software, was used to design this prototype. This prototype was an approximately 14in x 10in wedged platform containing four raised buttons with arrows engraved on each button. The arrow buttons were placed in a diagonal/square configuration. The device was modeled to look like transparent green acrylic.

Images: 

Rendered image of the prototype

Clearer look at the button configuration and engraving of this prototype

Angled shot of the height of the wedge shape of  this prototype

I designed a prototype of our device that would have a wedged structure with four flat but raised buttons in a diagonal square configuration. Overall this was a very simplistic design and didn’t include very many of the more detailed design elements that will be included for the final project. 

I received feedback from my sister on this prototype. Some of the feedback she gave were on the size of the device, the buttons on the device, and the incline of the wedge structure of  the device. For the size, it was initially difficult to gauge how large or small it should be, so I opted to make it on the smaller side, having the top of the device be 14in long and 10in wide. The buttons  themselves were around 2.5in by 3in big. The feedback I got from my sister was that this sizing was likely too small to actually be able to maneuver around and press with your feet. However, from Lynne, we found out that overall our device should be smaller than we anticipated because she has small feet and a smaller size would likely be more comfortable for her. Other feedback from my sister was that the device should have an adjustable incline rather than a static one, to account for different seating  positions and comfortability of the person the device was intended for. I thought this was a good idea since we have no idea what is the optimal angle for the incline to be stationed, so having the choice to adjust it as needed would be the perfect solution for this issue. 

One feedback that I thought didn’t need addressing was one on the type  of buttons. Originally this machine was intended for something like Dance Dance Revolution, which not  only has up, down, left, and right buttons, but it also has diagonal buttons. My sister commented that this should include diagonal buttons, but for the sake of this project, as its main function was to be connected to a computer, the diagonal buttons wouldn’t be necessary. 

With prototyping our device, I found a lot of difficulty deciding the sizing and specific angles of every piece necessary to build it. I think, moving along with our final device, this prototype was a good insight on how the structure should be created and how the angle of the incline and size of  the device can make a difference in how the user can enjoy it.

Conclusion: Moving Forward

The process let us focus on important aspects of the device and guide us towards the right direction for the final device design. It also gave us a feel of how the device will function in real life and not just from our imagination.

The main challenge of prototyping remotely was encountering unanswered questions. When unsure about Lynne’s exact situation (e.g. the exact size of Lynne’s chair), we made assumptions and continued with prototyping, as to not bombard Lynne with a chain of emails. Coordinating between team members also proved slightly challenging in making sure everyone had the same visualization of the intended final device.

From the critique we got from Lynne and others, we concluded on using an angled button design for the foot keyboard instead of the IR sensors. Lynne also commented that she has small feet and is planning to use the device on a recliner, so we changed up the design to fit her needs. We concluded that the button will be smaller than in the prototypes and will have an engraved arrow to indicate the arrow even without being seen. The button would also be laid in a row, with a maximum 0.5” gap in between for easy movement. We also concluded that the size of the keyboard should be maximum the width of her recliner. We decided that the foot keyboard should move with the recliner, so we designed to add an elastic band that would be slipped into the recliner in addition to having a non slip grip at the bottom so it would stay put.

In another iteration of this prototyping process, we could have more combinations of features. One that we did not address this time around was a prototype with an inclined body as well as our “gas pedal” like buttons. The structure of our device has been in debate as to which would allow for more comfort and ease of usage, and this was one combination we were unable to test but have considered for our design.

This is a documentation for Team Emily’s prototyping for the mouse detector idea that we decided to build for Emily after our initial meeting with her. Yun made a looks-like/behaves-like prototype, Youie made a looks-like prototype, and Alan made a works-like prototype. This documentation includes the descriptions and pictures of our prototypes, discussion of our prototyping process, feedback, and future work.

Prototypes

1. Looks-Like/Behaves-like Prototype (Yun)

Despite there being similar products such as mice traps and detectors in the market, what makes this product special is in interesting notifications. Due to the COVID-19 situation, Emily needs to social-distance herself at her house, and, thus, wanted something that could entertain her. This prototype was designed to help answer whether this device is entertaining, and furthermore, easy and safe to use in general.

The prototype is in a stereotypical cheese shape, and is built out of yellow corrugated cardboard sheet. On one side, it has a hole that represents a mouse detecting PIR sensor, and on the other side, it has a mouse shape panel, which will rotate and appear when the mouse appears, working as one of the notification systems. On the top, it has multiple circular corrugated cardboard sheets, which are part of the design choice, but also represent a speaker unit that will play Tom and Jerry music when the device detects a mouse. In the bottom, it has three identical springs, which represent a reset button that Emily can press with her foot.

An initial sketch of the prototype design

The overview of the prototype with a speaker unit on the top

A side of the prototype with a sensor

A side of the prototype with a mouse panel notification

When the device detects a mouse with the sensor, it will show up the mouse panel from the back

My mom gave me some feedback on design and safety. When she tried to push the reset button by pressing the device with her foot, it was hard to balance her body so she needed to put her one hand on the wall. She suggested having a handle on the wall that has the device. However, I thought there can be other ways I can solve the problem within the device rather than installing extra devices elsewhere, and decided to make the device shorter and wider. On top of that, my teammate Youie suggested to put a button on the top of the device rather than on the bottom, which will definitely make the device safer for Emily to use. 

Emily herself liked the design and entertainment components of the device: the cheese shape, Tom and Jerry music, and the mouse shape panel. However, she said the music I chose may be too loud that can startle her often. Thus, I got some different music track candidates such as Ratatouille soundtrack or The Cat and the Mouse piano, which are more soothing, but can still remind Emily of mice.

Moreover, she originally wanted the device to be around the wall and corner; however, during the prototype feedback session she let us know that mice appear near her refrigerator so it might be better to install the device around there. On top of that she was concerned that the sensor might detect small kids at her house as mice, and suggested the device to be a tunnel shape that can attract mice into it. We thought of the tunnel shape prototype as well in the beginning, but decided not to have it as the device is not meant to trap mice; however her concern was very reasonable that we are trying to improve the design considering both Emily’s concern and the space we are given.

A potential space Emily suggested for installing the device

2. Looks-Like Prototype (Youie)

This prototype was designed to help visualize a relatively concise design and stable structure that would fit well with the context.

This design is shaped like a quarter of a thin cylinder with a swinging panel for a visual notification, a speaker for an audible notification, a reset button to stop the notification, and sensors to detect mice for notification. It is generally yellow with a white swinging panel that also has an illustration of Jerry from Tom and Jerry. What I intend to communicate was that this panel will have to be visually distinct from the rest of the detector to stand out. The reset button can be pressed down with anything or simply stepped on. Yellow was chosen to make the detector seem rather entertaining.

Part labels

Fitting into a corner

Back side with the panel pivot mechanism

Popping up (for notification) and going back down (after pressing reset button)

Ideation sketch about feature arrangement and form

Building assembly in SolidWorks

Initial rendering with one material done in Keyshot

When I showed the prototype to my mom, she said that I will carefully have to think about the size and thickness so that it would be safe, and not get in the way of Emily when she is walking around. Because this is not something that I have been thinking about very much nor our team has discussed extensively, I will definitely keep this in mind. I think scale will also be critical so that the visual notification will be clear enough for Emily, and also to be able to fit the parts inside appropriately.

3. Works Like Prototype (Alan)

This prototype was designed to simulate the Arduino circuit that would be used for the mouse detector, and to test the possibility of implementing some of our ideas from the sketch electronically.

The simulated circuit is made on Tinkercad with Arduino code. There are 5 input components and 3 output components. The outputs are a servo which would be attached to the mouse sign, which would rotate 90 degrees to show the mouse sign when a mouse is detected; a LED which would light up when a mouse is detected; a piezo simulating a speaker that would play a melody when a mouse is detected and if it is daytime. The inputs are a PIR sensor to detect the presence of a mouse, a photoresistor to sense ambient light to detect whether if it is daytime, an “ambient  sensor knob” potentiometer to set the gate value of the photoresistor, a “brightness knob” potentiometer to set the brightness of the LED, and a “reset button” pushbutton to turn of the LED and reset the servomotor to its original position.

Full Tinkercad circuit

A snippet of the Arduino code on Tinkercad

how Tinkercad simulates a PIR sensor

a short video showing the simulation on Tinkercad

Process Images:

Planning the components on paper

Testing photoresistor values using serial feedback

Learning how to program a piezo on Arduino

During the prototyping, I had a hard time using Tinkercad, because it does not simulate the circuit in real-time speed and its clock is very slow. That made functions involved with time difficult, in this case playing a melody using the tone() function. However, Tinkercad does do a decent job simulating the inputs such as the PIR sensor and the photoresistor, which made simulating potential situations possible.

Because I am currently living by myself, I couldn’t show this prototype to anyone in-person, but I did show it to my teammates to get feedback. Yun said she would preferred if I could integrate a real-time clock into the circuit instead of using a photoresistor and a potentiometer to control it. I liked that idea, but because Tinkercad does not have that ability, I cannot implement it; if we can physically build a circuit, that might be a possibility. They liked that I added an extra knob to adjust the brightness of the LED/lightbulb, and we discussed a possibility of adding another knob to adjust the volume of the music. This is a good idea, and I would like to integrate it, but again that is not possible with Tinkercad and its piezo component.

Moving Forward

When we talked through our prototype presentation with Emily, she told us that she would actually like if the detector was against a wall next to her fridge, connected to the power outlet there. This is the spot that most of the mice appear in her house.  I was a little surprised to realize that it was quite hard to design a looks-like model without knowing where exactly to put it, so it was nice when she showed us the location on Zoom. In terms of how our design will look, we still need to decide how this will change our design, as well as a potential tunnel that we will have for the mice to stay within (so that the sensor won’t detect other people or Emily’s son’s cat). Then, although I did not address it in this prototype, we may add a glow (light going on inside) for visual notification, and I think the panel may not be necessary, depending on how effective the glowing up will be. The glowing can stay turned on until she presses the reset button, while the audible notification can just turn off after 30 seconds, etc. We also need to think about what will happen with the detector when Emily is not at home. I think at this stage of the project, we got a lot of critical feedback and there wasn’t much to ignore.

It was meaningful to make a behaves-like prototype using some miscellaneous crafts in that we could get the feedback from other people who were not involved in the ideation and design process. However, it could have been better if Emily herself could interact with the device and giver feedback based on the real experience whether the device is safe and comfortable to use, whether the design is appropriate for the space she want it to be, and some evaluations on the entertainment factors. For creating a CAD prototype, we did not have a particularly difficult situation from the fact that we could not physically show. Nevertheless, it was unfortunate that we couldn’t actually visit her house to make observations. In comparison, making a works-like prototype without building a physical circuit is quite frustrating due to the limited functions of Tinkercad. It made it impossible for us to add components useful for the mouse detector, but not already on Tinkercad.

We will look into how to make the mouse detector only detect mouse by putting it in a tunnel that only a mouse would fit. That would involve designing the tunnel and re-designing some of the structure and electronic components. We will refine the features and forms of the parts, and figure out how to add any new features (ex. volume controller). We will also be looking into what kinds of material will be good for durability, appropriate for glowing, etc.

This document highlights the prototyping process of our assistive device for Diane. The interviewing and ideation process can be seen here:

https://courses.ideate.cmu.edu/60-223/s2020/work/meeting-with-diane/

We decided to create a personal metronome for Diane. It will take a form factor of a wristband, and allow Diane to choose different frequencies that will output as a vibrating buzzer.
We took three separate approaches to the prototype, where we looked at how we wanted the device to behave, work, and look like. 

Prototyping

Behaves like (Elizabeth)

This prototype served to answer how Diane can intuitively customize her metronome beats without verbal instructions. Main considerations were put into how various buttons should be placed on the bracelet, as well as the types of feedback Diane should receive in order to set the beat frequency to her desired speed. The prototype was made in two versions — first, through paper prototypes to determine how Diane would customize her beats and two, through a paper model to determine a user-friendly form.

Overview of functionalities

Before I began making the prototypes, I sketched out different ideas to see how Diane should be guided in customizing her beats. Based on our technical framework, our user flow was: 1. Diane turns on the bracelet through a on/off switch. 2. Diane presses the center button three times, according to her desired frequency. LED and haptic feedback would indicate that she is in the “customize” state. 3. The metronome begins based on the customized frequency. LED turns off, to indicate that she is now in the “metronome” state. 

Clarifying the difference between the “customize” and the “metronome” state was the key issue at hand. While I initially thought that one LED may suffice to reflect the beat pattern, I received feedback from my parents that it would not be clear that they have to press three times. As such, I opted for three LED lights to reflect a sort of progress bar.

I began with how the prototype should feel like in its 3d form, to understand the types of inputs and outputs Diane would interact with. While I initially worked with clay for easy adjustment of the form, the clay that I owned was too crumbly to add appropriate details. 

Initial clay model. Too crumbly to make detailed prototypes. Tried out circular form, for perhaps a rounded display, rather than rectangular. 

As such, I created a model using cardstock paper. This was particularly successful, as it gave me precise control over the placement of buttons and the LED feedback.

Scored and cut out box on cardstock for housing of electronics The main insight from this was that the button should be placed inwards to prevent any accidental presses. This naturally meant that the button should take up most of the real estate on the model, as it needed to be big enough for a finger to go in. When testing this with my parents, they found it pretty straightforward. My mom liked how simple it was, as having too many buttons would be confusing and frustrating to figure out.

Inward button to prevent accidental presses. Small form factor for least amount of intrusion.

The second prototype came through paper prototypes of the user interface. I tested this with my parents, by giving them different “screens” and telling them how the interface would react. While they were initially a bit hesitant to play around with it, it gave me a better idea of how the haptic and visual feedback should be patterned.

My initial iteration was that at each time you press the button, you get a single haptic feedback, and the number of lit LED lights increases with each press. My dad pointed out how it would be more intuitive if at the second press, you get two beats based on the frequency of the beats you customized, and only after the third press, you get the whole metronome. 

As for my mom, she said that she would rather have set frequencies to dial through, rather than create the beat herself. To her, customizing the beats implies that she would be able to have variations in the vibration feedback, but since this was a metronome, she would rather prefer going through set beats. I was rather surprised to hear this, as this was a much simpler solution that we hadn’t approached, simply because it didn’t seem as interesting from a maker’s perspective. However, I could see why a simpler solution is more user friendly. While my mom’s suggestion was very valid, since the “customization” was our main feature for this iteration, I decided to go forward with my dad’s direction instead. 

The following is the final experience paper prototype. I followed my dad’s suggestions of giving two vibration feedbacks upon the second press:

When talking with Diane, she wanted a couple changes to the prototype. First, she much preferred my mom’s suggestion of dialing through set frequencies, rather than customizing her own beats. (This meant creating a whole new interface to determine how Diane should dial through five to eight modes of frequency.) Second, she brought up concerns with the LED lights, as she didn’t want to bring any attention to the device. When I told her that it would only be lit in the “customize” phase, she was more relieved. However, this was a good feedback to keep in mind, as I knew that the LEDs should be as small and inconspicuous as possible.  Third, she liked the small form factor, particularly since she has a small wrist. 

One important insight was that Diane does not want the bracelet to look like a medical device, or even a typical fitness bracelet. She was happy with the looks of Chloe’s prototype (shown below), but her preference towards aesthetics was important to prioritize for future iterations.

Looks like (Chloe)

The front view of the prototype

The side view

This prototype was designed to help answer. The design question: what the device would look-like. This prototype is in two forms, one physical and one digital. The physical prototype is made out of clay, and it shows what it will look like when it is in use. The digital prototype shows more realistic, detailed design as a product. 

The beginning of the prototype.

Telling her the face will be placed here

https://drive.google.com/file/d/19xJQwwU0UHXcEqI3ZDZhMnkBVBEy7Owp/view?usp=sharing

It was interesting to work on a “look-like” prototype that will be having a human  interaction. I realized that there were so many parts to consider when it is designed for a personal use. Our Osher student had most concerns about its look, afraid of people seeing it as a medical device. I believe that nobody should feel ashamed or embarrased about assistive/medical device, yet  I do understand her concerns, and since our task is to assist with out client’s personal need, I followed her idea and tried to make it look “cool (in direct Diane’s words)” so that nobody sees it as a medical device. Diane went further with her feedback and asked if the design could get simpler, as it would look like a silcione cuff, and I agreed. As much as the wiring does not get in the way, I agreed to make it look simpler. My local person mentioned about the material and preferred hand of my client. I have decided to use silicone as material, since it is resistable to water, sweat, and rust. Also from the question about preferred hand, I figured out that Diane is right handed. I was surprised that she actually thought the design was fashionable. I have always made artworks with Rhinoceros 6, but regarding that this was my first time designing a product, Diane’s comment really motivated me.

The process went smoother than I thought. I think taking the feedbacks from last class and integrating the buttons and  LED into the wristband and altering its look in to a silcone cuff would be aesthetically pleasing and achievable at the same time. The next step for me would be figuring out the dimensions of the parts that will be embeded under the silicone. Even though I am the most experienced person with 3D modeling in my team, I never worked thinking within the precise dimensions; therefore, I think it will be a good challenge for me. Next time, I think I would use a different program (maybe) for the looks of it. I am more comfortable with Rhinoceros 6, yet I think it looks more detailed and well-presentable when it is done in Fusion360. For my own practice and development, I think I might try Fusion360.

Works like (Ivan)

My prototype was designed to test out one specific method of input for our device. To keep our device extremely compact, we thought to only have a button as input and a switch for on and off. Thus, we had to figure out if there was a way to input frequency using just one button. The prototype takes in three presses of the button, and takes the average time between the two intervals, and sets that as the frequency of our output. It does this by keeping track of four states. States 0, 1, 2 are when the device is waiting for input, and state 3 is when the device produces output. 

Tinkercading the input test

Reading the Serial Output for the 0-3 States

const int BUTTONPIN = A4;
const int REDPIN = A2;

int state = 0;
unsigned long timeStore[] = {0,0,0};

int freq;

bool buzzState = false;

void setup() {
  pinMode(BUTTONPIN, INPUT_PULLUP);
  pinMode(REDPIN, OUTPUT);

  Serial.begin(9600);
}

void loop() {
  if (not digitalRead(BUTTONPIN) and state < 3){
    timeStore[state] = millis();
    state = state + 1;

    Serial.print("state: ");
    Serial.println(state);
    delay(100);
  }

  if (state == 3){
    freq = ((timeStore[2] - timeStore[1]) + (timeStore[1] - timeStore[0]))/2;
    buzzState = true;

    Serial.print("buzzstate: ");
    Serial.println(buzzState);
  }

  if (buzzState){
    analogWrite(REDPIN, HIGH);

    delay(freq);
      
    analogWrite(REDPIN, LOW);
   }
  
}

During my prototype testing with my friends I was with during my process, I got a lot of positive feedback. They thought the input was clever and intuitive. When I brought up the idea of a larger set of buttons, or a slider, they thought that even though it could work, it loses the simplicity found in this method of input. 

Video of input working in Tinkercad

However, when we showed this input to Diane, she brought up a good point that we didn’t think about. She wants there to be a preset range of frequencies, as opposed to making one for herself on the spot. This is something that this method of input cannot do, and she dislikes that. I think that answers the design question for this prototype extremely well. As even though we have found that this input is a feasible design, it is not the appropriate design for Diane, and we will need to rethink a way to minimize the input. We will be looking into alternatives that Diane brought up, of using knobs or sliders, while thinking about not making the device too bulky at the same time. It will be a challenge as knobs and sliders are more tactile, so they take up larger space, but we will be going down that path.

Moving forward

We think the prototyping process went fairly well. Under the odd circumstance, where there was limited material, and everything had to be done virtually, I think we were able to present our ideas well to Diane. The virtualness of it meant that it was hard for Diane to show us exactly what she wanted, as she could not form the clay or move things around herself. But we figured out what she wanted after a few back and forths. I think we will be revamping a lot of our design for this product. We will try to make it look more like a piece of jewelry as opposed to a device. And we have decided to use a different type of input, namely a SoftPot Membrane Potentiometer.

One key insight from Diane was that she would want some variation between the “inhale” beats and the “exhale” beats, for cases when she uses this to control her breathing in pilates. This was surprising, as she envisioned herself using this metronome in multiple scenarios, rather than a set instance of when she wants to be less restless. This indicated that our prototype should be more flexible towards allowing variations of use cases. While we are not sure if this would be a possible feature to add, this was definitely a food for thought to make our prototype more sophisticated. 

If we were to do this prototyping again, I think we would come together and make a more diverse range of prototypes, as opposed to three parts of one idea. I think that will show our client a better range of what could happen, and could allow for better discussion of what they would want.

All in all, we think that the prototyping process has gone very smoothly, and we are excited to implement the feedback we got into our final product.

After the team’s interview with Cynthia, we decided to build a device that would help train her dog who loves to chew sandals and other items like paper. In this documentation, we will go over the various forms of prototypes that were created to further develop the device.

The general idea of the device is to put an item, like Cynthia’s sandals, on a platform with PIR sensors that can detect wether or not the object has been moved. If the object is moved by Cynthia’s dog, the device will emit sounds at 25 kHz and LED lights will activate. The sound is meant to be at frequencies that only dogs can hear, but not humans, so as not to disturb Cynthia. There is an additional switch that Cynthia can turn on/off so that she may move/remove the object on the platform without the device going off. We hope that over time, Cynthia’s dog will learn what items he should not be touching and chewing on with the help of this device.

Ideation sketch

Prototypes

1. Works-like Prototype on TinkerCAD (Gracia)

This prototype was designed to help answer the question: what features are attainable to simulate and what are some limitations that we must keep in mind? The engineering prototype shown below was made on TinkerCAD and has four main components, a PIR Sensor, Neopixel Ring (LED), Piezo Buzzer, and a switch. When the device is on (controlled by the switch button) and the PIR Sensor detects movement, the Neopixel LEDs turn blue and the buzzer emits a sound. For simplicity, the alarm is deactivated when the detected movement has stopped. When the switch button is in its off position, no alarm will go off even if there’s movement detected by the PIR sensor. The color blue is a design decision based off color ranges that dogs are able to see and the sound frequency emitted is in the range detectable by dogs but not the human ear.

Final wiring of electrical components

Four main input/output components of the prototype

The video above shows the interaction when movement is stimulated in front of the PIR sensor when the switch button is off vs on.

The biggest issue that I encountered during the prototyping process is reducing the lag time in the simulation. When I first wired and coded my prototype, it took a really long time for the simulation to register changes in movement/no movement detection from the PIR sensor. It took about 1 simulation second, which translates to around a whole minute in real time. Thus, I tried to improve my code so that the system runs as efficiently as possible, which helped move things faster and reduce lag time. For instance, I eliminated redundant actions. In order to turn on and specify each pixel in the NeoPixel ring, it must be done one-by-one for each pixel. The simulation ran really slow if the show function for the NeoPixel is within the loop that updates each pixel’s color. However, it ran much faster the show function only happened once after the loop finishes. Additionally, I got rid of external functions. Even though the commands are exactly the same, I found that the simulation ran faster if the main loop function didn’t have to call an external function.

Update and show pixels individually

Show after all pixels are updated

Overall, I was able to get a general answer to my design question after going through the TinkerCAD library to see what components are available and implementing the basic function of the device. A lot of the feedback I was getting was also related to the slow response time in the TinkerCAD simulation. I will definitely be working further to take extra precautions when writing my code in the future so that the system can run as efficiently as possible. The slowness and non-instantaneous response was not surprising but it was surprising to find that eliminating functions helped reduce the lag time. This will ultimately make the code style unfriendly to outside readers, but I think it’s a tradeoff that is necessary for a better user experience.

Another feedback I received was that the device functionality itself was too simplistic. Going forward, I would like to add more functionalities to it without adversely affecting the simulation time. One idea I am going to work on implementing is to have a motor move the platform down and maybe have a mechanism that encloses the object when the alarm goes off. It’s another level of teaching the dog that he/she shouldn’t be touching the object. Even if the dog tries to get it, he/she wouldn’t be able to. I also plan to have “ON/OFF” labels on the switch since it’s not very intuitive.

2. Looks-like Prototype on Fusion360 (Amy)

This prototype was designed to help answer the design question: How might the physical appearance and form of the device be designed to look to achieve both functionality and clean aesthetics?

This prototype is a looks-like model of the dog-training device to help our team visualize what the final product will actually look like. Its form is an elevated platform designed to hold and detect Cynthia’s sandals via PIR sensors located beneath the glass paw print. Other components located at the bottom of the platform include a switch button, LED, and Piezo Buzzer. The model body is made with wood material and has a cylindrical form (80mm tall, 300mm wide).

IMAGES

Completed prototype rendering in Fusion 360

Aerial view of device and labelled components

Overall of device proportion and scale (mm)

PROCESS IMAGES

Planning sketches of the device appearance and dimensions before modeling

Creating different sketch layers for the model

Putting the sketch bodies together and setting material (glass and wood)

During the prototyping process, I found that it was really helpful to first have the design of the device sketched out ahead of time so I had a clear idea of what I was trying to build. A challenge I had while trying to build this model was figuring out how to use a lot of the tools in Fusion 360, since I’m not that familiar with the software.  I spent some time trying to figure out how to create rounded walls for the outer edge of the device. I eventually solved this by first extruding the circular face and then creating a smaller circular extrusion inside the larger one to hollow out the inside. Overall, there was definitely a learning curve, but with online resources and tutorials I was able to figure out most of what I needed to start designing the platform. Upon finishing the prototype, I think I was able to answer the initially proposed design question. The form satisfied what we needed in terms of both functionality and a clean, simple appearance, although there are definitely still improvements which can be made.

Some of the in-person feedback I received on my prototype included that the components seemed too small and difficult to notice, especially the LED and the button switch. Since the LED is supposed to light up as an indicator that the alarm is going off, it’s important that the light is noticeable. In addition, the shape of the device was called into question as the circular form didn’t seem very space efficient. For future changes, I plan to integrate the larger NeoPixel ring component into the device as a light indicator rather than a tiny LED light. For the circular form, I primarily chose it for aesthetic purposes because the round corners give it a smoother and more playful appearance. But I think I might also stick to it because since there’s no sharp corners, it will not pose as a safety hazard in case the user accidentally hits the edge of the device.

3. Behaves-like Prototype (seth)

This prototype was designed to answer the question of how the device might behave. It was made using only things available around the house–namely, a storage box and a playing card. The shoes sit on top of the box above the “sensors” and the indicator is lit up blue (blue playing card), meaning that the shoes are in place and not being chewed. When one or both shoes are removed, the indicator light turns red (red playing card) and the piezo begins emitting a dog whistle tone, indicating that shoes may be getting chewed. In the case of this prototype, my harsh screaming was substitute for a piezo.

There wasn’t much to creating this prototype due to the simplistic nature of it–see “it was made using only things available around the house.” However, it did successfully convey how the final device might actually behave once fully built and implemented.

IMAGES

Light is blue when shoes are in place.

Light is red and piezo emits a dog whistle tone when one or more shoes is removed.

Despite the simplistic nature of this prototype, it received positive feedback. My screaming as substitute for the piezo received some laughter and confusion at first, but after explaining, it made sense to the users (my parents). While it was ultimately quite large, since I used a storage box, it still successfully got the point across.

Moving Forward

Reflecting on the prototyping process, our team found that we were able to create a more comprehensive exploration by each focusing on a different kind of prototype. There were definitely added challenges which came with working remotely. For instance, communication within our team and toward our client was limited. Working remotely makes it difficult for us to fully demonstrate our prototype to our client, especially when showing it on a software like Fusion360 or TinkerCAD. For both cases, it’s hard to show real time demonstration of our creation so we must create videos beforehand so that our client can watch it at an appropriate speed.

In addition, it’s more difficult to get a sense of a cohesive device due to the barrier of having three separate prototypes that can not be integrated together. Since each member was working on their own prototype, there were slight inconsistencies between each one such as different components or variations in form. However this was actually beneficial for us in terms of exploring different ways to achieve a result rather than being tied down by one method. In the future, we might try to develop a more solid idea of the details of our prototype before starting to work individually. Overall, the prototypes are still able to convey the vision for our device successfully.

After receiving feedback from Cynthia, our team decided to add a couple additional features to improve our device. We plan to include an additional reminder to walk her dog as well as an adjustable volume knob. We will be implementing a real time clock so that the device can keep track of time and notify Cynthia at 8AM that her dog should have already been walked. Also, we will use a potentiometer to control the volume of the alarm that is meant for Cynthia. With these added features, we are hoping our dog-trainer can be more customized and well-suited towards Cynthia’s needs.