Team Beth Prototype Documentation

What we built

Our moss spreading device is a simple design. It is a remote-controlled car with a blender on the top, a tank to hold moss, and a funnel to dispense the mixture at the bottom. The purpose of the car is to cover land with a beautiful, even layer of moss with minimal effort.

Car Model

isometric view

side view

top view

front view

Controller Model

Controller Exploded View

Controller top view

TinkerCad

Each button sends a signal to the IR receiver, represented by the remote in Tinkercad.

(Subtitles may be covered by the bottom bar)

Movement demo:

Blend/dispense demo:

After some time, Beth sees that her yard is looking a little dull so she feels like beautifying it. Some of it is covered in moss and some is not. She does some research and finds that she can make moss by blending buttermilk and moss. The only problem is that her yard is extremely huge and complex with random patches of open area mixed with sporadic trees. It’s not convenient to only have one blender-full of moss at a time to cover 3 acres of land.

She grabs her remote controlled robot, places it in her yard and flips the power toggle to the on position. Beth begins to fill up the car’s tank by blending her moss and buttermilk with the blend button on the remote. After two full blenders, Beth starts to drive the robot by pressing the directional buttons on the remote and also pressing the dispense button so she could spread the moss mix however she would like.

How we got here

Vehicle design process

Here is our original idea for moving the fluid in the blender to the tank. It consisted of have a servo move a thin disk in and out of the nozzles. The servo would move the disk in while we didn’t need any fluid to be transferred. It would move the disk out of the way to let fluid through. We very slowly (but surely) realized that this solution wouldn’t work quite well due to the placement of the motor and how thin the disk would have to be.

Brainstorming using servomotor to open blender to tank

We then came up with a slightly better solution that would allow for easier placement of the servo and less spillage.

However, a problem we encountered right after was figuring out how to dispense the fluid that was transferred into the tank onto the ground without a pump. Here is picture showing a picture of our primary tank shape, which was close to a rectangular prism.

rectangular shaped tank

We were already trying to build to minimize weight which meant adding another motor for a pump would be costly. We then decided to sacrifice some efficiency with holding fluid and make the tank angled so that gravity could push out the fluid.

drawings for gravity powered tank

final tank design

One big problem we had to address was the dispensing mechanism.  We had to take into account leaking a mixture of thick-milkshake-like consistency, the weight of the liquid, and space allocation in the robot. A few ideas we had was a way to use magnets to open and close a door, gears that would use DC motors to bring a door up and down (like a garage door), and ways to use servos to pull a plane up and down. However, none of these ideas really solved the problem of massive waste while opening and closing.

Drawbridge style idea

Our solution was to mimic the blender to tank design from earlier and spread the liquid with a funnel-shaped output.

funnel design for spread

The biggest breakthrough decision we made was to focus on moss dispensing; our original idea was to also attach a cordless leaf blower. The weight of a strong enough leaf blower added on to the weight of the battery and all the liquid in the tank would make the robot need a lot of power and super strong motors. Beth shared this concern and pointed us in the right direction.

Our very first design, original plan to have leaf blowing moss robot

moss dispenser only iteration

Controller design process

The controller was initially designed to be held with both hand, inspired by Nintendo controller.

first controller iteration

However, after the feedback from Beth that she needs to spare a hand for other tasks, we changed the design to one-hand controller and made sure that the form can fit nicely in one hand.

second controller iteration

Work ethic and pace

Here is a schedule we had set for each other to get all the components of the project done.

set work schedule

We all stayed on track and it was because we spread out the tasks evenly and keep in mind what would take longer. It also helps that we made our tasks modular. Once one task was done it served as a bolster to completing the following task.

Conclusions and lessons learned

A question was brought up about the cleaning of this device: “If there is buttermilk left inside then there will be mold forming inside after a while. Will that affect future usage of the machine?” To clean the device, Beth would fill up the blender with water, blend, and let the water run through the tank. She could run water through until the dispensed water is clean.

Another comment was: “Have you thought about making the car solar power?” This is a great idea. To not add to the weight of the robot itself, we can make a solar powered charging station. But since Beth said she doesn’t get much sun, we would still have the AC adapter option.

A lot of comments were about testing:

“When the blender is full is the device top heavy and unstable?”

“How are you ensuring that your motors will be able to carry the weight of the entire device + when it’s full?”

“This is a clever design, however I worry about the vibration of the blender and how that will impact other components of your moss rover.”

The vibration of the blender is actually something that we didn’t think about. It is a valid concern that would require testing to address. We think it was unfortunate that we couldn’t test these problems but if we find the right parts, like a strong battery and DC motors, our design would be effective. If we build up a physical prototype, Beth said we can head out to her yard and test out the device and we can answer these questions then. Overall, working with Beth was a lot of fun. It was cool that we were able to build a device for a very unique problem.

We had several Zoom meetings to figure out the mechanism together (as shown in all those sketchy sketches of the robot model above). These meetings were very fruitful and effective in coming up with theoretical solutions for some technical difficulties, such as how to design the stoppers and funnels. However, because we were working remotely, we didn’t have the opportunity to test out the area our tank could cover and how effective different batteries, motors, blenders, and wheels would be. Also we were unable to test the stoppers between the blender and tank and the funnel which are important parts of our design. Also because we couldn’t meet, we divided the remote work quite clearly and were each responsible for a certain part. In retrospect, this was effective but overall, communication, about the form, electronics, and prototyping, would have been much easier in person.

We learned how to balance ambition with practicality during our prototyping process. Our first iteration, the leaf blowing moss dispenser, was a really clever idea to us, but Beth was concerned about the practicality. So for our second iteration, we made our scope more realistic. In retrospect, we should have made our process more modular from the start. If we broke down our ideas into smaller components in the beginning and made a Gantt-chart-like plan, we would have been able to see how realistic it actually was.

The biggest takeaway from our experience working with an elderly person was that checking in with Beth during our second iteration prototyping process might have helped improve our design. As we approached the end of the project, we got very invested in how the mechanism works for the robot since we were dealing with a fairly complex system. While such investigation is very valuable and we each learned a lot from the prototyping process, we put aside the need of Beth, who was supposed to be the main focus of our design. From our previous conversations with Beth on our first idea, she pointed out how some actual circumstances were different from our assumptions so we needed to take into those real-life factors into considerations, which was one of the biggest drive for us to shift to our second iteration, making our machine less ambitious and more simplistic and functional. Similarly, it would be nice if we talk to Beth to get some feedback for our second iteration, which might push our project to an even more practical, more human-centered design result.

Technical details

Robot electronics:

Breadboard image robot

Remote electronics:

https://www.tinkercad.com/things/4zUE3ML0yFY

Breadboard image remote

RC car schematic

Remote schematic

#include <IRremote.h>
#include <Servo.h>

/* Beth's Moss Dispenser
 *  
 *  Description: A remote controlled moss blender and dispenser to help Beth with her
 *  yard beautifying processes.
 *  
 *  https://www.tinkercad.com/things/1E1FraSAW9K
 *  
 * Pin mapping:
 * 
 * pin   | mode   | description
 * ------|--------|------------
 * 11     input     IR receiver   
 * 3      output    Left Front Motor Input 1  
 * 4      output    Left Front Motor Input 2
 * 5      output    Right Front Motor Input 1  
 * 6      output    Right Front Motor Input 2 
 * 7      output    Left Back Motor Input 1  
 * 8      output    Left Back Motor Input 2
 * 9      output    Right Back Motor Input 1  
 * 10     output    Right Back Motor Input 2 
 * A5     output    Blender to tank servomotor
 * A4     output    Dispensing door servomotor
 * A3     output    Blender Motor Input 1
 * A2     output    Blender Motor Input 2
 * 
 * 
 * Credit: https://www.instructables.com/id/Arduino-Modules-L298N-Dual-H-Bridge-Motor-Controll/
 * 
*/


const int RECV_PIN = 11;
const int LFIN1 = 3;
const int LFIN2 = 4;
const int RFIN1 = 5;
const int RFIN2 = 6;
const int LBIN1 = 7;
const int LBIN2 = 8;
const int RBIN1 = 9;
const int RBIN2 = 10;
const int BLEND2TK = A5;
const int DOOR = A4;
const int BLENDIN1 = 12;
const int BLENDIN2 = 13;


Servo blenderservo;
Servo doorservo;
unsigned int blendtimer = -20000;

unsigned int lastPress = 0;

bool dispensing = false;

bool on = true;

//IR Library stuff
IRrecv irrecv(RECV_PIN);
decode_results results;

void setup()
{
  pinMode(LFIN1, OUTPUT);
  pinMode(LFIN2, OUTPUT);
  pinMode(RFIN1, OUTPUT);
  pinMode(RFIN2, OUTPUT);
  pinMode(LBIN1, OUTPUT);
  pinMode(LBIN2, OUTPUT);
  pinMode(RBIN1, OUTPUT);
  pinMode(RBIN2, OUTPUT);
  pinMode(BLENDIN1, OUTPUT);
  pinMode(BLENDIN2, OUTPUT);

  blenderservo.attach(BLEND2TK);
  doorservo.attach(DOOR);
  
  Serial.begin(9600);

  irrecv.enableIRIn(); 
  
  blenderservo.write(0);
  doorservo.write(0);
}

void moveforward() {
  digitalWrite(LFIN1, HIGH);
  digitalWrite(LFIN2, LOW);
  digitalWrite(LBIN1, HIGH);
  digitalWrite(LBIN2, LOW);
  
  digitalWrite(RFIN1, HIGH);
  digitalWrite(RFIN2, LOW);
  digitalWrite(RBIN1, HIGH);
  digitalWrite(RBIN2, LOW);
}

void movebackward() {
  digitalWrite(LFIN1, LOW);
  digitalWrite(LFIN2, HIGH);
  digitalWrite(LBIN1, LOW);
  digitalWrite(LBIN2, HIGH);
  
  digitalWrite(RFIN1, LOW);
  digitalWrite(RFIN2, HIGH);
  digitalWrite(RBIN1, LOW);
  digitalWrite(RBIN2, HIGH);
}

void turnleft() {
  //left wheels backwards
  digitalWrite(LFIN1, LOW);
  digitalWrite(LFIN2, HIGH);
  digitalWrite(LBIN1, LOW);
  digitalWrite(LBIN2, HIGH);

  //right wheels forwards
  digitalWrite(RFIN1, HIGH);
  digitalWrite(RFIN2, LOW);
  digitalWrite(RBIN1, HIGH);
  digitalWrite(RBIN2, LOW);
}

void turnright() {
  //left wheels forwards
  digitalWrite(LFIN1, HIGH);
  digitalWrite(LFIN2, LOW);
  digitalWrite(LBIN1, HIGH);
  digitalWrite(LBIN2, LOW);

  //right wheels backwards
  digitalWrite(RFIN1, LOW);
  digitalWrite(RFIN2, HIGH);
  digitalWrite(RBIN1, LOW);
  digitalWrite(RBIN2, HIGH);
}

void blend() {
  digitalWrite(BLENDIN1, HIGH);
  digitalWrite(BLENDIN2, LOW);
  Serial.println("blending");
}


// volume and skip buttons move robot front, back, left, right
// 0 button dispenses moss
// 1 blends
// on/off button

void remoteaction() {
  unsigned int value = results.value;
  Serial.println(value);
  
  switch (value) {
    case 32895: {
      Serial.println("moving forward");
      moveforward();
      break;
    }
      
    case 36975: {
      Serial.println("moving backward");
      movebackward();
      break;
    }
      
    case 8415: {
      Serial.println("turning left");
      turnleft();
      break;
    }
      
    case 24735: {
      Serial.println("turning right");
      turnright();
      break;
    }
      
    case 12495: {
      Serial.println("dispensing moss");

      if (!dispensing) {
        doorservo.write(90);
        dispensing = true;
        break;
      }
      else {
        doorservo.write(0);
        dispensing = false;
        break;
      }
    }
    
    case 16580863: {
      Serial.println("on/off");

      if (on) on = false;
      else on = true;
      break;
    }
      
    case 2295: {
      Serial.println("start blending");
      blend();
      blendtimer = millis();

      break;
    }
    
      
  }
}

void loop() {
  // blend for 20 seconds (simulation different)
  if (millis() - blendtimer <= 20000) {
    blend();
  }
  // open blender to tank for 20 seconds then close (simulation different)
  if (millis() - blendtimer > 20000 && millis() - blendtimer < 40000) {
    blenderservo.write(90);
    digitalWrite(BLENDIN1, LOW);
    digitalWrite(BLENDIN2, LOW);
  }
  else {
    blenderservo.write(0);
    digitalWrite(BLENDIN1, LOW);
    digitalWrite(BLENDIN2, LOW);
  }

  // get remote button presses
  if (irrecv.decode(&results)) {
    Serial.println(results.value);
    
    remoteaction(); 
    if (!on) {
      Serial.println("off");
      digitalWrite(LFIN1, LOW);
      digitalWrite(LFIN2, LOW);
      digitalWrite(LBIN1, LOW);
      digitalWrite(LBIN2, LOW);
      digitalWrite(RFIN1, LOW);
      digitalWrite(RFIN2, LOW);
      digitalWrite(RBIN1, LOW);
      digitalWrite(RBIN2, LOW);
      digitalWrite(BLENDIN1, LOW);
      digitalWrite(BLENDIN2, LOW);
      blenderservo.write(0);
      doorservo.write(0);
      
    }
    
    irrecv.resume(); // Receive the next value
  }
  
}

/*
 * Project: Remote for Beth's Moss Dispenser
 * 
 * Description: Remote for moss dispenser
 * Imagine the Tinkercad Circuit was built using an Arduino Nano
 * 
 * https://www.tinkercad.com/things/4zUE3ML0yFY
 * 
 * Pin mapping:
 * 
 * pin   | mode       | description
 * ------|--------    |------------
 * 5      input pullup   move forward   
 * 2      input pullup   turn left 
 * 8      input pullup   turn right
 * 4      input pullup   move backward
 * 6      input pullup   blender
 * 7      input pullup   dispense door
 * 9      input pullup   on/off
 * 
 * 
 * Credit:
 * /https://www.arduino.cc/en/Tutorial/Debounce
 * https://beatyourbit.wordpress.com/2018/02/05/arduinoinfrared/
 * https://www.instructables.com/id/IR-Transmitter-and-Receiver-Using-Arduino/
 */

#include <IRremote.h>

IRsend irsend;

const int FRONT = 5;
const int LEFT = 2;
const int RIGHT = 8;
const int BACK = 4;
const int DOOR = 6;
const int BLENDER = 7;
const int ON = 9;


unsigned long lastFrontTime = 0;
unsigned long lastBackTime = 0;
unsigned long lastLeftTime = 0;
unsigned long lastRightTime = 0;
unsigned long lastBlenderTime = 0;
unsigned long lastDoorTime = 0;
unsigned long lastOnTime = 0;

unsigned long debounceDelay = 50;

int lastFrontState = HIGH; 
int lastBackState = HIGH; 
int lastLeftState = HIGH; 
int lastRightState = HIGH; 
int lastBlenderState = HIGH;
int lastDoorState = HIGH; 
int lastOnState = HIGH;

int frontState;
int backState;
int leftState;
int rightState;
int blenderState;
int doorState;
int onState;



void setup()
{
  pinMode(LEFT, INPUT_PULLUP);
  pinMode(RIGHT, INPUT_PULLUP);
  pinMode(BACK, INPUT_PULLUP);
  pinMode(FRONT, INPUT_PULLUP);
  pinMode(DOOR, INPUT_PULLUP);
  pinMode(BLENDER, INPUT_PULLUP);
  pinMode(ON, INPUT_PULLUP);
  
  Serial.begin(9600);
  
}

void loop()
{
  bool frontReading = digitalRead(FRONT);
  bool backReading = digitalRead(BACK);
  bool leftReading = digitalRead(LEFT);
  bool rightReading = digitalRead(RIGHT);
  bool doorReading = digitalRead(DOOR);
  bool blenderReading = digitalRead(BLENDER);
  bool onReading = digitalRead(ON);
  

  if (frontReading != lastFrontState) {
    lastFrontTime = millis();
  }
  if (backReading != lastBackState) {
    lastBackTime = millis();
  }
  if (leftReading != lastLeftState) {
    lastLeftTime = millis();
  }
  if (rightReading != lastRightState) {
    lastRightTime = millis();
  }
  if (blenderReading != lastBlenderState) {
    lastBlenderTime = millis();
  }
  if (doorReading != lastDoorState) {
    lastDoorTime = millis();
  }
  if (onReading != lastOnState) {
    lastOnTime = millis();
  }
  
  //checking for new press of forward button
  if ((millis() - lastFrontTime) > debounceDelay) {

    if (frontReading != frontState) {
      frontState = frontReading;
      
      if (frontState == LOW) {
        Serial.println("moving forward");
        irsend.sendNEC(0x0000807F, 32);
      }
    }
  }
  
  if ((millis() - lastBackTime) > debounceDelay) {

    if (backReading != backState) {
      backState = backReading;
      
      if (backState == LOW) {
        Serial.println("moving backward");
        irsend.sendNEC(0x0000906F, 32);
      }
    }
  }
  
  
  if ((millis() - lastLeftTime) > debounceDelay) {

    if (leftReading != leftState) {
      leftState = leftReading;
      
      if (leftState == LOW) {
        Serial.println("turning left");
        irsend.sendNEC(0x000020DF, 32);
      }
    }
  }
  
  if ((millis() - lastRightTime) > debounceDelay) {

    if (rightReading != rightState) {
      rightState = rightReading;
      
      if (rightState == LOW) {
        Serial.println("turning right");
        irsend.sendNEC(0x0000609F, 32);
      }
    }
  }
  
  
  if ((millis() - lastBlenderTime) > debounceDelay) {

    if (blenderReading != blenderState) {
      blenderState = blenderReading;
      
      if (blenderState == LOW) {
        Serial.println("blending");
        irsend.sendNEC(0x000008F7, 32);
      }
    }
  }
  
  if ((millis() - lastDoorTime) > debounceDelay) {

    if (doorReading != doorState) {
      doorState = doorReading;
      
      if (doorState == LOW) {
        Serial.println("dispense button");
        irsend.sendNEC(0x000030CF, 32);
      }
    }
  }
  
  if ((millis() - lastOnTime) > debounceDelay) {

    if (onReading != onState) {
      onState = onReading;
      
      if (onState == LOW) {
        Serial.println("turn on/off");
        irsend.sendNEC(0x00000000, 32);
      }
    }
  }
  
  lastFrontState = frontReading;
  lastBackState = backReading;
  lastLeftState = leftReading;
  lastRightState = rightReading;
  lastBlenderState = blenderReading;
  lastDoorState = doorReading;
  lastOnState = onReading;
}

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

Interview with Beth

Prototypes

Looks-like Prototype

This prototype was designed to answer the following questions:

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

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

Overall view of the car from the side

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

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

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

Original sketch to plan out what materials I would need

Gathering materials to build

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

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

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

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

Looks-like Prototype

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

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

full view of the 3D model

close up of the blender

model next to 5’5 person

how the blender and tank would be connected by hose

original thoughts on the body of the car

thoughts of the blades for the blender

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

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

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

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

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

Controller Prototype

process 1 – physical mockup

process – initial idea 1

How ir sensor and controller work in tinkercad

process – initial idea 2

final render

render – where does the ir sensor goes

render – some fun fillet!

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

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

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

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

Moving Forward

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

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

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

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

Brainstorming ideas for door mechanism on Zoom whiteboard

Overall drawing to get on the same page

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

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

Zoom meeting with Beth

Introduction:

For this project, we will build an assistive device for our Osher student, Beth.  On Friday, March 27th, Meijie, Estevan, and Suzanne (Team Beth) held a call with Beth over Zoom at 6 p.m. to get to know more about her and what we could build that would assist her in her day-to-day life.

Meeting Agenda:

Our group was divided into two, one interviewer and two note takers. They weren’t permanent roles, but would help the flow of ideas and conversation.

We planned to first start off with going around with introductions to break the ice a little bit and then to proceed with the purpose of the meeting. This included a very brief description of the project, such as our goal, time frame and limitations. Then we would open it up to Beth to talk about herself.

After that, we had these questions prepared to get more specific answers about how we might be able to build an assistive device.

• What do you like to do?
• Is there something you remember enjoying doing, which becomes harder as some inconvenience comes up in life?
• Are there any activities in daily life that are difficult, frustrating, or in general could use an intervention? Maybe narrate the action a little
• How is your day going? Narrate your daily activities?

A general rule our group had set was to speak up if something she was saying could be taken further or turned into a potential idea for a device.

We planned to try to end the meeting off with a narrowing of 3 ideas or so.

Finally, we planned to thank Beth and let her know plans for getting her critique.

Meeting summary and major takeaways:

Beth lives in a neighborhood to the north of Pittsburgh and owns 3 acres of land (wow.) She had multiple jobs and has been a very active member social work of Pittsburgh. Beth talked about how she doesn’t really have much troubles in life so we explored several activities to brainstorm ideas, including walking her dog, working with electronics, calling while driving, and taking out the trash. 

A main issue she explained was organization of papers and clutter. Beth talked about how it would be helpful to have a way to categorize things she should throw away and keep. We tried to think of a labeling device and a device to easily put things online to sell, but what we would be making would just be a label-maker.

Beth shows us a pipe under the road in front of her house that spews water onto her property

Notes from the meeting: we talked about a wide variety of activities to brainstorm ideas

She discussed other issues like her dirty glasses, getting rid of emails, and not carrying her phone around. Beth mentioned an annoyance towards taking out the trash and we talked about making a remote controlled trash can that she could drive out to her street.

One idea mentioned was building Beth a strong lift for her to be able to move the tree limbs and piles of wet leaves from her yard.

She also told us that the soil in her yard isn’t good, there are a few areas without moss, and she wants to make her entire yard covered in moss. She explained how moss can be made by mixing buttermilk and moss. This brought up another potential device, something that could spread moss over all 3 acres.

Post-Interview Discussion:

Our first comment from discussing as a team was that “Beth is dope.” She has been a caterer, a social worker, a business owner, and even more! We all agree that she was super nice and that the meeting went well.

The meeting did initially follow our agenda with a question and answer format, but later we just all racked our brains for an activity that is difficult to do because she was really having a hard time thinking about something she has trouble doing. However, if this were to happen again we would give Beth a better space for brainstorming and a little more structure in identifying inconveniences.

Nonetheless, the wide range of things we talked about allowed us to come up with a variety of ideas. We ended up narrowing down what we gathered from the meeting to three potential assistive devices. 

• Lights are turned on when the force sensor detects user going to bed. A speaker starts 1 minute (demonstration 3 seconds) after the lights turn on if box hasn’t been opened.
• A dimmer interior light turns on when the box is opened (detected by proximity sensor) in case it’s too dark to see.

Front view: different materials allow the light to alert user and display wiring, but keep the contents of the box hidden

Top view of the inside: clear acrylic shows the electronics below and allows interior light to shine through

The force sensor and power source are connected through the back.

Process:

I’d originally planned to have LED strips on the exterior of the front and along the border of the top that would light up when the lid was opened. The acrylic ended up being too thin to embed the lights properly, so I changed direction.

Original sketches to have LED strips along the border of the top and edges of the front

I was browsing though previous semesters’ projects that used clear acrylic and found that I like being able to see the wiring and electronics. But I wanted to keep the contents of the box hidden for privacy. Deciding to use clear acrylic allowed me to changed my original plan of have lights on the outside of the box and along the top of the interior.

Sketches of the parts of the box that I would laser cut in either clear or solid acrylic

For the lid, I wanted to make it a sliding lid that would fit into a groove when I realized the hinge would be hard to work with (the plastic’s tendency to hold its position made it hard to get the lid precisely against the top), but again I found the acrylic too thin to do that. I compromised the smooth exterior by placing the hinge on the outside.

Attaching the hinge to the interior would always leave a slight gap when closing the lid

Drilling holes into the pieces to attach the hinge

Soldering longer wires to the pressure sensor and switch

First iteration of laser cutting was slightly too small to fit the switch

Discussion:

Overall, I am satisfied with the way my project turned out, because the project did achieve my goal of being a proficient reminder device, but I wish I’d added some more advanced features. I’m glad I took into account details such as taking naps, having “light as a gentle nudge, the sound as a second reminder”, and the interior light.

Comments in my critique were also positive about the design, choice of material, and thought process. One written critique that I completely agree with was “I would suggest a longer wire to connect the box to the pressure sensor that would be placed under the mattress.” This would definitely be a change I would make next time. Another problem with the design was the plastic hinge. It sometimes pops the lid open slightly, so in a future iteration, I would laser cut the acrylic to imbed a magnet to keep the lid shut. The plastic hinge also has to be “trained” to hold its shut position and is more difficult to bend, so I would also use a metal pinned hinge instead.

I found designing the box was surprisingly time-consuming, and I got hung up with the blue/black lines in the fusion 360 software. But I did learn a lot about constraints and dimensions and gained useful experience for future designing. Seth helped me with laser cutting, and from him, I learned a lot about using delete overlap and combine curve to allow the laser to move in one continuous line.

Another comment was: “This project looks super aesthetically pleasing! A suggestion to maybe add a user interface option to change the pressure threshold instead of having to go into the code.” I think this is a great idea, and in another iteration, I would add a potentiometer and button to be able to set the pressure threshold so the device would be able to be used for example by an adult and a toddler. Another way I would incorporate user interaction would be to have color changing options for the lights.

In discussion, we talked about how the device could be useful for people with Alzheimers. A next step could be to develop a way to connect it to a phone where the user could customize reminders.

Schematic:

Code:

/*
   Medicine Taking Reminder

   This device reminds the user to take their medicine before going to bed, using a force sensor to detect it. Reminder cues are light and sound.

   Pin mapping:

   pin   | mode   | description
   ------|--------|------------
   12     output   Outside LED
   10     output   Inside LED
   8      input    Switch
   A1     input    Force sensor
   A2     input    IR sensor
   9      output   Speaker

   Libraries Used: Volume3


*/

#include "Volume3.h"

const int EXLEDPIN = 12;
const int INLEDPIN = 10;
const int SWITCHPIN = 8;
const int FORCEPIN = A1;
const int IRPIN = A2;
const int SPEAKERPIN = 9;

// how long to wait until sensor is on
// 10 seconds for demo, 72000000 (20 hours) in use
const unsigned long RESTARTTIME = 10000;

const int PRESSURE = 400;


bool on = true;
bool newDay = true;
bool closed = true;
unsigned long newDayTimer = 0;
unsigned long exLEDtimer = millis();


void setup() {
  pinMode(EXLEDPIN, OUTPUT);
  pinMode(INLEDPIN, OUTPUT);
  pinMode(SWITCHPIN, INPUT);
  pinMode(IRPIN, INPUT);
  pinMode(FORCEPIN, INPUT);
  pinMode(SPEAKERPIN, OUTPUT);

  Serial.begin(9600);

}

void loop() {

  // is device turned on?
  if (digitalRead(SWITCHPIN) == LOW) {
    on = false;
  }
  else {
    on = true;
  }

  // has it reached restart time for sensor to be on?
  // 10 seconds for demo, 72000000 (20 hours) in use
  if (millis() - newDayTimer >= RESTARTTIME) {
    newDay = true;
  }

  bool start = false;

  while (on && newDay) {

    unsigned long exLEDtimer;

    int force = analogRead(FORCEPIN);

    if (force > PRESSURE && !start) {
      if (!start) {

        exLEDtimer = millis();
      }
      start = true;
    }

    while (start) {
      digitalWrite(EXLEDPIN, HIGH);
      
      //haven't opened box in longer than 1 minute
      //demonstration will be 5 seconds
      Serial.print("millis - exled");
      Serial.println(millis());
      if (millis() - exLEDtimer >= 5000 && closed) {
        vol.tone(SPEAKERPIN, 220, 500);
      }

      //is box opened
      int distance = analogRead(IRPIN);

      if (distance < 50) {
        closed = false;
        newDay = false;
        start = false;
        vol.tone(SPEAKERPIN, 220, 0);
        newDayTimer = millis();
      }
    }

    while (!closed) {

      digitalWrite(INLEDPIN, HIGH);
      digitalWrite(EXLEDPIN, LOW);
      if (analogRead(IRPIN) >= 50) {
        closed = true;
        digitalWrite(INLEDPIN, LOW);
        vol.tone(SPEAKERPIN, 220, 0);

      }
    }

  }
}

The IR proximity sensor measures when something is near, allowing us to use the timing to calculate rotational speed.

Faster rotational speed makes the LED brighter. The photoresistor detects the brightness to change the output.

The servo motor powered by the external battery moves a magnet, changing magnetic field strength.

Description:

The IR proximity sensor reads the distance of a specific point of the rotating disk. If it takes less time to get closer to the sensor, the rotational speed is faster. When rotational speed is faster, the LED gets brighter. The photoresistor senses the brightness of the light. The brighter the light, the servo motor moves the magnet further away, which creates a stronger magnetic field.

Progress:

First, we used a potentiometer to test how the middle step, the LED and photoresistor, would affect the rotation of the servo motor.

We switched to a smaller IR proximity sensor that detected more specific distances, because the larger one was meant for further distances. This was an important change in our project.

We attached an external battery to the servo motor to decrease electrical noise that affected the LED. This helped us reduce the flickering of the LED and the twitching of the motor.

Discussion:

Something that was difficult to figure out was how to use the IR proximity sensor to read rotational speed. We needed it to measure difference in the time when the stick got close to it at first and then close to it again. We wrote software to have the sensor read the time only the first time it gets approached, before spinning away and back again.

Another thing that was difficult was getting the servo motor to stop being really jittery. At first, we noticed that the LED light was flickering, which affected the motor, which in turn made the light flicker. We use an external power to power the servo motor to give it a steady supply of electricity, which stopped the LED from flickering.

We then realized that the noisy data that the photoresistor was picking up was causing the problem. We figured out through testing the range of the LED with analog write that there was a consistent pattern of spiking. We solved this problem by using moving average filter code from the course website. This tweak got rid of the majority of the twitching of the servo motor.

Schematic:

/*
   Project 1: Double Transducer: Rotation Speed to Magnetic Field Strength
   
   Varsha Shankar and Suzanne Nie (varshas)+(suzannen)

   Description: The double trasnducer takes in rotational speed through the IR proximity sensor and outputs 
   that as a LED brightness. Then a photoresistor reads the LED brightness and outputs that to a servo motor 
   that moves a magnet towards the front as the LED gets brighter and opposite and LED gets dimmer.
   This changes the magnetic field.

   Pin mapping:

   pin   | mode   | description
   ------|--------|------------
   5      output     LED
   A2     input    photoresistor
   A3     input    potentiometer[testing]
   A1     input    IR sensor 
   3      output   servo

   Libraries Used:
   LiquidCrystal Arduino library for I2C LCD displays

*/

#include <Servo.h>
#include <Wire.h>
#include <LiquidCrystal_I2C.h>



//used to make the data coming in less noisy
float filtered_val = 0;  
const float PREV_WEIGHT = 0.8; 
const float CUR_WEIGHT = 1 - PREV_WEIGHT;

LiquidCrystal_I2C screen(0x27, 16, 2);


int LED_brightness;
const int LEDPIN = 5;

const int PHOTOPIN = A2;
int photopinval;


Servo servo;
const int servopin = 3;
int servopos;

//Testing purpose
//const int potpin = A3;
//int oldpotval;
//int newpotval;
//int potval;


int IRval;
int IRPin = A1;

//used to measure the time difference between each rotation
unsigned long timer;
unsigned long oldtime;
unsigned long newtime;
unsigned long timediff;

//used to take only one measurement each rotation
bool far;


void setup() {
  pinMode(PHOTOPIN, INPUT);
  pinMode(LEDPIN, OUTPUT);
  //can use this to test
  //pinMode(potpin, INPUT);
  pinMode(IRPin, INPUT);
  servo.attach(servopin);
  Serial.begin(115200);
  screen.init();
  screen.backlight();
  screen.home();

  timer = millis();
  oldtime = 0;
  newtime = 0;
  timediff = 0;

}

void loop() {
  timer = millis();

  photopinval = 925 - analogRead(PHOTOPIN);
  //checks to see if an object is close enough starting and ending a rotation
  IRval = analogRead(IRPin);
  if (IRval > 450 and far == false) {
    far = true;
    newtime = timer;
    if ((newtime - oldtime) > timediff) {
    }

    timediff = newtime - oldtime;
    oldtime = newtime;
  }
  if (IRval < 450 and far == true) {
    far = false;
  }


  LED_brightness = map(timediff, 0, 750, 0, 255);
  if (LED_brightness > 255) {
    LED_brightness = 255;
  }
  else if (LED_brightness < 0) {
    LED_brightness = 0;
  }
  analogWrite(LEDPIN, 255 - LED_brightness);
  filtered_val = filtered_val * PREV_WEIGHT + photopinval * CUR_WEIGHT;
  servopos = map(filtered_val, 29, 750, 0, 180);
  servo.write(servopos);

  screen.home();
  screen.print("i:");
  screen.setCursor(12, 1);
  screen.print("o:");
  screen.setCursor(6, 0);
  screen.print("m:");
  if (timer % 50 == 0) {

    screen.setCursor(2, 0);
    if (timediff <= 0) {
      timediff = 0;
    }
    if (timediff > 750){
      timediff = 750;
    }
    screen.print(99 - map(timediff, 0, 750, 0, 99));
    screen.setCursor(14, 1);
    screen.print(map(servopos, 0, 180, 0, 99));
    screen.setCursor(8, 0);
    screen.print(99 - map(LED_brightness, 0, 255, 0, 99));
    screen.setCursor(8, 1);
    if (filtered_val < 29) {
      filtered_val = 29;
    }
    if (filtered_val > 750) {
      filtered_val = 750;
    }
    screen.print(map(filtered_val, 29, 750, 0, 99));

  }
}

Project Creator: Muhammed Azhar

Short Description: This technology detects nearby obstacles and notifies the wearer with a vibration/buzzer sound. As a wearable technology for blind people, it may resolve issues of existing systems such as white canes (may easily break) or guide dogs (expensive).

Project being tested successfully with a visually impaired person

Response: I think this project is great, because it is an affordable option that can help many people. The concept of wearable detectors seems incredibly promising.

Like the creator mentioned, an improvement that could be made would be to combine the devices into one piece, in the form of a jacket. Wearing the detectors on the legs could also help the wearer with changes in slope or obstacles on the ground.