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