What We Built

Our talking scale functions as a typical scale, able to measure how much an item placed on it weighs, with additional functionality that allows it to be accessible for a blind person. For example, each function that we have also has an audio cue. In addition, our buttons have printed braille labels that allow Justin to be able to read what each one does.

Overall view of the final product

Grate for the speaker

Buttons for unit change, tare, and speak functions

Knob to control the volume

Braille strips graciously provided by Justin

Our talking scale functions as a typical scale, able to measure how much an item placed on it weighs, with additional functionality that allows it to be accessible for a blind person. For example, each function that we have also has an audio cue. In addition, our buttons have printed braille labels that allow Justin to be able to read what each one does.

Narrative Sketch

As Justin prepares his yearly deer jerky, he goes to his kitchen and to his kitchen counter, where he has his Talking Scale. He plugs it in, and it does a little musical motif to notify him that it’s on. He places a bowl in the middle of the scale and pushes the middle button, which reads “tare” in braille underneath in order to zero out the scale. From the speaker, the scale says, “weight is now zero” indicating that the tare worked. He then places the jerky in the bowl, and presses the button on the right, which has the “talk” label in braille. The scale reads out, “One point one pounds,” telling him that the jerky weighs 1.1 pounds. He also wants the reading in grams, so he presses the left button, which has the “units” label in braille, changing the units. The scale says “grams” indicating that the unit is now in grams. He presses the talk button once more, and it reads out, “four hundred ninety nine grams,” telling him the weight of the jerky in grams. Satisfied with the weight of his jerky, he is able to successfully partition it out.

How We Got Here

This prototype was designed to help answer the design question of how we would get the load cell to work and how we would design the scale to be as accessible as possible for a blind person.

As such, our prototype had a working load cell. We also had a Fusion design mockup, and braille prototypes for Justin to give feedback on.

Sketchbook work brainstorming forms of the project, as well as how to integrate the mechanism of the load cell

Progress shot of different braille squares produced by experimenting with different laser settings

Progress shot of the CAD file at the onset of the project

Overall view of the prototype

Closer detail look at the load cell, the tool with which we weigh objects

Closer details of the wiring and chips used in the prototype

Above is a video showing how the prototype was used: at this stage of the process, we had set up a small load cell, which sent information about the weight of the item placed on it to the Arduino, which sourced from a library of spoken numbers to speak the correct weight through the connected speaker

PROTOTYPE DEVELOPMENT

This device was developed to provide an accessible kitchen scale to our client who is blind. Our prototype included a scale using a 1kg load cell, and laser cut braille samples.

When we started our project, we came up with a few variations on the design. Originally, we wanted to incorporate bends into the structure, knowing that it would take more time to figure out the logistics. However over time we determined a simpler design was going to be our best bet, which was fortunate as we had to re-cut several pieces, which might not have been as easy if we had decided on the more complicated design.

We wanted to use an online library of a person saying different numbers, which we had for our prototype, but after some discussion, we decided these audio files were low quality, and that it would probably be best to make our own sounds for this specific project. We were fortunate to have Shenai voice over 100+ different audio files, covering the numbers 0-100, and then the hundred places, and then the units included. Though we were told that using an online resource might be better, we were happy to find success in our homebrewed method.

One thing we were unable to include in the final that we had for our prototype was laser cut braille. We wanted to create tactile markings for our client using a negative space approach to creating braille, and were able to send Justin our samples from this experiment. Justin showed great enthusiasm for our work on this, which was heartening to us, and he taught us some interesting facets of braille that we didn’t know. What kept us from this technique in the final was actually that Justin brought a braille labeler to class because he thought we might be interested. We were all really intrigued by this device, and quickly came to the realization that it would be a more efficient and appropriate method to label the device than what we were planning on. Justin printed out the labels for the different buttons and those labels are what ended up on the final version.

Process

Reworked CAD files of the plates bracketing the load cell

Reworked CAD files of the overall box design

Our original braille descriptors

Strips of braille from Justin

Freshly laser-cut box

… and its accompanying 3-D model

Screwing in the load cell to the final product

Freshly soldered connections, necessary for a tool we intended to hand off to another person to use regularly

Final product without the top plate, with a clearer view of the load cell

Throughout our process, we made many decisions which altered our original plans to either something more manageable for us or intuitive/functional for Justin, some of which are discussed previously in the prototype discussion. To add to the choices mentioned above, we made a lot of design choices specifically for Justin, such as making the box blue as it was his favorite color, and adding a rim around the edge of the weighing platform, an atypical feature in most scales, but one which helps him feel where the weighing space ends.

Though we expected the CAD file to be mostly correct, and thus only allotted about a day to troubleshoot and finish the laser-cut box, there were many small mistakes in the design which caused us to re-cut a handful of the pieces. Because the box was so small, many of these revisions addressed spacing issues within the box to allow for different electronic devices to physically fit. However, otherwise, we largely stuck to our schedule of tasks, and it resulted in a product that mostly functioned in the end!

Conclusions and lessons learned

On presenting our project to the world at large (or at least, the members of the class and our special guests), we received a lot of good criticism and feedback.

In particular, a few people noted how exactly we read out the different weights, noting that we could “Change pounds with decimal value to pounds + ounces.” This would definitely improve the quality of our project, since in the kitchen things rarely are used in terms of decimals, instead being broken up into pounds and ounces for ease of measurement.

We also got multiple criticisms of the design of the top, noting that we should “Maybe look into making the weighing surface not recessed. Harder to place large plate on it, for example.” However, this was a specific request by our client, who noted that he wanted there to be a raised edge around the top of the scale so that he would be able to feel out where the edge was. Although, during the walk-around critique, someone suggested that we simply add the raised edge as part of the top of the scale, instead of part of the housing of the scale, which may have solved the problem.

“The middle button needs to be tapped twice – better button robustness.” We had a lot of problems with the buttons, which might be just a problem with how the buttons are placed within the scale, needing either to be tapped twice or pressed extra hard for it to register. We might need to add extra supports onto it.

“The speaker system seemed to be a bit wonky, possibly the scale wasn’t sensitive enough for initial triggering.” We realized after the critique that there were issues with the speaker not saying certain words, which ended up being fixed due to some fiddling with the code. Otherwise, it should trigger upon button press.

Although we ourselves were not remote for this project, our initial interview with Justin was. Being that he was blind, the video call was at first a bit awkward, but as we got into the conversation it flowed a lot better. We were also able to work out a preferred way to contact him that allowed us to effectively communicate.

Working with a person with disabilities was a new experience for all of us. During our initial discussion with Justin, who is blind, we discovered how significant accessible design is. There were so many aspects of life that an abled person might take for granted, that require solutions for those with disabilities. Justin was so kind and willing to teach us, that it became hard to determine what project to work on.

If we were going to do this again, I think we would spend more time learning about accessibility for blind people. We learned a lot during this project, but it became clear that there was much more to learn about accessible design.

A key concluding thought we had after completing this project was that it is extremely important that design be accessible to everyone. Justin mentioned a variety of everyday problems that he encounters, and we wished we were able to help with more. I think we were all satisfied with our final result, but it’s easy to think about how it could have been done better. I think we came to a final design that we were happy with and that addressed Justin’s concerns, however given more time, we would have liked to make the device rechargeable, as well as include a louder speaker. Of course we would also like to work out any kinks in the readings, perhaps with a more accurate load cell, but we were satisfied with the results we were able to achieve. I think our main lesson was the importance of accessible design.

Technical details

Schematic and block diagram

Block Diagram + Schematic

Code

/* 
 *  Talking Scale
 *  Shenai, John, and Julia
 *  This takes in the scale readings and then reads them out appropriately, accessing
 *  files in the mp3 player and playing them. 
 *  
 *  Pin mapping: 
 *  LOADCELL_DOUT_PIN  3 
 *  LOADCELL_SCK_PIN  2
 *  SPEAK BUTTON 7
 *  TARE BUTTON 8
 *  UNIT BUTTON 9
 */

#include "Arduino.h"
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"
#include "HX711.h"

#define LOADCELL_DOUT_PIN  3
#define LOADCELL_SCK_PIN  2
#define ZERO 102
#define POINT 103
#define STARTING_SOUND 106
#define SPEAKBUTT 7
#define TAREBUTT 8
#define UNITBUTT 9
#define GRAMS 104
#define POUNDWORD 105
#define TARE 107


HX711 scale;
//Correct calibration factor: ~405
float calibration_factor = 405; // this calibration factor is adjusted according to my load cell

SoftwareSerial mySoftwareSerial(10, 11); // RX, TX
DFRobotDFPlayerMini myDFPlayer;
bool pounds; 

void setup() {
  mySoftwareSerial.begin(9600);
  Serial.begin(9600);
  pinMode(SPEAKBUTT, INPUT);
  pinMode(TAREBUTT, INPUT);
  pinMode(UNITBUTT, INPUT);
  digitalWrite(SPEAKBUTT, HIGH);
  digitalWrite(TAREBUTT, HIGH);
  digitalWrite(UNITBUTT, HIGH);
  pounds = true;
  

  Serial.println();
  Serial.println(F("DFRobot DFPlayer Mini Demo"));
  Serial.println(F("Initializing DFPlayer ... (May take 3~5 seconds)"));

  if (!myDFPlayer.begin(mySoftwareSerial)) {  //Use softwareSerial to communicate with mp3.
    Serial.println(F("Unable to begin:"));
    Serial.println(F("1.Please recheck the connection!"));
    Serial.println(F("2.Please insert the SD card!"));
    while(true);
  }

  myDFPlayer.volume(30);  //Set volume value. From 0 to 30
  myDFPlayer.playMp3Folder(STARTING_SOUND);  //Play the starting sound
  delay(2000);
  
  scale.begin(LOADCELL_DOUT_PIN, LOADCELL_SCK_PIN);

  scale.set_scale(calibration_factor); //Adjust to this calibration factor
  scale.tare(); 
}

// gets a scale reading
float getunits(void) {
  // gets an average of a few readings in order to be accurate
  float units = 0;
  units += scale.get_units();
  delay(100);
  units += scale.get_units();
  delay(100);
  units += scale.get_units();
  delay(100);
  units += scale.get_units();
  units = units / 4.0;

  // adjustments
  if (units < 0) {
    units =  0;
  }
  if (pounds) {
    units = units / 454.0;
  }
  return units;
  
}

void loop() {
  // changes the volume
  int volumevalue = analogRead(A0);
  int newvol = map(volumevalue, 0, 1023, 0, 30);
  myDFPlayer.volume(newvol);

  // gets units and then reads them out
  if (digitalRead(SPEAKBUTT) == LOW) {
    float units = getunits();
    read(units);
  }
  // tares the scale
  else if (digitalRead(TAREBUTT) == LOW) {
    // extra tares for insurance
    scale.tare();
    delay(100);
    scale.tare(); 
    delay(100);
    scale.tare();
    myDFPlayer.playMp3Folder(TARE);
    delay(3000);
    scale.tare();
  }
  else if (digitalRead(UNITBUTT) == LOW) {
    pounds = !pounds; 
    if (pounds) {
      myDFPlayer.playMp3Folder(POUNDWORD);
      delay(1000);
    }
    else {
      myDFPlayer.playMp3Folder(GRAMS);
      delay(1000);
    }
    
  }
  
  
}

// separates out a number into its component parts and then reads it 
void read(float weight) {
  float fractpart;
  float intpart;
  fractpart = modff(weight, &intpart);
  // separates out the number 
  // this works anyway because of floats
  int decimal = (int) (fractpart * 100 + .5);
  int integerpart = (int) intpart;
  if (integerpart >= 1000) {
    int thousand = integerpart / 1000 * 1000;
    myDFPlayer.playMp3Folder(thousand);
    delay(1100);
    if (integerpart % 1000 != 0) {
      int hundred = integerpart % 1000; 
      if (hundred / 100 != 0) {
        myDFPlayer.playMp3Folder(hundred / 100 * 100);
        delay(1000);
      }
      if (hundred % 100 != 0) {
        myDFPlayer.playMp3Folder(hundred % 100);
        delay(1000);
      }
    }
  }
  else if (integerpart > 100) {
    myDFPlayer.playMp3Folder(integerpart / 100 * 100);
    delay(1000);
    if (integerpart % 100 != 0) {
      myDFPlayer.playMp3Folder(integerpart % 100);
      delay(1000);
    }
  }
  else if (integerpart > 0){
    myDFPlayer.playMp3Folder(integerpart);
    delay(1000);
  }
  else if (integerpart == 0) {
    myDFPlayer.playMp3Folder(ZERO);
    delay(1000);
  }
  // only reads the decimal part for pounds
  if (pounds) {
    myDFPlayer.playMp3Folder(POINT);
    delay(1000); 
    if (decimal / 10 == 0) {
      myDFPlayer.playMp3Folder(ZERO);
    }
    else {
      myDFPlayer.playMp3Folder(decimal / 10 );
    }
    delay(1000);
    myDFPlayer.playMp3Folder(decimal % 10);
    delay(700);
    myDFPlayer.playMp3Folder(POUNDWORD);
    delay(1000);
  }
  else {
    myDFPlayer.playMp3Folder(GRAMS);
    delay(1000);
  }
}

 

WHAT WE BUILT

For the solution we designed a hood, inspired by a stroller hood, that is motorized and controlled by the user with two buttons. At least, that was the initial plan. Due to unforeseen circumstances and given our time constraint, we were only able to build the hood, and could not motorize it. The hood goes from the back of the wheelchair and then moves to a position above the client that protects her from the rain.

Narrative Sketch

As Cam is about to leave her house it starts to rain. She realizes this and as she is about to leave through the door presses the open button, which is located just below the joystick on her armrest. The hood then opens up covering her body and protecting her from the rain. Once in the vehicle, she then presses the close button to close the hood, moving back to the back of her wheelchair.

PROTOTYPE & PROCESS

*confused i think cuz i was writing about the final design instead of the prototype so gonna have to rewrite statements below

This prototype was designed to help answer the design question: “How can [client] keep themselves protected from the rain while still being able to control their wheelchair?”

The prototype shown below is a smaller version of the hood made using plastic ribbing and trash bag material.

Top view of the prototype fully opened.

Side view of opened hood.

Design sketch.

Sketch of hood.

Initial version of prototype

At first, we wanted to create the hood as shown below, with each rib of the hood on their own separate axis. However, we realized that this overcomplicating the device, and that the ribbings could all be placed on the same point of access, so the prototype was simplified in this manner.

Initial prototype laid out with ribbings attached

Initial prototype with ribbings and other components laid out

Whiteboard sketches made during prototype process

Whiteboard sketches made during prototype process(continued)

From prototyping the hood portion of the assembly, we were able to figure out how we wanted to construct the moving parts of the device. At first, we unsure on how we wanted the ribbings of the hood to be attached to the device: Did we want them all separate or on one rod? But by prototyping, we were able to come to the conclusion that using one rod mount is simpler. During prototyping, what sort of materials to use was another question we began to address, but never really answered until later in the project, post-prototype. We also wanted to create a motorized version of the prototype, as seen by the servo motors in the pictures above, but due to time constraints, we were unable to make this a reality. In hindsight, this was a good choice, as a motorized version would have been difficult when moving around the hood with the client when making measurements. During prototyping, we were also unable to come up with a solid construction or plan on how to attach the hood onto the wheelchair, a major concern that would be addressed later in the project after we met with the client in person and made measurements.

Overall we received positive feedback on our first prototype, no recommendations were given for us to consider and incorporate into our final design. However, the client did specify, when asked, whether or not she wanted a button-operated device or a joystick-operated device, as well as saying that she wanted the hood to be a large enough size to not make her feel constricted. When it comes to critiques of the prototype, we had thought that a full-shell version of the hood, with a full-180 degree range, would be the final design of the hood. However, after feedback from the client, we moved to a quarter-shell design, with a 90-degree range of protection. What surprised us as well was how large the actual hood would need to be after taking measurements, as the hood’s width alone would be about 32 inches.

PROCESS

The Retractable Rain Hood attaches to the back of the wheelchair at three places with clamps. These three clamps connect to a box, and at the top of the box is the system that attaches to the hood. The hood is designed to be a quarter of an ellipsoid and so the two wooden strips (reinforcements) in the hood are different lengths. The entire piece is made from wood and then a clear trash bag is what the hood is made from.

At the beginning of this project we were both very concerned and stressed about how and where we would complete this project. One of the things we were worried about was how we would connect the Retractable Rain Hood to the wheelchair in a place that would support the piece and also not cover up anything important on the wheelchair. After meeting with our client and getting to see the wheelchair in person we were able to come up with a solution to our main concern, and this was to clamp the Retractable Rain Hood at three points in the back of the wheelchair. At the end we were able to come up with a design that properly addressed our problem, apart from it being motorized though of course.

When it came to creating the wooden strips in the hood, first we laser cut 3 panels to curve the strips against. Since two of the curved panels were too large for the wooden sheets we had to cut them into four pieces. We also laser cut thin rectangles to turn into the wooden strips. After this, we glued two rectangle pieces together with different lengths and clamped them to the panels, we continued this, while fitting the rectangles into each other, until the wooden strips were complete. The hardest part during this process was the whole thing, but especially so when we got to the part of the panel that was curved. We had a hard time fitting the rectangle pieces together at the right lengths and keeping them flush with the panels. At times the rectangle pieces would pop out or broke from the tension of the curve. Another difficulty we faced was a result of two of the panels being being made from four pieces because it made it harder to keep the rectangle pieces at the right position. However, after creating the first wooden strip we were able to speed up the process for the other two.

One of the things that took longer than expected was deciding on the materials. That along unforeseen circumstances caused our planned materials to not get here on time as expected. Something that we forgot to properly take into consideration is that we had planned to do things during Thanksgiving break and so that definitely did not work out. Also, because of this and other things we changed the project to just focus on building the piece and removed the part that would make it motorized. So our schedule completely changed and we did not refer to it much after a certain point.

CONCLUSION

During our final critique, we really enjoyed hearing feedback and critique from others. To start off one of the feedback we received was, “When first hearing of the project, I worried it would make the wheelchair user look like a baby in a stroller. However, the design you came up with showed me that my opinion was unfounded, and it actually looks good.” This was really interesting to hear as this was not something that we thought much of during the design process. This is also probably because we thought that our material choice would take away from that. But overall we were happy with our final design choice. The next feedback that we received was to “Lean in” on boxiness–>provide storage. Use lay-up technique for “bending” wood. Tinted canopy.” We really appreciated this feedback because it makes the most out of our design giving our client another place to store things on her wheelchair. We also love the idea of using a tinted canopy which would still give our client the chance to look out of the hood while maintaining some sort of privacy. Next, someone stated “consider when the rain hood is down, there might be rain on it and get the person in the chair wet when extended.” This is a really good point and something we had not considered much surprisingly, we were hoping that the water would all fall out once the hood was completely closed again. But that is something that we would have to think through more to ensure that the water did not pool up in the hood. Lastly, someone said “Manufacturing limitations severely affected design decisions.” This was definitely the case, and during a conversation with one of the visitors it was really interesting to hear about the other processes to consider.

Working remotely with our client was a bit difficult mainly because our product heavily depended on being able to see the wheelchair in person. This delayed part of our design process as we did not know how we would fit it to her wheelchair until later on. In retrospect, something that we would have done differently is have more meetings with our client to properly update her on the changes made in our project. We also could have sent her more pictures of our process. Working with our client was great for both parties though and we all enjoyed the process.

After working with a person with a disability, we were just really surprised at how many things don’t already exist. We also learned that you can not make direct modifications to a wheelchair as that would void any warranty that came with it. It would have been really great to see the wheelchair in person one more time to make sure the clamps fit properly.

Looking back at our process some things that we would have done differently include doing better research on the materials and better time management in general. Overall, despite the many mechanical problems and our concerns, we successfully designed and built a product that both us and more importantly our client were happy with.

TECHNICAL PARTS:

We unfortunately did not have any code to supplement our device, as it created as a non-motorized version. However, attached below are the .dxf files, compressed as a .zip file, for the mounting attachments, clasps, riser box, and rod mounts that could be use to laser cut.

RiserDXFFiles

1. Introduction

For our final project, we were tasked to work with a client to develop a personal assistive device which would help improve an aspect of their lives. Our client, Brenda, uses a power chair and spends the majority of her time with it due to limited mobility. One problem she was very enthusiastic about solving was using an umbrella that would cover the electronics on her power chair if it was raining, and which could also be used as a sunshade when she participates in protests in the summer. So, for our project, we decided to realize the idea that Brenda proposed– an automated umbrella opener and closer which could be mounted on the back of her chair and activated easily without having to hold the actual umbrella. For more details and interview documentation with Brenda, please see here:

Interview Documentation Team Pomegranates

2. What We Built

Our project works very simply. The umbrella and the control boxes are to be mounted to a power chair, utilizing the existing interface of the back of the chair. The device has three buttons the user operates to control the umbrella. The power button allows the other buttons to be activated, so the umbrella isn’t accidentally raised or lowered when not desired. The device plays a little jingle to alert the user that the device is on. From there the user uses the other two buttons to raise and lower the umbrella respectively. The buttons activate a motor which pulls a string attached to the top of the umbrella, to pull it to the open position.

Since Brenda wasn’t able to make it to our final critique, we weren’t able to mount the device on her wheelchair. However, we look forward to connecting in the future.

Final working video – button presses engage motor either CW or CCW to pull rope through pulleys mounted in the base box and at the umbrella apex and tension or release the umbrella

The Control Box houses the buttons that Brenda uses to power on/off (green) the device as well as raise and lower the umbrella. The box is mounted such that the two white buttons are aligned vertically, where “raise” is on top of “lower”.

The box hosting the wiring, motor and pulley system.

The box as well as the umbrella itself are mounted to an aluminum extrusion beam.

The aluminum extrusion beam attaches to Brenda’s chair using the black clips that pin to cylindrical components of the chair. The pole of the umbrella is also connected similarly to where Brenda’s headrest is, to prevent the umbrella from wanting to rotate.

An inside look at the box shows the orientation of the motor amidst the wires and battery pack used to power the device. The motor spins the pully to wind and release the string used to raise and lower the umbrella. The worm gear inside the motor, prevents rotation of the axel when the motor is shut off or when the umbrella is raised so that it stays raised during use.

The string goes up the pole of the umbrella and around another pully fixed at a bearing at the top of the umbrella. This bearing is bolted into the umbrella pole allowing the string to pull up the “runner” which slides up the pole to open the umbrella. Typically, the runner is moved manually, but our device automates this procedure.

Umbrella at a open position

Umbrella at a close position

Brenda spends most of her waking hours sitting in her wheelchair, so accessibility is super important. On a given rainy or very sunny day, Brenda would decide to use our assistive device to protect her from the elements. With some help attaching the mount to the back of her power chair, Brenda is ready to be outside and go about her journey without any additional assistance. With the press of a button that is easily in reach on her left arm rest, Brenda powers the device, allowing her to control raising and lowering the umbrella by pressing and holding the adjacent buttons. The umbrella is able raise and lower while not obstructing Brenda’s vision in front of her and protects the entirety of the power chair due to the large diameter when raised.

On a particular rainy day, Brenda doesn’t worry about driving her chair through the rain because the umbrella will protect the controls and electrical components of the chair that are susceptible to water damage. The umbrella will protect her from the rain, and she is able to raise and lower the umbrella freely to accommodate her busy work schedule.

In the summer, Brenda chooses to attend a protest but is worried her chair’s stature will cause her to get lost in the crowds. To both protect her from the sun and help the people she is with to identify her in a crowd, Brenda uses our device to stay safe and be independent while fighting for what she believes in.

3. Prototypes and Process

This prototype was designed to help answer one question: does the motor we decided to use to pull the umbrella open have enough torque to lift the runner of the umbrella due to the umbrella’s size and weight.

For our prototype, we only utilized the top half the umbrella pole and attached the motor, pulley assembly to the pole using duct-tape. Using a borrowed motor driver and a lever switch, we were able to control up, then down of the umbrella using a single press for each. At this stage the switch activated the motor to rotate for a fixed amount of time. We had to hold the umbrella upright as no mount was created at this point. Additionally, we designed and 3-D printed a bearing for the top of the umbrella which held a pully, allowing the string to raise the umbrella. The motor wounds the string in tension to pull up, and releases that tension, relying on gravity to bring the umbrella back to the lowered position.

We grounded the motor to the base of the umbrella pole using duct-tape. This ensured consistency in the raising and lowering as the motor was only set to rotate for a specific amount of time.

The first iteration of the bearing we made was too big for the width of the pole. This happened because we had to send the part to the 3D printers before the umbrella was delivered. We were able to use a piece meant to lock the runner in place to rest the bearing on during the prototyping phase. The same design was updated with a smaller diameter for the final product.

Figuring out the wirings for the motor

Prototype of motor with bottom pulley attached responding to up and down button presses

Findings from the Prototyping Process

The answer is: the motor we decided to use does have enough torque to lift the runner of the umbrella and pull the umbrella open despite the size and weight of the umbrella. 

Feedback from the Critiques

One feedback we received from the critique was on the power of the system. For the prototype, to supply power, we had to plug in a 12v power supply. That is not ideal because Brenda would need to find power supplies. Thus, we decided to change it so that the whole system is powered by a battery pack; changing batteries once in a while is comparably easier.  

Another feedback we received was concerning the accidental activation of the system. Based on the feedback, we added an on/off button to act as the safety switch. The up/down control buttons would not work unless this on/off button is pressed; this adds another layer of protection to accidental activation.  

One feedback we didn’t quite address in our final design was designing for different umbrellas. Brenda mentioned umbrellas are consumables, so she would like the system to be usable by other umbrellas as well. We tried to address this feedback, however, ended up focusing on making the system work for the specific umbrella we had. If we had more time, we would love to make it work with other umbrellas as well.  

Surprises

One surprise knowledge we learned during the prototype process was that humans can act as resistors. We were wiring the motor and at one point, the motor only ran when a person was holding the wires. We tried adding in a resistor, and it sort of worked. So, we learned humans can have resistance of as high as 100,000 ohms. However, in the end, it turned out that we didn’t have a ground for the wiring which was the real problem. So, now we know humans can act as both resistors and ground.

Process

A lot of planning, drafting, redrafting, and revisions went into designing this project. Here is a (mostly) chronological record of our work sessions throughout the weeks.

Initial schematic drawn for clarity after scrapping the gear track idea and confirming that the beach umbrella was gravity tensioned

After we received the umbrella, work sessions got a lot more crowded but way more tangible. We made a ton of design choices and swapped out parts from IDeATe Lending out for ordered components– sometimes requiring rewiring and redesigning.

Umbrella is usable in midst of figuring out how to attach runner to pulleys!

Fitting the lever switches with arcade buttons for ease of use

An angle of the motor, motor driver (old Pololu), and Arduino (which would go into the control box) and the control interface (small box), with the external 12V power source connecter still attached

Process update for the control interface box, with old H-Bridge chip, with switches working and assembled

Progress photo of new H-Bridge motor driver connected and operational with new 12V battery pack– temporary connectors still attached and system not soldered yet

Then it came down to fitting all the components into the control box. One big issue we had was attaching the crossbar to the back of the control box and also securing it to the worm motor. This process took a lot of elbow grease (and literal machine grease), soldering, resoldering, and sawing screws and the metal stem of the umbrella.

Drafting work being done to design how the motor and pulley would fit inside the control box and how the control box would be mounted to the back of Brenda’s chair

Progress photo of figuring out how to fit all the components into the control box

Sawing the screws to the right length in order to slide into the crossbar

View of screw joints used to hold together control box

Inside view of control box while the motor was being screwed into the backing bar that attached to the back of the control box– copious amounts of motor oil for sliding the screws in not pictured

Throughout the process, we made and learned from our mistakes, discovered new techniques, and encountered many instances of components not working. Some mistakes we made included accidentally soldering all the wires with their extensions without passing them through the slots cut into the bottom of the acrylic control box, which caused a little bit of despair. Other mistakes included not making the tolerance of the 3D printed parts correct. The base that would slide onto the bottom of the umbrella stem and hold the control box wasn’t large enough and got stuck before sliding up all the way and we ended up having to saw off the plastic from the base of the umbrella and reprint the part. Additionally, the parts comprising the pulley at the apex of the umbrella were printed too large and did not secure onto the diameter of the pole as snugly as we would have hoped, so that was another part we had to remeasure and reprint. In addition to our components being ill-fitting, we also had issues with wire connections and soldering– at points the soldering in the wire extensions was not electrically connected and we had to spot check each wire to isolate which connection was not secure and thus causing the motor to continue rotating past the fully extended distance and nearly breaking our pulley system.

Some discoveries made included managing the H-Bridge motor driver. At first, using the one from IDeATe Lending was a little complicated as we had to figure out how to wire the motor to the chip, and at one point our entire group plus Catherine and Zach experimented with being human resistors. Once we finally sorted out the wiring, Zach simplified our code more by having us just drive one signal high and the other low and vice versa to switch the motor direction, and both low to stop the motor rather than using library functions which would be only applicable to the specific type of chip we had. Then, we had to figure out if a cheaper alternative to the H-Bridge motor driver from IDeATe Lending that we were using could be feasibly constructed from a series of transistors. Although we experimented with using MOSFETS as current switchers, in the end the homemade H-Bridge had to be scrapped since resources online which outlined such DIY H-Bridges utilized BJTs rather than MOSFETS, which is all the Physical Computing lab had. Although the components are similar, their electronic behavior was just different enough to be too complicated to transfer the wiring from one transistor type to another. We ended up ordering a cheaper high current H-Bridge, which then still took some trial and error to re-figure out the wiring for.

In terms of following schedules, we planned out a Gantt chart which may have been a little too ambitious:

A snippet of our Gantt Chart

Although we tried our best to stay on schedule, we encountered setbacks from having to wait for 3D printers to be available, different replacement components to come in, and for delays with 3D prints not being started as scheduled or TechSpark being closed unexpectedly. In this way, our work ramped up as the deadline approached and included a few long work sessions the nights before, as well as one particularly late night the night before presentations. Overall though, other than delays caused by materials not being usable in time, we kept on track for our designing benchmarks and were able to put everything together in time once we had our hands on the right materials.

4. Conclusions and Lessons Learned

Responding to Some Feedback

“The buttons are a little bit confusing some way of differentiating between them would be helpful” We were planning to position the box in a way that would have one button on the top and one on the bottom, so then the direction of control would align with the position of the button. However, we agree that it would be even better to distinguish the buttons with differently shaped buttons. That way the user can instantly know which button is for which direction, instead of fumbling around to see where the button is located. 

“The box attached to the umbrella is a little too big, but again it’s a prototype; the size of the black rotating rod limited the compactness…” Yes, the size of the box is indeed on the bigger side. We actually had to adjust where it’s located due to the size. It was originally going to be located toward the top of the chair near the headrest. This suggestion of using a smaller rotating rod would definitely help reduce the size of the box.

“The hardest part of robotic umbrellas (surprisingly I have experience here) is with making them close again. This team was able to figure out a way to deal with that, and it impresses me.” Thank you! Figuring out how we make the umbrella closes was definitely a big part of our initial discussions. We were originally going for a rack and pinion mechanism, however we realized, with the help of our professor, that we can use the help of gravity. So, we went ahead and found an umbrella that closes with gravity which simplified our design. 

“Auto stopping–>needs to count rotations or measure stall voltage on motor” This was definitely something we were planning to do but did not get the chance to. The next step, for safety reasons, would be implementing some sort of stop/limit switch, so the motor will only be activated for enough time to just open up and close the umbrella. The stall voltage suggestion is an interesting idea to try implementing. 

“The team has a problem I’ve had for years- overdesigning. By being as strict in designs to Brenda’s chair specifically, it can only ever work for HER chair. By having a looser design, more people could potentially use it.” Like mentioned above in our prototype feedback, this is something we are aware of. The current design might be hard even for Brenda to change the umbrella to a different one. One suggestion we got from the final critique was to reconsider how we attach the system to the chair by using a tripod-like mechanism: have one side always fit for our umbrella holder and the other adjustable for different kinds of chairs.

Experience of Working Remotely

Fortunately, the working experience is mostly hybrid for this project. We were able to meet in person and only went remote when needed. The most challenging aspect was communicating effectively when not in person. There were times when we needed Brenda’s input, and it took many text messages to sort it out. It was also frustrating at the beginning of the project when we were unable to get hold of Brenda. Despite all these, we were able to find compromises and move forward with the project. In retrospect, it is really important to plan for the in person opportunities we do have. If we have thought more about questions to ask her and measurements to take, we might have been able to minimize the need to communicate virtually.     

Working with a Person with a Disability

One takeaway is that when designing for people with disabilities, designers need to keep in mind the clearance issue. Power chairs are already bulky enough, it would be ideal to avoid making them bigger, especially horizontally. We had to carefully think about the placement of the control because of this. Nevertheless, I have to say, although designing for disability has its own special things, it is also really not that different from just designing for people. What surprised me is how this project can appeal to a broader audience. There was one comment from our critique saying “I needed this walking to class when I was in school” and I personally would love to have this umbrella retraction system for the porch umbrella my family has. Universal design is really the golden standard all designers should follow. 

Concluding Thoughts

To conclude, one last lesson we would like to mention is how iteration is an essential part of the design. People shouldn’t rely on things working out the first time they try, and we should plan for failures and redesigns. Our reprint of parts, reconnecting the wires, redesign of the box and more taught us too well of this lesson.

5. Technical Details

Block and Schematic Diagrams

Block Diagram

Schematic

Code

/*
   Automated Umbrella

   This code drives a motor CW or CCW by sensing up and down button presses. The up
   and down button presses are only registered when an overall on switch has been
   engaged. While the overall on switch is engaged and the motor is not running,
   a buzzer will sound an arpeggio as an alert tone to warn the user that the up
   and down buttons are active and can be engaged. The motor is driven CW or CCW by
   driving its IN_A and IN_B pins either high or low-- IN_A being high and IN_B
   being low or vice versa indicate the motor being driven in one direction, or
   both pins driven as low indicates the motor is stopped. The pins will never be
   both driven as high (illegal).
*/

/*
   ------------------------------------------------------------------------------
   Pin Mapping
   ------------------------------------------------------------------------------

   Name             Pin             In/Out
   IN_A              3               OUT
   IN_B              4               OUT
   PWM               5               OUT
   BUTTON_UP         2               IN
   BUTTON_DOWN       7               IN
   BUTTON_ON         8               IN
   BUZZER_PIN        9               OUT
*/

/*
   Credits:
   
   https://arduinogetstarted.com/faq/how-to-use-buzzer-without-blocking-other-code
*/

#include <ezBuzzer.h>


// motor pins
#define IN_A 3    // pwm pin motor (digital output)
#define IN_B 4    // control pin INA (digital output)
#define PWM 5    // control pin INB (digital output)

#define BUTTON_UP 2
#define BUTTON_DOWN 7
#define BUTTON_ON 8

#define BUZZER_PIN 9

ezBuzzer buzzer(BUZZER_PIN); // create ezBuzzer object

// notes in the buzzer melody
int melody[] = {
  NOTE_C4, NOTE_E4, NOTE_G4, NOTE_C5
};

// note durations: 4 = quarter note, 2 = half note
int noteDurations[] = {
  4, 4, 4, 2
};

//Variables representing state
bool up_state = 0;
bool down_state = 0;
bool on_state = 0;
unsigned long timer = 0; // used for speaker delay


// Helper functions for driving motor
void motor_stop() {
  digitalWrite(IN_A, LOW);
  digitalWrite(IN_B, LOW);
  analogWrite(PWM, 0);
}

void motor_cw() {
  digitalWrite(IN_A, HIGH);
  digitalWrite(IN_B, LOW);
  analogWrite(PWM, 255);
}

void motor_ccw() {
  digitalWrite(IN_A, LOW);
  digitalWrite(IN_B, HIGH);
  analogWrite(PWM, 255);
}

void setup() {
  pinMode(BUTTON_UP, OUTPUT);
  pinMode(BUTTON_DOWN, OUTPUT);
  pinMode(BUTTON_ON, OUTPUT);
  pinMode(BUZZER_PIN, OUTPUT);
  pinMode(IN_A, OUTPUT);
  pinMode(IN_B, OUTPUT);
  pinMode(PWM, OUTPUT);
  //Initial state of motor
  motor_stop();
}

void loop() {
  up_state = digitalRead(BUTTON_UP);
  down_state = digitalRead(BUTTON_DOWN);
  on_state = digitalRead(BUTTON_ON);
  // If overall on switch is activated (button will latch)
  if (on_state) {
    // If up button is registered, stop motor and then turn CW
    if (up_state) {
      buzzer.stop();
      motor_cw();
      delay(500); // delay for motor
    }
    // If down button is registered, stop motor and then turn CCW
    else if (down_state) {
      buzzer.stop();
      Serial.println("down");
      motor_ccw();
      delay(500); // delay for motor
    }
    // If neither button is registered, stop motor and loop buzzer alert
    else if (!up_state && !down_state) {
      buzzer.loop(); // called to play in the background
      motor_stop();
      delay(500); // delay for motor
      // if buzzer isn't currently playing anymore and 0.5 second has passed, repeat
      if (buzzer.getState() == BUZZER_IDLE && (millis() - timer) > 500) {
        int length = sizeof(noteDurations) / sizeof(int);
        buzzer.playMelody(melody, noteDurations, length); // playing
        timer = millis();
      }
    }
  }
}

What We Built

A video of our device when plugged in.

Our device is a kinetic art sculpture. It functions as a decorative piece meant to add beauty to its surroundings. When plugged in, it spins two mirrored designs in opposite directions to create visual effect.

An overall view of the main aspect of our project.

The motor that drives the top wheel as well as some other electronics on the inside of our device.

The 5v barrel jack located at the back of the device.

A picture of how the parts overlap. First (starting from the right), there is a motor. The motor drives the wheel in the back. A piece of wood separates that piece from the other wheel (which is driven by a gear). Then the K is in the front.

A picture of the gear that drives the front wheel. This gear is driven by a motor.

“When Kyle is about to start recording a video, he places the device somewhere behind him. He plugs in the device and it begins to move, adding life to its surroundings. The device stands in his audience’s peripheral, so Kyle remains the focus of the video while the device enhances the backdrop. Once Kyle is done shooting his video, he unplugs the device and it stops running.”

Prototype

First prototype of our kinetic art sculpture for our design client.

On/off controlled with the infrared light remote control.

We struggled to attach the motor and our laser cut designs together. Our solution was to use a shaft hub to hold them together.

A video of our “finished” prototype.

Prototype Development

Our first sketch of how we imagined our kinetic art sculpture to look like.

Played with these parts we found in the classroom.

An animation of the design that our prototype would make.

Our design client is a content creator and for our project we wanted to create a kinetic art sculpture that our client can put in the background of his videos for entertainment. Our goal was to make something expressive and unique to our client. For our first prototype we came up with a design that uses many gears that spell out his name and is driven by a motor. We also wanted to add cool effects on top of that to make it look more creative and fun, which was what our client wanted. Therefore, for our prototype we decided to try it out with just the first letter of our client’s name, the alphabet K. First we found some existing gear models on the internet and cut multiple pieces out in different sizes. Then we assembled them together and attached it to the K we laser cut. One mistake we made was we put the gears too close together causing too much friction making it difficult to rotate. We also laser cut more sophisticated designs to put on top of the gears but we realized we would not be able to get the effect that we originally wanted because they did not overlap and rotated in the same direction. But since we were going to upscale the project we considered that that would be our next step to figure out after getting our client’s feedback. 

Our group was pretty satisfied with where we were at with our project for the prototype critique. We got some great feedback from our classmates and guests. However, our design client, Kyle, did not seem to enjoy it as much as others. Our client wanted a more fun and exciting design and our prototype seemed too mechanical and was not expressive of his character which we totally understood and agreed with. After talking with our client, we decided to make some changes and come up with a more creative design that Kyle wanted. Even though we knew that this change required us to kind of start over, we were determined to create something that our client was satisfied with. That is how we came up with our final design.

Process

Tried to laser cut our first design however the model was too small and thin that it burned.

An animation of what our final project would look like.

Our new design test cut. We used the MDF material this time and we broke one of the parts we cut because it was too thin.

After cutting out the parts with the laser cutter, we made sure to glue it and use a nail gun for stability.

We tried connecting it to the motor for the first time without safely attaching it and because of the fast motor speed, the piece fell and broke, again. We quickly cut another piece but this time with a thicker material, 6mm plywood.

Soldering wires connected to the motors for organization inside the kinetic art sculpture stand.

Our group definitely had many ups and downs in the process of making our kinetic art sculpture for our client. Some things we struggled with was laser cutting our design models. One time we tried cutting out a few pieces of our design for our first prototype using a different type of laser cutter on campus and this laser cutter did not do a great job and pretty much burned most of our material. Also for our final design, we had multiple accidents of our parts breaking due to a very fragile material we used. This happened when we were assembling them together and trying to connect it with our motor for the first time. We had to recut the piece and paint it again but we made sure to use a stronger and thicker material. We also paid attention to stability. Since this is a standing sculpture, we were worried that it might not be strong enough to hold together and balance itself without falling. We used different types of glue, shaft hub, and nail gun to make sure they are supported and well held together Schedule was very tight since we were not really able to follow our planned schedule over thanksgiving break. Our group members were not able to meet up during break however we managed to get together everyday after break and work together to get things done.

Conclusion & Lessons Learned

Overall, we learned so much from this project. We were able to accomplish a lot, but we know that there was a lot more we could have done and that there is room for improvement.

One thing that was problematic about our device was the noise it made. After listening to the feedback provided by our guests, we realized that there were plenty of measures we could have taken in order to reduce its volume. Almost half of our feedback sounded exactly like, “it was really loud.” We honestly didn’t know that it would be a problem until after we had finished constructing everything. Once we did hear how loud it was, we didn’t know how to solve the issue. However, our critics provided a plethora of ideas that we could have implemented in order to reduce the magnitude of the issue. One person suggested that we, “experiment with other drive options,” and another that we, “[try a] belt system for rotation coordination. [Or a] spring… system… to eliminate noise.” There were so many other great ideas that were bounced around, but we hadn’t thought of any of them while we were constructing the device.

Another huge takeaway we got was the importance of prototyping. When we constructed our first prototype, we got the sense that our client wasn’t very excited about it. We thought for a while about how we could improve it, but in the end we decided to scrap everything and start again from scratch. This felt somewhat like we had just wasted time, but it prepared us for what we were going to attempt next. One person commented, “It takes someone strong of mind to look at their designs and realize that it is ‘too busy’… and start again from scratch. This team showed that skill.” In the end, it was much better that we be comfortable with the idea of starting over rather than trying to improve upon something that wasn’t working.

Working with our clients remotely caused fewer problems than expected. We were able to communicate with our client through zoom, but it wasn’t as effective as it could have been if we had met in person. At first, Kyle wanted some sort of assistive device that would help him hold a camera without dropping it. We were excited to do this for him, but later dropped the idea since we couldn’t get a clear idea of what his motor capabilities were or get the necessary measurements needed to fabricate the device. It was also difficult to make our design process as inclusive to Kyle as possible since we had to show him everything using a camera.

Overall, this project was an incredible learning experience. We are so grateful that we had the opportunity to work directly with someone who is disabled. When we were designing the camera holder, we were challenged to think differently about how we approached the design since we had to keep Kyle’s disability in consideration. When we moved to creating kinetic art, it helped us to see the humanity in Kyle because we got to work with him on something that was completely unrelated to his disability. We took away many lessons that were specific to this, but we also learned so much that we can apply to future projects.

Technical Details

On the left is the block diagram and on the right is the circuit.

Underneath you can find all of the .dxf files used to create the actual piece.

DesignComponents

Description

The table can be positioned against the already opened oven and place the hook onto the oven rack with button control. Then the user can drag the table out, which in turn drag the rack out, allowing the user to access the dish. After manually sliding the dish onto the table, the user can raise the height-adjustable table to counter height, and push the dish onto the kitchen counter.

Images of the Final Product

Overall Image

Side view of the overall table

Overall Image during Presentation

Video Demo of the Final Project

Detail: Controls

Detail: Wire box

Detail: Inside the wire box

Detail: 3D printed Tabletop attachment point

Detail: Servo attached hook

Narrative Sketch

With the winter season approaching, Dave and his friend’s are excited for the snow and championship season. The coming weekend happens to host both a snowy Saturday and a League Championship finals. Dave decides to seize the opportunity and reaches out on discord to set up a watching party. Come The night before the party, Dave wants to make it an extra special event, and decides to bake something grand for everyone to enjoy. He heads over to his kitchen and uses his rolling table to set up a wonderful lasagna for baking. When he is ready to bake, he clears the table except for his lasagna, and lowers the oven door. The table rolls right over the oven door, snugly fitting the sides of the door.

Dave pushes the lowering button on the controls to match the height of the oven rack and uses the illustrated hook buttons to latch onto the preferred rack. With a single hand, he slides in the lasagna dish, unhooks, and pulls his table out of the way to close the door and let the meal cook. When everything is ready, he lowers the oven door, lines up the table, and hooks on. The dish slides right onto the table, and Dave can unhook. Dave takes hold of the table by the handle and easily rolls the heavy dish out of the way. With the oven closed he can pull the table close to the counter and raise it to match counter height to slide it on. When game day arrives, Dave sets up the table with snacks and his lasagna and brings it to the living room, where everyone is excited for a great snowy night in.

Prototype

• The prototype was designed to solve the problem of accessing the oven rack while in a wheelchair.
• The prototype we built was a simple mechanical arm that can “drag out” the oven rack, allowing the user to access the dish. The device would be mounted on the countertop on one side of the oven. Then the user can use the controls to attach the hook onto the oven rack, extend the actuator, thus dragging out the rack.
• Images:

Overall Prototype Structure

Prototype with “Oven”

Open Hook

Close Hook

• Demo of Prototype:

Demo of Prototype

• Prototype Development:

Sketch of Prototype

Working Software and Electrical Components

Brainstorming Prototype Design & Searching for Kiwi Pies

• Reflection:

The prototype mostly solved the problem of “getting the food out”. There were some technical details to be handled, such as how to prevent the actuator from rotating due to shift of the center of gravity when the arm is extended, but overall the prototype did what we intended. We learned a lot from our first product. Stability when overextended, rotation, and wire interference were all important subjects we saw highlighted. The prototype also taught us about the importance of anchoring and the versatility of open beams, but these teachings were not ultimately relevant in the final product.

After prototype demonstration and discussion with our client, we realized that there was another problem that we did not think of solving – getting the food from the rack up to the kitchen counter. Since our client only has one fully functional arm, it can be a challenge to lift a hot heavy dish onto the countertop. Therefore we decided to integrate the “height problem” into our final design as well. Several pieces of advice about positioning and rigidity were ignored as a result of such a big change in our form factor. When all was said and done, we were very surprised at the significance of our oversight, but excited by the new iteration of our product as it would be more of an impactful product.

Process

Demo of Software and Electrical Components

The electrical components were very delicate, especially in prototype form, where wires often needed to be temporarily taped together. Using clip wires or installing quick use sockets on the screw-in spots may have saved us time.

Fully functional electrical components

We did not have an large variety number of certain colors, or enough of some colors, more prep time would make prototypes clearer for third parties on another prototype attempt.

Putting the wires in a box

Our box was very well fit for our electronics, sometimes a little too well fit for troubleshooting. An alternative could be fitting it to synthesize with the larger table, allowing for more room without being clunky or intrusive.

Making the controls

Early Whiteboard Ideation

Whiteboard Ideation

Building the table

Pre-drilled holes were essential to maintain the integrity of the wood. Drilling close to the edge caused some blemishes, even with pilot holes.

Chiseled piece for actuator

Testing half-built table

Our actual schedule was much more compressed. Immediately our material order was delayed because we had some trouble reaching our client for his oven heights, which would determine the actuators we needed. Following this trend many other dates were compressed because of our lack of access the woodshop during the thanksgiving break. Our design, electrical, and printing stayed to schedule. Our Assembly took longer than expected, but our very generous timeframe made it work.

Conclusion

The final critique allowed us to perceive our project from outside our many hours with it. An objective and critical eye gave us several new insights and even inspirations for the concept. The range of advice was broad, from changing the openness of the latching hook, to adding remote movement to the table. The most inspiring comment was simply “The structure can have many other purposes,…” This was representative of several comments which focused on the versatility of a motorized and mobile work surface. The comments inspired us to consider the optimizations possible to expand the reach of the device like range increases or wheelchair connection points. 

Other comments helped us to improve the main focus of the device, use with an oven. One party suggested it “May need ‘ramp’ to help sliding pan.” This suggestion was a very do-able way to greatly reduce the force required to overcome the bump of the servo hook when sliding a dish in. Another piece of feedback addressed the polish of the table, it simply cited “Cable management.” This was a very fair critique and a component that can be fixed with better sleeving and more attachment points and ultimately deliver a safer product, an essential feature for a person with limited mobility. Two final pieces of critique coincided, and present a great finishing addition to the table. An observer noted that “The wood may be a fire hazard.” and “Cleaning issue. Maybe sealing it would help.” Dave also noted that he appreciated the wood surface as he liked to stain his wood furniture the same tones. Though we made sure the wood could safely withstand oven temperatures, as a final step, sealing and staining the table Dave’s preferred tone would make it extra safe and special for him.

Our project workflow was fragmented into in-person and remote work/interview sessions. The experience was unique in that we could both conveniently contact each other and still meet up  to more accurately share ideas and unite components, especially physical components. The team had flexible schedules for independent and group work which allowed us to put the work in whenever we needed it. The connection with our client was not so concrete and did create some disconnects. The remote interview with our client, Dave, allowed us to view the environment the device was meant for and gave us insights that meetings at Ideate could never have. However, by not sharing the same space we did miss one of Dave’s main hurdles and objectives with this project until he visited in person to see our prototype, namely the need for conveying dishes from rack height to counter height. In retrospect, sharing a list of fundamental functions live with Dave may have helped us catch the divide between his needs and our ideas earlier.

The experience with Dave was an opportunity to re-analyze our built environments in detail. By considering his needs in our product design we dove into his challenges and focused on ideas that are not often highlighted. An example of these new insights came from his description of dealing with pneumatic doors. The need to operate doors that required significant force to operate shows that poorly designed force thresholds on everyday devices can be very damaging hurdles for some people. We quickly noticed how this extended to our own experiences with one very stiff door at the entrance of Hunt. A better built environment, for example, by way of a door with adaptive closing force, is essential for many individuals and generally a more person focused design. A flaw in our approach was the gap of understanding we had around Dave’s abilities. Though not always the most comfortable topic, it is an essential one when building a supporting device. Next time, I think one of the central focuses of the initial interview should be building a meaningful understanding of the relevant disability.

Throughout this project we expanded our experience with many subjects. Each member exercised their skill with design, physical fabrication, product sourcing, communication, electronics, debugging, and many more subjects. The most surprising of these was the exercise in empathy, to make useful and fitting devices for the people that need them. We learned about the practical limits of armature level manufacturing and how to develop ideas that are people-centric. The second time around we would not rush into the prototyping stage so brashly in order to assure our efforts were well spent, and we would make team hats.

Technical Details

• Schematic and Block Diagram

• Code

/*
 * Project Title: Oven Assit Device
 * Team Kiwi Pies
 * Bella, Emily, Noel
 * 
 * Description:
 *  The Arduino takes in the value of four buttons
 *  Two buttons for open/close hook
 *  Two buttons for raise/lower table
 *  And functions accordingly
 *  
 *  Pin Mapping
 *  
 *  A0 OUTPUT servo pin
 *  A1 INPUT button for raise table
 *  A2 INPUT button for lower table
 *  A4 INPUT button for open servo
 *  A5 INPUT button for close servo
 *  
 *  4 OUTPUT IN_A pin for motor driver 1
 *  5 OUTPUT IN_B pin for motor driver 1
 *  3 OUTPUT PWM pin for motor driver 1
 *  
 *  9  OUTPUT IN_A pin for motor driver 2
 *  10 OUTPUT IN_B pin for motor dirver 2
 *  11 OUTPUT PWM pin for motor driver 2
 * 
 */

#include <Servo.h>
Servo servo1;

const int motorA = 4;
const int motorB = 5;
const int motorP = 3;

const int motorA_2 = 9;
const int motorB_2 = 10;
const int motorP_2 = 11;

bool motorAvalue = HIGH;
bool motorBvalue = LOW;

const int b1 = A1;
const int b2 = A2;

bool button1 = LOW;
bool button2 = LOW;

const int SERVOPIN = A0;
const int OPENPIN = A4;
const int CLOSEPIN = A5;

void setup() {
  pinMode(motorA, OUTPUT);
  pinMode(motorB, OUTPUT);
  pinMode(motorP, OUTPUT);
  
  pinMode(motorA_2, OUTPUT);
  pinMode(motorB_2, OUTPUT);
  pinMode(motorP_2, OUTPUT);
  
  pinMode(b1,INPUT);
  pinMode(b2,INPUT);

  pinMode(OPENPIN, INPUT);
  pinMode(CLOSEPIN, INPUT);
  pinMode(SERVOPIN, OUTPUT);
  
  servo1.attach(SERVOPIN);
  servo1.write(140); // servo reset to neutral position
}

void loop() {
  button1 = digitalRead(b1);
  button2 = digitalRead(b2);
  
  motorAvalue = button1;
  motorBvalue = button2;

  if (button1 == HIGH || button2 == HIGH){
    analogWrite(motorP, 120);
    analogWrite(motorP_2, 120);
  } else {
    analogWrite(motorP, 0);
    analogWrite(motorP_2, 0);
  }
  
  digitalWrite(motorA, motorAvalue);
  digitalWrite(motorB, motorBvalue);

  digitalWrite(motorA_2, motorAvalue);
  digitalWrite(motorB_2, motorBvalue);
    
  int hookOpen = digitalRead(OPENPIN);
  int hookClose = digitalRead(CLOSEPIN);

  if (hookOpen == HIGH) {
    servo1.write(60);
  }

  if (hookClose == HIGH) {
    servo1.write(140);
  }
  
}

• Design Files

Design files for the controls

3D model of tabletop attachment piece

Design file for the overall product

Kiwi Pies Squad pic

This project is done with the intent of creating an assistive device for a client who faces certain challenges, and to start it off, an interview was done to help familiarize the team and client. This meeting was conducted in October 2021, with the purpose of Team Apricots, consisting of Peter, Evangeline, and Nathan, learning more about their client, Connie, and what sort of challenges their project could address. The meeting was held online through Zoom, with each individual in their own separate spaces.

Agenda:

In terms of setting up the meeting, a text group chat was created, and from there, the group was able to come up with an appropriate time for said meeting.

Meeting Agenda (follows the suggested agenda on the course website):

• Group member introductions followed by Connie’s introduction.
  • talk about her disability and what that means for her
  • ask about what she does for a living and her day to day lifestyle
  • share personal stories about interests/hobbies
• Overview of expectations for the final product that we will be developing
  • Non-professionals, all new to building devices from a hands on approach
  • Not intended to invent something completely new and scalable as a product
  • We are trying to build a useful prototype of an assistive device
  • Ending with a reasonably well done product at the end of the 5 week timeframe
• Discussion of daily tasks that Connie has trouble with and potential solutions
  • Start with asking her if she has any specific tasks that she struggles with
    • where do these problems come from?
    • what would need to happen for this to be solved?
    • how does she generally work around this problem?
  • Ask about hobbies that she likes doing at home
    • what are some struggles she has with these hobbies?
    • what are workarounds that she has found for any problems she has?
• Whiteboard initial ideas and drawings
• Make sure we share contact info, emails, phone numbers, best way to contact each other

Summary:

The interview began with brief introductions, and then, what specific disabilities Connie has. However, in terms of the bulk of the interview, most of the content of the interview involved the team learning more about what challenges Connie and people that have similar disabilities to her face in their day-to-day life, rather than brainstorm specific ideas to address said challenges. As the team learned more about Connie, it was more clear what sort of device we could build in terms of feasibility, as well as what things to look out to help make an assistive device that was not intrusive. For instance, because Connie does not have much hand dexterity or strength, it becomes difficult when it comes to activities such as cutting meat, unlocking her door, and gripping shampoo bottles. Other tasks, such as tying shoes or putting socks were difficult, and even on-market “solutions” such as sock aids were not that comfortable or easy to use. We also learned about more about the wheelchair she uses, and certain limitations that come with her wheelchair. Connie mentioned how her wheelchair has hooks located on the back of her wheelchair, but for Connie, the accessibility of these hooks is not satisfactory, and additional side hooks would also be helpful. In addition to problems specific to Connie herself, Connie also outlined more general issues for other people with disabilities, such as how certain products/services are hard to get or access because these people live in rural areas. If their products or services require external management or maintenance, then this becomes even more difficult and frustrating for people in more rural areas.

Peter drawing out image of an idea that could help with turning door knobs.

Image of some of the notes taken during the interview.

Reflection:

Looking back at how the interview meeting, it went pleasantly well, as some of the team felt a bit nervous going into the interview, but as it progressed, a good pace and ambience was established. We did not experience any sort of long lulls in our interview, and Connie was able to articulate clearly difficulties she had and was eager to answer any questions we had. While the interview did not go exactly as planned, the insights the team was able to obtain was conducive in ideation. If one aspect was lacking, it would have helped for Connie to have shown us her wheelchair and the extent of her physical strength and dexterity, but unfortunately, time ran out before we could get that far. What was perhaps unexpected, was how everyday tasks that we would do without second thought were not as simple for people with certain disabilities, and coming out the interview, this made a strong impression on us. Another point that stood out to the group was how some services and products’ accessibility was not equal across all populations, as rural areas have more difficulty.

We are Team Dates which includes, Ronald, Sohye, and David, and for our final project for intro to physical computing we are working with Kyle, a disabled person on making a device that could assist him in some facet of his life. We interviewed Kyle in order to figure out what he might need to make his life a little easier or better. The interview was held on November 2nd at 7:30 PM since Kyle couldn’t make it earlier in the day and all members of the Dates were present in the meeting. Kyle was a funny and charismatic guy which made the interview and easy to do but, coming up with new ideas for things he might want to get solved was a difficult experience.

Meeting Agenda

For our agenda, we decided to loosely follow the plan outlined on the website, with a focus on asking follow up “why” questions as the interview progressed. We felt that having our interview feel more conversant would better help us understand our client’s needs.

1. Introductions/Icebreaker
   1. Introduce ourselves, give fun fact (10 min)
   2. Describe our reason for doing this (5 min)
      1. We’re here to make your life easier. We’re not professionals and we’re not getting paid to do this, but our hearts are in the work and we genuinely care about helping.
   3. Begin Conversation (40 min)
      1. What do you do? What are some things you enjoy doing?
      2. Picture yourself doing those things. Is there anything you find uncomfortable or irksome?
      3. If you could have anything in the world, what would it be? Why?
      4. How are you doing today? Is there anything you can think back to that may have been an inconvenience? Even if it was little…
      5. What are some things that make you happy? Why?
      6. Tell us a few stories.
      7. Could you show us an example of…
   4. Conclude (10 min)
      1. Thank Kyle for his time.
      2. Possibly plan a follow up meeting.

Meeting Summary and Major Takeaways

Through our meeting with Kyle, we learned about Kyle’s hobbies and his passion for his youtube career. Kyle already had an idea in mind of what he wanted before even meeting us, and he was so passionate about this project. He told us that he wanted a camera mount that would be comfortable for him to use to film his youtube videos. We thought this would be a great idea until we ran into some problems. Kyle did not actually have his camera yet but is hoping to get one during the upcoming holiday. He was really excited about this idea and so were we until we thought about the many difficulties that would follow, such as meeting up with him in person to measure the wheelchair, not knowing what kind of camera he would be getting, the fabrication and the feasibility of this idea. We wanted to brainstorm and discuss other possible ideas however Kyle was really adamant about the camera mount project.

After the meeting was over, we talked and brainstormed together about how this camera mount might look like, what kind of functions it will have, and how it would interact with Kyle.

Early sketches of the adjustable camera mount

Even though Kyle was really adamant about this idea, we wanted to come up with other project ideas. We started thinking about having a camera stand mounted on his computer or monitor that he can easily control. We also came up with an idea of making an art piece, a kinetic art that is unique to Kyle and he can put up on his wall or in the background of his youtube videos. We came about this idea after thinking about how Kyle mentioned his interests in art, and how he wishes he could have done something more artsy in college. However these ideas were developed after our meeting with Kyle, therefore we had to schedule another meeting to discuss our new ideas with him.

In our second meeting with Kyle, we talked about our thoughts and approach on the adjustable camera mount. We also introduced him to our new idea, the kinetic art project, and he seemed to really enjoy this as well. Because of the unsure feasibility of the camera mount idea, we are leaning towards making a kinetic art piece that is unique and special to Kyle.

Thoughts after Holding the Meeting and Discussing

At first, we were torn between building a camera mount or building a piece of kinetic art. He seemed very dedicated to having the camera mount, but we saw a lot of problems that might arise if we had gone with it. We had to schedule another meeting with Kyle and share our more-flushed-out ideas to get a better understanding of where Kyle’s head was; we didn’t want to coerce him into accepting something he didn’t want, but we also didn’t want to be forced into accepting a task we couldn’t handle. We spoke with him again however and he seemed to really love the idea of a kinetic art piece.

Now that we know what our project is going to be, we have to do a lot of flushing out. We have a great deal of creative liberty on this device, so we have to step back and think about the direction we want to take it. Specifically, we have to figure out what sort of aesthetic we’re going for (but more importantly, what kind of aesthetic Kyle would want), and what sort of assistive functionality we should give it.

We’re feeling excited to take on this challenge, especially since automated, kinetic art is new territory for all of us. It’s going to take a lot of thinking, planning, and prototyping, but we’re confident in our collective abilities to tackle this problem.

The objective of this project is to design a product for a client with physical disabilities. We (Team Prunes) set up a meeting with our client, Dave, to better understand his needs and learn about his ideas for the product. The meeting took place at 12:30 pm EST on Nov.2nd. All team members (Bella, Emily and Noel) were present at the meeting, along with our client Dave.

Agenda

• Casual Conversation

Start the meeting with casual chatting to allow both parties to get to know each other better. The team members can introduce their fields of study and interests. It would be great to know more about our client – his interests, his passion, his careers, etc. This would help us know more about what his general everyday life is like, which can help us design a product that pertains to his needs.

• Explanation and clarification about the project

Briefly reiterate the scope and goals of the project and the general timeline of the whole project process.

• Understanding the Needs

To better design the product, we should know more about the condition of Dave’s physical disabilities. Specifically, we would want to know the medical condition, how does it affect his daily life, and what particular challenges he faces. Knowing these challenges can help us come up with some product that can target these problems that he faces regularly, and thus be helpful to his everyday life.

We would also want to see his living environment if that’s possible.

• Discussing the Client’s Ideas

Before coming up with our own ideas, it would be great to know if our client already has some designs in his mind, and if so, what they are. If they’re within the project scope and are achievable given the timeframe, it would be great if we can build something that Dave has in mind already.

• Ideation process

Based on the information we’ve gathered, we can start brainstorming on the potential ideas for this project, and discuss them during the rest of the meeting.

Summary/Takeaways

Meeting Dave gave us a good grasp on the kind of things he wanted help with from us. Even though more than half of the meeting was more banter than interview, we were able to learn a lot of useful information.

Initially Dave mentioned the best candidates he could think of for an accessibility device; architecture, genetics experiments, and carpentry.

He expanded on these and told us which of his physical limitations got in the way of the things he likes to do. Primarily, his worry was loss of mobility in his left arm. With only one agile arm, normal tasks like carrying potted plants, holding work pieces, and opening hydraulic doors became difficult barriers.

“My arm doesn’t work anymore, neither do my legs or my back, so yeah, I’m basically down to my right arm and that’s it.”

“My left arm doesn’t work anymore. I’ve torn the muscles out in my left shoulder from not having a 150-million percent accessible apartment – I mean, my apartment is but the building is not. And not having an attendant because everyone keeps quitting. I go through attendants like tissues because they’re essentially single use. ”

On of the first things we learned about Dave is his variety of hobbies and interests, which was a great way for us to learn more about him and brainstorm possible points of intervention for us to help. It was clear that he had been thinking of some of these common occurrences before which helped us identify what specifically got in the way of him doing the things he loves:

“I really like baking! I’m a pretty good cook, if my arms or legs work, which they don’t really anymore. So being able to get into and out of the oven without injuring myself would be great.”

“I’d like to be able to do genetics stuff with trees because it is way easier than you think, but I need to be able to get down to the ground without injuring myself or throwing myself out of my wheelchair.”

Another major aspect of Dave’s life is his computer. With four monitors total, he spends a lot of his time on the computer and enjoys multitasking with them, even mentioning to us that the only thing stopping him from having more monitors is the amount of power and desk space he has.

Dave showing us his ideal PC setup of having many many monitors to multitask with.

Looking at his PC setup, we were quite impressed but were also able to see some things that Dave keeps within reach for frequent use, like a towel.

“I have a towel so that when I have hot food from the microwave, I can put it in my lap and not burn myself, since I can’t hold it with my hand.”

Dave’s PC setup, along with the towel he uses to help him eat food without burning himself.

We closed our conversation with some specifics about his situation. We were able to see his powered wheelchair, and saw some of the limited use he had in his left hand.

“Before I used a wheelchair, I used a walking stick, but before that I even had trouble walking, so having a chance to sit when waiting in line and then instantly get back up again would be really helpful.”

Dave’s apartment, with his electric and manual wheelchairs that he uses to get around.

“Half the reason I lost my ability to drive was when I collapsed since I was waiting in line for so long at the DMV that they said I wasn’t able to drive”

Q: “What position is most comfortable for you to be in, like sitting and relaxed?”

A: “None. I have to move a lot. I have a lot of spine damage – I can’t really sit without moving for too long.

Q: “Which one is your favorite idea that we’ve discussed so far?”

A: “Probably the thing that would be most useful to me is the the thing with the oven _ I mean, I’m Italian, so the only way I know how to make people happy is by making them as fat as possible. And that’s not super easy to do if I’m not able to bake. If I’m having a really bad day, the best way I know how to fix my bad day is if I become generous to somebody else – so I do that with food.”

Q: “What is it about the oven that is preventing you from using it as of now?”

A: “I can’t open the oven door with my wheelchair because I hurt myself more leaning forward to use the oven that I have to stand there on my own, but I can’t use my walking stick and the oven since I only have one hand, so it’s like, okay, this is how things are.”

While we thought that our direction was quite set in the direction of the oven, as we talked over some of the technical considerations of the device, we learned about a different problem that had been effecting Dave. He said “I can’t use my own shopping cart because the door to this building is very hard and heavy and closes very quickly. And like, I have to use my wheelchair as like a battering ram just to open it. That’s how I destroyed my arm is trying to hold the door open, and that injury has lasted over a year now.”

Another photo of Dave’s apartment, showing his shopping cart that he hasn’t been able to use.

“I can’t add the cart to the end of my wheelchair either because it lengthens it, and my wheelchair gets stuck in that door anyway. So at the same time that an arm attached to the wheelchair sounds like a good idea, I need to make sure I’m still able to get in the door.”

Hearing how the door in his building had already severely injured him and also prevents him from living life how he’d like with his shopping cart, we felt like this may be another avenue for a way to help.

Reflection

Our conversation with Dave was mostly productive and allowed us insights about some of his hardships with plentiful context. A significant amount of the conversation was ‘off the rails’ but we were always able to refocus and talk about the project. The conversation started off with a back and forth about animation and video games which set up the rest of the conversation to be comfortable and relaxed.

In the next opportunity to speak with Dave, we feel it would be in our best interest to have specific questions ready to share. This way, Dave is able to quickly address our most important questions before we talk about broader contexts. We don’t want to miss out on any information that could help us deliver a better suited product.

From our initial conversations with the professor and TA we constructed the following questions to share with Dave in our next exchange:

Can you comfortably position your wheelchair adjacent to the oven door when lowered? In terms of physical space and reasonable temperature.

What are the reasonable dimensional limits of a removable wheelchair attachment? At what weight is the accessory not manageable?

Is fine motor control, like that required to change batteries, a barrier for you?

Do you prefer a closed, safer device, or a more open, repairable device?

• Introduction
  • Go around introducing ourselves, what we do, give some background into the class, why we’re taking the class, and into what we plan on doing
  • Ask the same of the client + insight into their motivations for volunteering for the project
• The project itself, from the notes: 
  • Trying to build prototype useful devices
  • Engaging in an iterative design process, including gathering formative feedback around the midpoint of the process
  • Taking about six weeks to go from this meeting to a reasonably high-fidelity final product
  • Documenting our process
  • We are not:
    • Professional technologists who are experienced in making polished products
    • Planning to build something that will be sold commercially
    • Constrained by any practicality outside of usefulness to the person we’re designing for
    • Likely to invent a totally novel piece of electronics (we combine many existing available components in new ways, but don’t make components)
• Timeline: 
  • This meeting as an introduction between us, figuring out what your needs are and what you would like
  • After this meeting, we’ll talk about our options, decide on a path that seems feasible, and then start drawing up sketches and prototypes
  • The next few weeks will be a process of prototyping something, figuring out what works and doesn’t, and then working on refining and polishing that design until we finish up in early December. 
• The actual meat of the interview:
  • Starter question: directly ask if there are any activities in their daily life that are challenging or difficult for them to do that might need assistance
  • Follow up questions: 
    • ask them to go through a day in the life of and about their usual routine
    • ask them to demonstrate anything or pantomime parts of that daily routine (observe for any difficulties we might be able to help with) 
    • ask about any hobbies that are challenging
  • Afterwards if capable, follow up with sketches or our ideas for designs in order to solve these solutions 
• Afterwards: 
  • reiterate contact information and timeline for the project

• Meeting summary and major takeaways:

We learned that Justin has been blind since birth, and much of our collaborative (between all four of us) ideation surrounded finding ways to adjust to that impairment. Justin came in pretty prepared, and proposed ideas such as a:

• Device that makes coffee in the mornings—some type of device that tells whether a cup is full or not (don’t want to just put finger in the liquid so it doesn’t overflow)
• Digital scale that is able to read to him (making turkey, reads out “4.5 pounds”), including a tare function
• Meat thermometer that can read him the temperature
• Braille display
• Light in room detector using pitch to reflect the level of light
• Guitar tuner helper device

Along the way, we discovered his love for music (and his YouTube channel!), especially guitar, and our conversation came around to the idea of a device to help tune a guitar, that might be able to interface between a set of external speakers. This would be a physical, easy to use alternative to digital applications or more visual-based tuners.

As the meeting progressed, we discovered that many of these devices are actually already available on the market, but exorbitant pricing posed a barrier to Justin purchasing some of them. Additionally, we learned the scales for blind people that are on the market aren’t really that accessible—despite reading out the number of pounds of an object, the buttons didn’t have braille markings on them, making different functions basically indistinguishable. As a result, we considered trying to build a low cost alternative to some of the already available designs.

After the meeting, we fleshed out more ideas for the potential devices, such as using an ultrasonic ranger for the liquid detector, pasting a braille strip that says “for Justin” on our final project for a touch of personality, or getting clips of numbers being read out for the digital scale. We also ruled out the braille display, as it is very complex and out of scope for our resources/time, although we did note other kinds of detail that braille could add when working on designs (such as having buttons marked with braille).

• Your thoughts after holding the meeting and discussing as a team:

We went totally off the rails from our agenda as Justin had already thought pretty deeply about what might make his life easier, immediately bringing up his own ideas that he had already prepared. Conversation was pretty smooth after the initial bumps of getting everything set up, and we all enjoyed talking to him and figuring out collaboratively what devices we could make that he could also use. We were even able to refer back to our initial meeting agenda after we had gone through his prepared ideas, being able to come up with even more by asking about his hobbies and if there was any way we could build something to aid in those. Although it would have been good to get a precise idea or a specific one that Justin is looking for in particular, Justin reassured us that he would be  happy with whatever we would be able to provide. We were ultimately able to come out of the meeting feeling far more secure in the kinds of things that we’re going to be building for Justin due to the conversations we had.

Some of the questions we have for Justin now is regarding his preferences with the user interface of out design, such as what size should braille letters be.

We are Team Pomegranates (Matt, Serena, and Alice) taking Intro to Physical Computing. For our final project, we are working with our client Brenda, a person with disability, to create a device that would be relevant and useful for her daily life. To start off, we scheduled an interview with Brenda to get to know her. The main purpose of the meeting was to learn about what her daily lives are like, and from there, to be able to generate ideas and directions for the project. All team members met with Brenda on Tuesday Nov. 2nd at 9:45. 

Meeting Agenda

Introduction

• acknowledge the atypical circumstance of conducting this meeting remotely
• How are you
• Names (“fun fact”) + years / majors
• Their name, “fun fact”, what drew them to want to participate

Ask for permission to record

Explanation and Clarification about Project Goals

• Time frame: 5 weeks; 18th prototype due; 

• We are:
  • Trying to build prototype useful devices
  • Engaging in an iterative design process, including gathering formative feedback around the midpoint of the process
  • Taking about five weeks to go from this meeting to a reasonably high-fidelity final product
  • Documenting our process
• We are not:
  • Professional technologists who are experienced in making polished products
  • Planning to build something that will be sold commercially
  • Constrained by any practicality outside of usefulness to the person we’re designing for
  • Likely to invent a totally novel piece of electronics (we combine many existing available components in new ways, but don’t make components)
• Any questions?

Understanding Needs

• Any activities in their daily life that are difficult, frustrating, or otherwise seem like they could use an intervention?
  • Willing to demonstrate a daily task or a series of tasks to you on the call? 
  • Anything used to enjoy doing, which has become harder over time for any reason? Are there creative ways to make that thing easier to do now?
  • narrate the action and do the drawing yourself in a way that’s visible to the group. (map, a sequence of cartoon panels, more abstract form)
  • Ask if she’s comfortable using a shared drawing-surface tool? → ask the client to draw a map or cartoon of their daily life

https://jamboard.google.com/d/1s5Rxv3rxq0p4oE7c4sLhxYmTp92bzYberSlI7clN7xU/edit?usp=sharing

• Ask ethnographic questions: “why is this important to you?”
• Once you’ve asked some of these guiding questions, use materials you might have on hand (play dough, household building materials like toothpicks, tongue depressors, tape, etc.) to mock up solutions to the story you’re telling, and show these to the camera
• Make sure they are a part of the process as much as possible
• Discuss and establish some categories for “problems” to narrow and refine the conversation
• Think of this as making a “convenience machine”, one that reduces one of the little annoyances we all have, maybe call it a “gadget”? Language is important.

• Conclude
• Thank your client for their time
• take any final documentation images/drawings/notes you may need to wrap up before you sign off.
• Reiterate the overall project schedule if you feel it would be necessary to clarify before leaving.

Meeting Summary and Major Takeaways

Brenda came into the interview with her main idea already in mind. Before we could even introduce ourselves, she explained how she wanted us to develop an automatic retracting device for her umbrella that would be attachable to her power chair. While it excited us that she had already found an idea she was passionate about, we slowed the conversation to dig a little deeper and learn more about Brenda. 

First thing first, Brenda was adamant about changing our team name from the raisins. Instead of the dried up fruit, we decided to change our team name to the pomegranates, a much more exotic fruit.

Next, we wanted to learn a little bit more about Brenda’s disability. She told us that she has trouble using her left hand and uses her right hand to drive her power wheelchair. While she is able to do simple functions with her left hand, such as pushing a button or flipping a switch, it is hard for Brenda to juggle multiple tasks while in her power chair. Some examples she gave were carrying her coffee from meeting to meeting, making a phone call on the go or simply holding an umbrella in the rain, which was the basis for her idea. Brenda even expressed difficulties taking her shoes on and off without having to wait for someone to help her with the task. Since Brenda spends “90 percent of [her] day” in the power wheelchair, it is frustrating for her not to be able to multitask during her busy schedule at work. 

This conversation really motivated us as a group. By taking us through different things she finds difficult, Brenda was able to convey just how important her idea of an umbrella holder and retractor would be to her. As a result, we were excited to know more about what exactly she was looking for and what would best suit her needs. She would like our design to: 

• Mount on the back, left side of the power chair
• Be able to open and close automatically with the flip of a switch or
• via connection to the Bluetooth module in her power chair
• Retract at least 4-5 inches above her head
• Cover her whole power chair
• Utilize an umbrella that is colorful so she is easily seen in crowds
• Be easy to dismount from her power chair when not needed. 

Based on this information, we came up with the following sketches and used our Jambord link to show Brenda what we were thinking to confirm that we were on the same page as her. 

Early sketches developed from Brenda’s description of the chair and what she was looking for.

With these specifications, we needed to learn a little more about her wheelchair and the beach umbrella she likes to use. While she attempted to show us how her wheelchair could put her in a standing position, she wasn’t able to manipulate the camera angle so we couldn’t really get a clear picture of what was going on. Brenda assured us that she would give us pictures of what it looks like raised and lowered, as well as general pictures of the chair that we can use to see what area on the chair we have to work with. Unfortunately, Brenda has not gotten back to us since our interview, and we were unable to get any pictures to include here showing the power chair, its design or how it works. We had to make educated guesses when performing ideation and sketches. Furthermore, Brenda has not gotten back to us about which umbrella she uses or how it works specifically. We are eagerly waiting for her response and plan to look into purchasing a similar umbrella to test and construct on. 

Thoughts and Discussion

The meeting did not follow our agenda, but that’s not to say it wasn’t productive. Before we even had a chance to introduce ourselves or begin our icebreaker, Brenda started off with explaining her idea, and why she wanted it. Since this removed the need to probe for aspects of her life which could benefit from an assistive device, it allowed us to further explore the idea of her automated umbrella retractor during our meeting. This was a benefit, as we were able to ask clarification questions about her chair, as well as learn more about how we could possibly integrate Bluetooth functionality into this project. Conversation flowed really naturally throughout the entire meeting as we brainstormed and asked questions. Next time, we would opt to ask her more directly if she could point out other ideas we could fall back on, or just adjacently consider if her primary idea doesn’t seem feasible as we start to draft our solution. 

After our meeting, we realized that we didn’t get a good description of the umbrella she uses in detail, which made it a little challenging to begin the brainstorming process, but we’ve opted to just purchase an umbrella for testing and prototyping purposes. In addition, we realized we each had different understandings of what Brenda wanted from our project— either it being just an umbrella opener/closer, or just an umbrella elevator/retractor, or both. However, after discussing it within the group we were able to come to the conclusion that it was likely Brenda meant for the combination of features. Overall, we all though that the meeting went well, but wished we were able to obtain details about her umbrella as well as the power chair more quickly— Brenda has yet to reach out with her follow-up information.