Our overall goal is to create an assistive device for our partner Wilma to help her life in some fashion. After narrowing down product ideas we decided to develop a way for her to know the contents of her downstairs freezer without having to walk down an extra flight of stairs. We developed a product which takes physical user input to develop a inventory list which can be accessed from a different location. This is our first iteration prototype in which we wanted to develop a behaves like prototype to give Wilma the feel of what our final product will look like. After presenting this prototype and getting critique both from classmates and from Wilma we have been able to develop steps for how to take this prototype further.

Product

Fig 1) Physical interface board, this will be by the freezer downstairs, user can add the blocks in the various spots and change the quantity with the buttons which is reflected by the lights

Fig 2) Upstairs display which shows the food type and quantity reflected from the physical user input

Our products main function is to give its user the ability to input their freezer inventory and then have access to that inventory list in a separate location. In order to make the product more user friendly, keeping our target subject in mind, we wanted to make the input process more physical and tangible. The product has two main parts, the physical input interface in the freezer area where they manage the quantity and the monitor that would be kept upstairs that gives the user the ability to see the quantity of items they have in the freezer. For the physical input interface the user can pick amongst the different wooden blocks representing the most kept food items and place them on any of the stands. Once placed on a stand this tells the upstairs monitor that the food is present in the freezer. Then they are able to use buttons to increase or decrease the quantity of that item which is reflected by lights going on and off. This quantity is tied to the food on the corresponding stand which is then shown on the screen to the user upstairs. This saves the user time and a trip downstairs to check what is in their freezer as they can see the list on the upstairs monitor.

Process

Fig 3) Initial circuitry tests, test Neopixel Led Strips to see if we could control them for our purpose. It was important to be able to control each LED individually which this gave us the ability to do.

Fig 4) Then added the LCD display and small push buttons to test the overall functionality of our product. This was a simplified version of our final circuit which included larger push buttons. We wanted to see if we could coordinate two push buttons to change both the quantity on the LCD as well as the lights on the Neopixel.

Fig 5) Sketching ideas for physical prototype and how we would attach larger push buttons, after initial sketches we were able to create CAD models of the various laser cut pieces.

Fig 6) Laser cut blocks and physical interface with button attached.

Fig 7) Attached conductive tape and resistor to the laser cut blocks, we went through many different iterations of how we would attach the conductive tape and resistor to create the best contact to the metal supports.

Fig 8) Attached NeoPixels and metal contact holders for the blocks. We wanted to get the bent metal contacts in place to test our voltage divider circuits as well as make sure the laser cut holes properly fit all of our circuitry. We had to physically drill a couple of holes to mount the Neopixels as we forgot to laser cut them in our initial model.

Fig 9) Testing analog read values of the different voltage divider circuits caused by the different resistor values of the different blocks, in order to properly hard code each block into the software we had to test its range over each of the three possible circuits it could be attached to.

Fig 10) Fully completed and wired circuit

Fig 11) Wilma holding a block after our meeting with her. She was able to give us good insight into how we can improve the product to her liking and it was great to get her opinion on the product.

Challenges

One of the first major challenges that we had was developing a product idea from our initial meeting with Wilma. She mentioned early on that she would forget what was in her downstairs freezer and would have to walk down the stairs a lot to check the contents which is not ideal. We thought we could create some way to track the inventory but did not want a tech heavy solution. We thought if Wilma had to enter the data on a screen that it would not be used as often so we wanted to develop a way to make the process more physical. From this we developed the solution to use different resistors placed on blocks which when placed on a stand would allow us to read the voltage from a voltage divider circuit thus giving us the ability to categorize the blocks. Some issues from this included how we were going to attach the resistors to the blocks and then the blocks to the board to make a good enough connection to get a consistent reading. We were able to develop a solution to use conductive tape on the blocks and then have bent metal be used as the stand to create the contact which was then connected to our circuitry.

Other challenges included choosing what type of display to use as the “upstairs monitor” as well as how to display the quantity of the items on the board downstairs. For this prototype we decided to use the 16×2 LCD as the upstair monitor. From weighing different choices and thinking about the scope of the behaves like prototype we thought that this was the best solution as it gave us the ability to show a list of three items and did not need any extra circuitry to run. For the physical interface quantity we initially tried to use the OLED displays but were not able to get the results we were looking for and realized we would have the pin outputs necessary to house multiple OLED displays. This led us to the Neopixel LED strips which gives us the ability to control each light on the strip individually. This meant it was a perfect way to track the quantity of each of the items. Overall many of our problems were in the early stages of prototyping developing our idea and picking the circuitry that we wanted to use but once we were able to get our product concept completed we were able to build and code everything else with little trouble.

Crit Review

We met with Wilma on Monday during class and she was able to give both positive and negative feedback on our prototype. One of the things she liked about our project was the tactile user interface. She mentioned that this was preferable to typing into a computer. We hope to keep this feature in the final iteration of our product. At  the same time, she mentioned that the blocks we made were a little too bulky. After some quick ideation, we decided to move forward with RFID cards, which can be easily stored and organized. Other input that was useful was her telling us that she did not have a lot of space in her kitchen. For this reason, we decided not to make a separate set of cards/blocks for the kitchen, but instead use something a little more convenient. Through our conversation with Wilma, we decided that we did not need any kind of input on the first floor kitchen, and that we only needed a way to display information in a useful way (i.e. a screen that is easily synced with the downstairs panel).

In our project, the goal was to provide an assistive device for an elderly individual. Our project developed into a puzzle, once we realized the enthusiasm which Philip, the individual we were assigned to, seemed to show for quantitative puzzles in our initial meeting. This post will document how we constructed the prototype, with images showing crucial steps we took in our design process.

The Product

The device we created. The top shows arrows used to illustrate the direction of math operations to the user. The buttons are used to create new puzzles, or view associated values.

These dials make up the main component of interaction in our design. Each one serves as input for a number from 1-9.

On the top of the device, a screen indicates the current value of operations calculated from the of the four dials on each side of the device. The screen also indicates a number referred to as the “GOAL”. The operations needed to reach the goal are unknown to the user, and they must reason through changing the dial values, and viewing the current value, in order to reach it.

Our Process

An initial sketch which was the main outline for our idea.

This image depicts Ryan experimenting with code on a simpler version of the wiring in the final prototype.

This image depicts Chileshe’s experimentation with a 16×2 lcd which would be used to indicate important aspects of the puzzle to players.

An experimental proof-of-concept dial; also shows Willow working on the design for the prototype’s body.

This image depicts a test of the wiring required for our project. It helped us to discover cumbersome aspects of our design.

The back and front of pieces which fit together to form the prototype.

Each of the four sides united together. The edges are designed to fit together like a jigsaw puzzle.

Wires soldered to the potentiometers, and a wooden piece with laser cut dials.

Ryan and Chileshe attempt to fit wiring into the prototype’s body.

The prototype coming together.

Difficulties

  The difficulties in this project were rather mild. The prototyping process was initially dominated by discussion on how the user would produce input for the device. The initial sketch shows a screen on each side to depict a selected number, as well as buttons to increase or decrease the number. We realized that this was unnecessarily complicated, largely because of the  excess wiring it would have required. We also realized that it was pointless, because a dial on each side would accomplish the same goal, while achieving visual simplicity, and much higher tactile engagement.

From that point on, everything else seemed to flow naturally. However, the coding became tricky when we realized that not only did we have to provide a numerical goal for a player to reach, but also that it would not be convenient for us to provide a goal that might not be solvable. So a function was created to come up with the solution for the puzzle’s operations before we provided it as a goal for the player.

Prototype Feedback: How we’ll move forward.

           The crit was useful for discovering much finer details involved in using our device. For one, a loophole was discovered which might allow a clever user to dial through until they find a solution. In addition, we received feedback that the puzzle might initially be too difficult, so we are considering difficulty levels for our final design. Right now, the work that follows will mostly be on the internal logic of the device. During the crit, there was also constructive criticism from the design side. The puzzle box is supposed to be an assistive device for the use of an elderly individual, and he suggested increasing the contrast of the numbers on each face, to make them more legible. We will definitely be taking action on each aspect of the crit.

The Schematic

Part One Here

Introduction:

Our group was assigned to create a useful device to enhance the life of our assigned person, Joseph.  This document explains how we created our prototype to gather feedback from Joseph in preparation for our final project.

Product:

Prototype Layout With Two Separate RFID Bookmarks

Sound Chip used to emulate desired behavior of final design

Pinout from the RFID Shield

Product Discussion:

Our device is designed to help you keep track of where you last left off in a book.  Each book you are reading will have a special bookmark we created inside of it.  When you open the book to read, you take the bookmark out and move it over our device and a short recording will play from the speakers on our device.  This recording will be a previously recorded summary of what last happened in the book.  After you are done reading, you click the record button, and record a new summary over your previous one and place the bookmark back in the book.  In short, our device will play back a recording of what last happened in the book you are reading, so as to refresh your memory and help you keep track of what’s happening in multiple books.

Process:

We first began testing to make sure our RFID tag reader worked.

Soldering original RFID tag reader (RC522 chip)

Soldered RFID tag reader

Wired RFID tag reader to test if it works

Re-wring RC522 chip with a level shifter since the RFID reader only takes 3.3 v instead of 5 v which is supplied by the Arduino pins

Testing different RFID tags to see which work

Due to the difficulty in using our previous RFID tag reader, we switched to using the Adafruit PN532 Shield.  This RFID tag reader is higher quality and has better documentation, making it easier to use.

Adafruit PN532 Shield RFID tag reader fully soldered

Testing to see which tags work with the new RFID tag reader

After finally getting the RFID reader to work, we tried to fix our code and get the Arduino to record and play back WAV files.  However, due to the complexity of our code and multiple errors in it, we switched to using a voice record and play module to simulate the desired behavior for our prototype.

Voice Record and Play Module

Testing different speakers to find loudest one to use to play back recordings

Finished Prototype at the JCC crit

Major Challenges:

The biggest challenge was scaling our project back into a working prototype in the short amount of time we had.  We needed to switch multiple aspects of our code and hardware to get a behaves-like prototype in time.  First, we switched our code from dealing with an arbitrary amount of RFID tags into a tangible number of two.  This was significantly easier to code as we just used the first character of the RFID tags’ special identification number.  Also, our code for recording and playing back audio was complicated and would have taken long to debug, so we switched to using a voice record and play module.  This allowed us to finish on time and simplified the code.  Other minor challenges were finding loud enough speakers and using the RC522 RFID tag reader.  The original RFID tag reader was difficult to use as there were limited resources available online, so we switched to using the Adafruit PN532 Shield RFID tag reader which has great documentation online, making it easier to use.  Overall, we faced a lot of technical challenges, but we were able to find alternate solutions to finish on time.

Utility of Crit:

There were several useful ideas we received that we will definitely be using for our final design.  The first was making sure that the housing of the final product is portable enough to be moved around the house.  It was pointed out that people don’t always read in the same place in the house and being able to move the device around would be very convenient to any avid reader.  The second piece of crit we received from Joseph was just to make sure we make enough bookmarks for him and his wife. They are often reading three books at a time each for different book clubs, and accounting for extras if they are also reading additional books outside their clubs, we plan to make at least 10 visually distinct bookmarks.  An additional piece that will need to be improved for the final design is including louder speakers because our prototype is barely audible from even short distances.  We decided to ignore the input of potentially saving old recordings, so the user can play back old recordings instead of writing over them.  This is because after talking with Joseph, he didn’t feel that feature was necessary. 

Team: Nathan Serafin, Alyssa Casamento, Josh LeFevre

Our process

Brief Intro

We built this Fischer-random Chess device to help Steve both teach Fischer-random Chess and play Fischer-random chess during chess club and during chess tournaments. Our idea was to decrease the time and frustration for Steve to set up a Fischer-random chess game: currently the standard process is quite clunky.  We worked through logic to randomly assign the back row chess pieces to random locations based on rules within the game.

To learn more about our idea and our initial design research process to discover this need, check out our first post, here.

The Prototype

The solution allows the suer to place the randomizer along the back row of a chess board. They would then press the randomize button (in this case, the red button) which would illuminate or designate where to place one’s chess pieces. In our prototype we used a color light strip to indicate the different pieces based on color. For the final, we hope to encode the piece data into the actual light or digital output.

The underside/components side of our prototype. In this test, we chose to use RGB LED lights to show the result of our randomized functions.

Start up state to dow the devices one and read to randomize.

Once the red button in the model is pushed, the randomized set up for Fischer-random chess is created. Each push of the button creates a new legal and random configuration. Currently each light color is associated with one chess piece on the background.

Process Documentation

Progression

Ideation. During this step we synthesized the insights from Steve along with our ideas, hesitations and limitations. Out of this discussion we landed on the Fischer-random chess device.

Diagraming possible electrical circuits to see if a location and chess pice movement indicator would be possible. We eventually abandoned this idea because of the complicated electronics needed to track all the chess pieces on a 8×8 chess board.

Diagraming and discussion logic for randomized piece placement.

Roughing out a balsa wood prototype for a rapid design process, in order to give our idea form without spending too much time getting lost on a refined output before our critique.

Uploading and testing our wiring on the initial code

Setup for initial testing of LEDs

First system test

Initial testing of patterns

Challenges

The biggest challenges that we are currently facing are:

• Making the unit small enough for easy portability
• Figuring out the proper form within which this device should live
• Linking up enough neopixel lights or OLED screens, at a reasonable price, to both the Arduino and the chess board.
• Finish the code to run randomly without writing out every permutation, since the Arduino does not have a native shuffler.

We are working through creating a truly random code which is near completion, and finishing product physicality. The limitations in Arduino screens, cost, and location have been frustrating, but we have specified our solution through the added constraints.

April 11th critique: Reflection

Nathan during our presentation at the JCC on April 11

Our critique at the JCC was overall helpful. Sharing our ideas with the class and all participants helped us solidify our idea by verbalizing it out loud. However, we felt that the critique would have been more helpful if the event was structured more like a science fair style or with rotating small groups. In the smaller groups we believe we would have received more specific and meaningful feedback.

Steve loved our project and suggested that we add official chess logos for each piece that would light up to more clearly indicate where to place the chess pieces. Also, he confirmed that our randomizer would be helpful. He also noted that it would be fine if our end design was more compact and portable. In addition, he confirmed that battery power would be the most useful power source.

From the audience we heard:

• Concerns that the item would not be adopted because individuals may be leery of our randomization
• That we should make the lights logos, similar to Steve’s feedback
• Making the unit smaller and more compact would be helpful
• That we should make a decision whether or not the project is battery powered or DC powered

Overall, from the feedback we received we are  determined to make our device smaller, battery powered, and utilize the chess logos. We will also finish building out the randomizer code to make use of the 960 back row combination possibilities.

For the final interaction, we also plan to house the unit in a more polished wood or plywood construction to add rigidity and polish to the end result.

The product design process is iterative and fluid.  Ideas must be created, tested, and, most importantly, the opinions of the person the device is being made for should be taken into account.  On this note, we created a prototype that would show how our device would work, and met with Enrique. We wanted to see what his opinion of our direction was and how the device would work with him using it.  You can read about our initial meeting with Enrique here: https://courses.ideate.cmu.edu/60-223/s2018/work/initial-meeting-documentation/

Behaves like prototype: Arduino with breadboard and pipe cleaners to attach to belt loops, pulse sensor, and LCD

Close up of the accelerometer

Pipe cleaners were attached to the bread board with water balloons

Setup showing the accelerometer and Arduino taped to the breadboard

Paragraph 2: What It Does

After talking with Enrique, we found that for him, and many older individuals, being motivated to exercise is very difficult.  There are many reasons for this including, but not limited to, exercising not being particularly fun for them and not knowing what to do other than some basic motions like walking.  We decided to tackle this issue. Our device will be a fitness planner and tracker. The prototype we presented during the mid-way meeting focused on the tracking aspect of the final device.  It attached to the belt or pants pocket of the user and would track how many steps they took. It would display the number on a screen and would show a progress bar filling up as they got closer to the goal.  The prototype also tracked the users heart rate using a common medical device called a pulse oximeter. This shines a light at a person’s skin to read their heart rate. The prototype displayed the user’s heart rate by blinking an LED along with the heart beat.  The prototype was made to test how well the step tracker worked, how consistent the pulse reader was, and how comfortable it would be to wear on one’s hip.

Though not the final design, the prototype could be used by tying some pipe cleaners around the user’s belt or pocket and plugging the Arduino into a computer to power it.  Once plugged in, the prototype will track steps and display everything automatically (the step goal was preset for the prototype, but the final device will have a step goal that the device chooses).  The pulse oximeter could be used by pressing the pulse oximeter light (a round pad with a heart on it) against the users finger. This will automatically read the user’s pulse.

Brainstorming what we should incorporate into our device in terms of physical requirements translated into functional specs, and how our gizmo could provide motivation.

Testing out the 3 axis accelerometer with gyroscope

Testing out a 3 axis accelerometer (no gyroscope)

Testing the sensitivity of the 3 axis accelerometer with gyroscope on the hip. The breadboard was taped to Matt’s belt loop.

Checklist we used to keep track of tasks

Picture of our notes when we were trying to figure out how to calibrate the accelerometer

The prototype after adding an LCD to show the steps taken and a progress bar

The prototype after adding the pulse sensor, which was very sensitive and may be taken out of the final gizmo

Circuit for the accelerometer and LCD

Major Challenges:

The largest challenge we faced was programming the accelerometer to count steps. Although much of the code was pulled from the documentation, deciding on  threshold values to determine if a step has been taken was difficult and is something we still need to improve. Our process of deciding these values consisted of one person taking steps with the sensor and another adjusting the threshold values until the measured steps were in reasonable agreement with the actual steps. In order to get accurate measurements we needed to find steady state values to compare against. This code proved particularly difficult to iron out.  The other major technical challenge we faced was communication between two arduinos. We found code online that was able to send the data we needed, but integrating it with our step counting and exercise deciding code is an ongoing challenge that we continue to work to solve. Although rudimentary, our pipe-cleaner attachment system was also a challenge to design. We wanted a slim and easy attachment method that could work on either the arm or belt for testing. The pipe cleaner design provides a simple solution, more than satisfactory for a prototype.

April 11th Crit:

During the crit on April 11th, it seemed like the audience was confused about what our final gizmo would look like because we had so many ideas for what it should look like and what it can do. This made us realize that we should streamline our goals and emphasize the motivational part of this gizmo. We were hoping to get some feedback from Enrique about whether he would be motivated by this because our goal is to encourage him to do a little exercise every day, no matter how trivial it seems. We didn’t get that feedback from him yet, but the audience didn’t have any problems with it so we’ll assume that random exercises are fun.

We also learned from the crit that although the docking station with another Arduino and display is a good idea in the future, it may be infeasible for the final build. The audience also asked if the gizmo would prompt Enrique randomly throughout the day to exercise, or if he would actively ask the gadget for an exercise to do. This made us think a little more about how to nudge him, and we ultimately decided that random prompts may be annoying and thus discourage him from turning the gadget on, especially if he’s busy and it tries to get him to exercise. If he starts by asking for an exercise and enjoys the exercise (along with a little “success” jingle), then he’ll actively use the gadget.

You can find our part one post at https://courses.ideate.cmu.edu/60-223/s2018/work/meeting-documentation_1/

PRODUCT SECTION

Recipe Light Display is a representation of Rosemarie’s cooking recipes, enhancing Rosemarie’s cooking experience. There are 2 modes that can be used in this device: Record and display. She will be able to record and save her recipes by putting inputs from the controller. Ideally, at the same time, there will be sensors to record her recipes through temperature, motion, sound, and other senses. After the inputs are completed, the recipe is saved and the light display is on. Each color symbolizes an aspect in an recipe. Rosemarie will be able to look back to the recipe through an experiencing the light display. 

PROcess SECTION

Session 02

After meet up with Rosemarie, we categorized activities she do and discussed possible assistive device designs. We came down to two directions:

1. Interactive Travel Map – This assist Rosemarie to talk about her travel stories, linking the world map to the art pieces she brought back from travels.  A World Map and a small toy airplane that she could ‘move’ around that map and attach to it magnetically, and when the airplane landed on a city she had been to and have a collected object from, a small LED next to that object would light up, so she could share it with others.
2. Light Up Cooking Art Display –  This enhance Rosemarie’s experience with cooking. We imagined a wall art display or table piece that used sounds from her cooking and colors to represent ingredients to create a changing light display while she is cooking, and a final piece when she is done that she could save and look back at later to remember the recipe she had made.

Session 03

After emailing Rosemarie about our ideas, she is interested with the cooking idea. We decided to move forward with Light Up Cooking Art Display. We made iterations of possible display ways.

Forward:

1. Figure out the use of LED tools
2. Figure out the photo sensor
3. Figure out the art display form

SESSION 04

This meet we were figuring out the code, mechanics, and physical form of our assistive device, playing with LED lights.

SESSION 05

This session, we made our first prototype through coding Arduino, laser cutting, soldering, and assembling.

SESSION 06

Here, we present our first prototype at the JCC.

Above is a screenshot of the code segment which we use to display the lights in a pattern based off of 3 colors, using input from the user to generate such colors, and meal time (e.g. breakfast, lunch, dinner) to choose a moving pattern.

JCC Critique Discussion:

During the discussion with Rosemarie after the critique on our first prototype at JCC, we confirmed that Rosemarie will enjoy using our designed devise and are ready to reiterate the device toward the final product. There are few take away notes from the discussion.

First, Rosemarie mentioned about displaying too many words would lose the purpose of the Recipe Light Display, because she would instead looking at her recipe book. She would like to see a short dish name beside the Recipe Light Display for her to remember specifically which dish she made. Second, according to the display location at Rosemarie’s home that she suggested(stainless steel kitchen table beside the fridge),  we discussed potential final forms of Recipe Light Display. Rosemarie is vegan and loves vegetables.  She liked our proposed forms: broccoli-like , a row of palm trees, and other forms of natural greens. Third, she was interested in the idea of Joe could react or interact with her cooking through Recipe Light Display. We thought about adding a favorite function button for Joe.  Fourth, we discussed  her favorite cooking ingredients and her cooking process. This information helps us to tailor the device to her more accurately with sensors like motion, sound, and temperature.

One of our biggest challenges was  figuring out how to get information about the food from the user. Originally, we planned to use a small camera to receive input about the colors of each food, but this was not possible due to available sensors and the memory limits of using an Arduino. This was one of the main reasons we switched to using an LCD display and collecting user input. Another challenge was moving from an abstract idea of some interactive art display that heightened the experience of cooking to a physical object that was reactive to the user. The process of doing this was mainly spending a lot of time brainstorming and looking at our available resources in the room.

SESSION 07

This session we planned out agenda for the next few weeks.

FORWARD 

 what we need to consider

1. form
2. dish name
3. favorite botton
4. record mode
5. saving mechanism
6. sensors
7. categories

FORM

Rosemarie is vegan and enjoys nature aesthetic, so we decided to design the form inspired by palm trees.

CONTROLLER SEQUENCE

CATEGORIES

1.  hot or cold? (red and blue-ish white)
2. What kind of cuisine? (colors of flag in one tree | no colors if no cuisine)
3. what flavor? (spicy, sweet, sour, bitter, savory – see color scheme from 1st prototype)
4. Heavy or light dish? (heavy- intense light & light – less intense light)

SESSION 08

Here, we separately work on codes on lights, encoder, choices, and color, and physical prototype.

SESSION 09

Here, Arushi and Adriel combined codes

semi-final product

Product Instruction

Recipe Light Display comes with a controller and a tree display. 

1. User decides what dish to cook 
2. User switches to record mode on the controller
3. User uses the yes or no buttons to answer displayed questions on the controller
4. The tree display lights up with specific colors, pattern, and rhythm based on one’s answers
5. User uses letter wheel on the tree display to save dish name
6. User switches to play mode on the controller
7. User’s friends and family favor the cooked dish by pressing the heart button on the tree display
8. User presses previous or forward button to revisit the kinds of dish one has made and to see friends and family’s favorite dishes

SaveSave

SaveSave