Built by: Josh Lefevre, Nathan Serafin, & Alyssa Casamento

A brief overview

In the Spring semester of 2018, our team of Carnegie Mellon students was paired with a gentleman named Steve, to develop a device that would make an element of his daily life convenient and entertaining in some way. At our first design research and interview with Steve we had acknowledged his interest in the game of chess. We began to explore effective ways in which we could improve his quality of playing as an avid player and teacher. After numerous iterations of ideas, we decided to create an automated Fischer-random chess device. This device would help Steve increase the speed of initializing chess tournament games, and help him to teach Fischer Random chess to others.

In our 1st publicized iteration, we recorded our process and critique session with Steve, and others. The feedback we received from these events solidified our overall direction of the project and encouraged us to improve our initial design. We began creating our final product, with a more legible, compact and user friendly design. This post is a discussion of our process and design decisions that led to our final product for Steve.

What we built

What it does

End view of the chess randomizer. The total thickness is about 1.25 inches

Our project is a device that facilitates the initial set-up of the back row (king, queen, bishops, knights, and rooks) of a chess game in accordance with the rules of the Fischer-random variant. The device’s interface is simple to use. One presses a power switch on the device and then pushes  the “randomize” button that chooses one of the 960 possible setup combinations of Fischer-random chess. A single standard chess icon lights up with a unique color near each backrow square to indicate where the piece should be placed on the chess board. A total of eight pieces are chosen during each randomization process.

Pressing the power button & the green lights turn on to indicate boot up has occurred.

Pressing the randomizer button initiates the algorithm to randomize the back row.

Pressing and holding the button only gives one pattern

Detail of the charging port

We used a combination of LED strips, etched/frosted acrylic and laser cut icons to diffuse and create the illumination of symbols seen.

Detail shot of the illuminated pieces. The vertically etched lines show separation between spaces on a chess board. We deliberately did not code them black or white because this setup allows use on either side of the chess board.

Intended use

When Steve is looking to play a round of Fischer random chess, he can pull out this device and align it with the chessboard, using the notch. Once he has placed the device on the table, he can use the power button to turn the device on and then press the “randomize” button to display a new legal, randomized set up for Fischer-random. Then Steve can quickly set up his back row and begin playing chess.

How we got here

Ideating during our first visit with Steve

Our  initial visit with Steve, had successfully  produced plenty of ideas we could have used. Some of the original ideas centered around making the driving experience safer by keeping Steve alert at the wheel,a tracking device that would help him find his phone when it  gets lost and numerous devices that Steve could use to  teach other about the game of chess.

Originally we had focused on ways in which we  could create a system to locate Steve’s phone more personally effective than the  “find my iPhone app” . We considered creating a case made of led’s that would blink with the  push of a wireless button.  Steve currently doesn’t use a case because of the increase in size it adds so we continued to brainstorm ideas.

After some discussion among the group, we reflected  what Steve would personally find interesting. We acknowledged that most of our conversation had revolved around Steve’s love for chess. He enjoys all aspects: playing, teaching, competing, and exploring new variations.

Affinity map of our initial  ideas

Our first chess ideas revolved around  helping Steve teach others about the game of chess. We considered building a smart chess board that would show someone how to set up pieces and  show  all legal moves one to three moves in advance given a certain setup. We felt that this would allow Steve to teach students faster but also be a fun way to show how technology could be used to lower learning barriers.

After a few days of diagramming, consulting with aids, and wrapping our heads around the logic, we realized that this approach, while good, was both outside our computational and physical hardware abilities while remaining within the scope of the course, and ultimately not personally designed to help the need of our user;Steve,. Refocusing our goals on improving the game  of chess for Steve  led us to think about ways in which we could build a device that would  allow for Steve to play one of his favorite versions of chess, Fischer-random. Considering Steve currently takes an unnecessary amount of time  to randomize his Fischer Random setup, we explored ways in which we could efficiently scrambles the starting location of a players back row.

First functioning prototype.

First light and icon prototype

We created our first  LED prototype  that would demonstrate the basic idea behind the Fischer Random functionality.

It indicated where the randomized chess piece positions should be, as well as exemplifying our initial form concepts. We took this model to our critique with Steve and received an ample amount of feedback on how we could improve our design. This demonstration and critique of several ideas with Steve provided us a guiding star to follow throughout the rest of our design and making process.

While we were satisfied with  the overall concept  of the design , we  brainstormed with  Steve about ways in which we could  most effectively display  each piece.

Steve had suggested to use the typical chess piece symbols from the online versions of chess to ensure the images were legible.

We considered many display option including, RFID tagged pieces to LED backlit icons, LCD screens, laser-cut displays and many other ideas.

SPI linked LCD screens

After much discussion and ideation, we narrowed our design to testing two different methods for displaying the the set up for the back row. The first idea explored was to implement backlit icons of the various chess pieces.Initially, we made great progress on integrating and programming the lights beyond the original concept idea we showed Steve during our critique. However, the idea of using  LCD or OLED screens to display  each random ordered  piece icon seemed optimal . We were still leaning towards using LCD screens because the display size of icons would be larger and the form factor of the end device would be                                                                                            smaller and less bulky,

“Correctly” rendered bitmaps after a week of testing.

 We switched gears and began working with some LCD displays using the SPI protocol. They were rather frustrating to use, due to non-ideal libraries, incompatibility with the Arduino Uno’s native 5V logic level, and an extreme lack of good bitmap-conversion tools.

After a week of sleepless nights, we decided to cut our losses and returned our focus to making the backlit LEDs the best we could make them.

Second round of prototyping the correct layering of wood and acrylic.

We ran several experiments on how to make the back-lit chess icons look good and be legible to those with  even compromisable eyesight. We ended up choosing a layered system of frosted or etched acrylic and birch plywood that would dilute the  LEDs to create the effect and finish we sought.

Leads soldered onto LED strip

Some complications we faced while making the device were that the lights were unevenly spaced on the LED light strand we were using, which made the placement of holes more difficult. We were also hampered by significant differences in the thickness of the plywood versus the acrylic, which nominally should have been the same.

Testing full electronics setup

Testing electronics layout

Assembling the final product

The final difficulty was not the coding of the project, which came rather easily after thinking through the logic, but the assembly of the final product using glue, and mixed materials (acrylic and wood). We had quite a few material casualties, and the hand polishing took a long time.

After our final assembly we were excited to share this product with Steve.

Final touches for the prototype.

At our presentation, he became excited and mentioned that this is exactly what he wanted. He also noted how helpful this device would be at his chess club and for tournament play. This was a the moment of excitement and personal reward for our team. We recognized that we had truly met his need and created meaningful gift for him to use, now and into the future.

We did not stick to our final build plan, as we found it very difficult do decide between using small displays, or the cutouts that we eventually settled upon.  While diverging from the plan made the project more stressful, it did allow us to more carefully consider our options.

Conclusion & lessons learned

Critique major take-aways

Final critique & presentation of our product to Steve

There were three major suggestions that would have significantly improved the project.  First, when the device is first powered up it could turn on all of the lights to their appropriate color, allowing easy verification that the device is fully functional.  Second, a clear panel could be placed over the top of the device to protect from dirt and dust. Third, the lights and symbols could be mirrored on the other side of the device, and the device could be placed vertically in the center of the board, allowing both players to set up simultaneously.

• These suggestions paired with our own thoughts would lead us to develop future considerations for building a similar device the future:
• Go with name brand LED strips to ensure a greater likelihood of equidistant spacing between each light.
• Integrating high resolution OLED screens would be effectivtive and decreasing the size and form factor of the end product.

What we learned

Building a device for someone else is much more rewarding than building one for yourself.

If we were to do this project over again we’d involve Steve more frequently throughout the process and go beyond just having a critique but actually conduct user testing in real environments where the device will be used. Though we kept in contact with Steve via email periodically our actual interaction were limited which could have added more value to our finished project

Working with an older adult is rewarding and your realize that they have 88% of the same needs you do only they are little older and may not know all of the possible functionality. Which in many ways highlights a design principle of building for the need not the exotic, even when the exotic is super cool.

Reflection

I’d recommend that everyone should have a chance to make something for a friend that  they’ve made who isn’t family or roommate and see how it changes their life and perspective on human relationships.

The most important and interesting part of this project wasn’t the coding and making of the end product but the process of how we got there and the friends we made along the way.

Building a project for a specific person puts a rather different perspective on the design.  Choices need to be made to best cater to the requirements of the intended user, rather than always choosing the most technically elegant solution.  I think the conflicts were generally resolved, but it did cause some dissonance in the design process.

Technical details

Code

/*
 * Copyright 2018, Alyssa Casamento, Josh LeFevre, Nathan Serafin.
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <http://www.gnu.org/licenses/>.
 */
#include <Adafruit_NeoPixel.h>;

constexpr int TDATA_PIN = 2;
constexpr int BDATA_PIN = 3;
constexpr int BUTTON_PIN = 4;
constexpr int SRAND_PIN = A0;

constexpr uint32_t
color(uint8_t r, uint8_t g, uint8_t b)
{
    return (((uint32_t) r) << 16) | (((uint32_t) g) << 8) | ((uint32_t) b);
}

constexpr uint32_t OFF_COLOR = color(0, 0, 0);
constexpr uint32_t READY_COLOR = color(0, 255, 0);
constexpr uint32_t ROOK_COLOR = color(255, 0, 0);
constexpr uint32_t KNIGHT_COLOR = color(0, 255, 0);
constexpr uint32_t BISHOP_COLOR = color(0, 0, 255);
constexpr uint32_t KING_COLOR = color(255, 255, 255);
constexpr uint32_t QUEEN_COLOR = color(255, 0, 255);

constexpr int NPIXELS = 24;
constexpr int ROW_SIZE = 8;

uint32_t READY_DISPLAY[] = {READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR,
                            READY_COLOR, OFF_COLOR, OFF_COLOR};

typedef enum {
    EMPTY = 0,
    KING = 1,
    QUEEN = 2,
    ROOK = 3,
    BISHOP = 4,
    KNIGHT = 5,
} piece_t;

bool prev_button = 0;
bool go = false;
bool pattern = false;

uint32_t tdisplay[NPIXELS];
uint32_t bdisplay[NPIXELS];

Adafruit_NeoPixel tstrip = Adafruit_NeoPixel(NPIXELS, TDATA_PIN, NEO_GRB + NEO_KHZ800);
Adafruit_NeoPixel bstrip = Adafruit_NeoPixel(NPIXELS, BDATA_PIN, NEO_GRB + NEO_KHZ800);

static void
display_setup(Adafruit_NeoPixel& strip, uint32_t c[])
{
    strip.setPixelColor(0, c[0]);
    strip.setPixelColor(1, c[1]);
    strip.setPixelColor(2, c[2]);
    strip.setPixelColor(3, c[3]);
    strip.setPixelColor(4, c[4]);
    strip.setPixelColor(5, c[5]);
    strip.setPixelColor(6, c[6]);
    strip.setPixelColor(7, c[7]);
    strip.setPixelColor(8, c[8]);
    strip.setPixelColor(9, c[9]);
    strip.setPixelColor(10, c[10]);
    strip.setPixelColor(11, c[11]);
    strip.setPixelColor(12, c[12]);
    strip.setPixelColor(13, c[13]);
    strip.setPixelColor(14, c[14]);
    strip.setPixelColor(15, c[15]);
    strip.setPixelColor(16, c[16]);
    strip.setPixelColor(17, c[17]);
    strip.setPixelColor(18, c[18]);
    strip.setPixelColor(19, c[19]);
    strip.setPixelColor(20, c[20]);
    strip.setPixelColor(21, c[21]);
    strip.setPixelColor(22, c[22]);
    strip.setPixelColor(23, c[23]);

    strip.show();
}

static void
display_back_row(Adafruit_NeoPixel& tstrip, Adafruit_NeoPixel& bstrip,
                 piece_t back_row[])
{
    for (int i = 0; i < ROW_SIZE; i++) {
        switch (back_row[i]) {
            case KING:
                tdisplay[i * 3]     = KING_COLOR;
                tdisplay[i * 3 + 1] = OFF_COLOR;
                tdisplay[i * 3 + 2] = OFF_COLOR;
                bdisplay[i * 3]     = OFF_COLOR;
                bdisplay[i * 3 + 1] = OFF_COLOR;
                bdisplay[i * 3 + 2] = OFF_COLOR;
                break;
            case QUEEN:
                tdisplay[i * 3]     = OFF_COLOR;
                tdisplay[i * 3 + 1] = QUEEN_COLOR;
                tdisplay[i * 3 + 2] = OFF_COLOR;
                bdisplay[i * 3]     = OFF_COLOR;
                bdisplay[i * 3 + 1] = OFF_COLOR;
                bdisplay[i * 3 + 2] = OFF_COLOR;
                break;
            case BISHOP:
                tdisplay[i * 3]     = OFF_COLOR;
                tdisplay[i * 3 + 1] = OFF_COLOR;
                tdisplay[i * 3 + 2] = BISHOP_COLOR;
                bdisplay[i * 3]     = OFF_COLOR;
                bdisplay[i * 3 + 1] = OFF_COLOR;
                bdisplay[i * 3 + 2] = OFF_COLOR;
                break;
            case KNIGHT:
                tdisplay[i * 3]     = OFF_COLOR;
                tdisplay[i * 3 + 1] = OFF_COLOR;
                tdisplay[i * 3 + 2] = OFF_COLOR;
                bdisplay[i * 3]     = KNIGHT_COLOR;
                bdisplay[i * 3 + 1] = OFF_COLOR;
                bdisplay[i * 3 + 2] = OFF_COLOR;
                break;
            case ROOK:
                tdisplay[i * 3]     = OFF_COLOR;
                tdisplay[i * 3 + 1] = OFF_COLOR;
                tdisplay[i * 3 + 2] = OFF_COLOR;
                bdisplay[i * 3]     = OFF_COLOR;
                bdisplay[i * 3 + 1] = ROOK_COLOR;
                bdisplay[i * 3 + 2] = OFF_COLOR;
                break;
    }
}

    display_setup(tstrip, tdisplay);
    display_setup(bstrip, bdisplay);
}

void
setup()
{
    pinMode(TDATA_PIN, OUTPUT);
    pinMode(BDATA_PIN, OUTPUT);
    pinMode(BUTTON_PIN, INPUT_PULLUP);

    pinMode(SRAND_PIN, INPUT);

    randomSeed(analogRead(SRAND_PIN));

    tstrip.begin();
    bstrip.begin();

    tstrip.setBrightness(64);
    bstrip.setBrightness(64);

    tstrip.show();
    bstrip.show();
}

void
loop()
{
    bool button = !digitalRead(BUTTON_PIN);
    if (button != prev_button) {
        delay(100);
        prev_button = button;
        if (button) {
            go = true;
            pattern = true;
        }
    }

    if (!go) {
       display_setup(tstrip, READY_DISPLAY);
       display_setup(bstrip, READY_DISPLAY);
    }
    else if (pattern) {
        piece_t back_row[8] = {EMPTY, EMPTY, EMPTY, EMPTY,
                               EMPTY, EMPTY, EMPTY, EMPTY};
        int K, Q, R1, R2, BI1, BI2;

        int color1_cnt = 4; // Even.
        int color2_cnt = 4; // Odd.

        /* Place king. */
        if (((K = random(1, 6)) % 2) == 0) {
            color1_cnt--;
        }
        else {
            color2_cnt--;
        }
        /* Place first rook. */
        if (((R1 = random(0, K - 1)) % 2) == 0) {
            color1_cnt--;
        }
        else {
            color2_cnt--;
        }
        /* Place second rook. */
        if (((R2 = random(K + 1, 7)) % 2) == 0) {
            color1_cnt--;
        }
        else {
            color2_cnt--;
        }

        back_row[K] = KING;
        back_row[R1] = ROOK;
        back_row[R2] = ROOK;

        /* Place first bishop. */
        BI1 = random(0, color1_cnt - 1);
        int n = 0;
        for (int i = 0; i < ROW_SIZE; i += 2) {
            if (back_row[i] == EMPTY) {
                if (BI1 == n) {
                    back_row[i] = BISHOP;
                    break;
                }
                n++;
            }
        }

        /* Place second bishop. */
        BI2 = random(0, color2_cnt - 1);
        n = 0;
        for (int i = 1; i &lt; ROW_SIZE; i += 2) {
            if (back_row[i] == EMPTY) {
                if (BI2 == n) {
                    back_row[i] = BISHOP;
                    break;
                }
                n++;
            }
        }

        /* Place queen. */
        Q = random(0, 3);
        n = 0;
        for (int i = 0; i < ROW_SIZE; i++) {
            if (back_row[i] == EMPTY) {
                if (Q == n) {
                    back_row[i] = QUEEN;
                    break;
                }
                n++;
            }
        }

        /* Place knights. */
        for (int i = 0; i < ROW_SIZE; i++) {
            if (back_row[i] == EMPTY) {
                back_row[i] = KNIGHT;
            }
        }

        display_back_row(tstrip, bstrip, back_row);
        pattern = false;
    }
}

GitHub repository

Schematic

Full resolution

 Physical Form DXF

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).

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

Introduction:

We aim to create an assistive device for an older person. This can be in the form of any type of device that helps them in their day to day life. In order to better understand our intended user we set up a meeting with Wilma, an older lady in the area who volunteered to help us, in order to get a better idea of different problems in her life that we can aim to solve. We set up the meeting for Monday, March 26th at the JCC. Our main goals for the meeting were to introduce ourselves to Wilma, explain the goal of the project, explain the meaning behind an assistive device, explore Wilma’s living situation and finally hear about different problems she has in her day to day life. From here we were able to construct an agenda for the meeting.

Agenda:

1.) Introductions: We first want to introduce ourselves to Wilma. Sharing facts about us such as year in school, major, and where we are from as well as learning about Wilma and her past will make it easier to interact for the rest of the meeting as well as in the future. Establishing a connection of trust is critical since we are creating the product for her in particular.

2.) Project Goals: 

• Creating an electro-mechanical device, explain what this means and types of components it can entail
• Create an assistive device, explain meaning of assistive device and how it can incorporate any aspect of one’s life
• Explain our technical background, this will give more information into the type of projects that we can complete
• Explain timeline of project, only have 6 weeks to build final device so it needs to be scalable
• Show examples from project 2, bring laptop to show pictures and documentation of past projects to show types of devices that we can create

3.) Ideation/Problem Identification

• Have Wilma explain her daily routine, asking about any problems she undergoes through the steps. Sample Questions: “How could this experience be improved?”, “What is the most difficult part of completing this task?”
• Have Wilma talk about different areas of her home in order to get a better idea of some of the situations she finds herself in, have her sketch certain areas/tasks if necessary. “What do you wish was different about this area”
• Supplementary Questions:
  • Is there something that you used to enjoy doing/used to do that you can no longer do?
  • What task causes the most physical strain day to day?
  • What task causes the most mental strain day to day?
  • What do you wish could be automatically done for you?
  • What technology do you use? What do you like/dislike about it?
• Ideation process: Based upon the different problems identified we want to sit down and discuss possibilities of ideas that we can move forward with. Bring a notebook in order to sketch different possibilities with Wilma giving input on different ideas with our guidance. Goal is to have three good ideas that we can explore further

4) Conclusion

• Based upon ideation we want to take any notes/pictures of what the final assistive device would help with
• Thank Wilma for her help and set up future meeting. Can also ask if we can contact her with small questions based upon further exploration of different ideas

Meeting Summary/Takeaways:

Notes Wilma took to describe her daily routine to us

Together we tried to identify issues in Wilma’s daily life and possible solutions using technology

During the meeting, we tried to derive specific problems or issues that Wilma had in her daily life, and one of the problems she raised was an issue with her doorbell. The doorbell at her apartment is identical for all doors, so the she has no method to differentiate which door to go to. However, we came to an agreement that there is no clear technological solution for this problem, because anything sound based may go unheard and anything visual defeats the purpose, because then she might as well just check the door.

Through further brainstorming, Wilma mentioned that she often had trouble tracking what she had in her freezer, and would realize that she had forgotten to buy more of what she needs when she needs them. We decided that this would be a more suitable goal to pursue, since the scale is much smaller, and we can focus on certain aspects of it step by step.

In our initial research, there seems to be several API’s that can access barcode databases. If we decide to pursue this project, we would use a scanner input to keep a simple inventory for her freezer, with options to increment and decrement counts with buttons. Because this project will have to connect to an online database, we would most likely use a Raspberry Pi.

Other issues we discussed with Wilma included the difficulties of keeping track of the pills her husband needs to take, walking down stairs with bifocal lenses, and more generally, how it is difficult to engage in her social life because she needs to take care of her husband and how taxing common chores can be due to her arthritis.

Notes we took during the meeting – describes some of our brainstorming and thought processes

Thoughts:

While we tried to identify everyday issues that technology may be able to solve, it was interesting to notice that Wilma had already adapted her lifestyle to accommodate these difficulties, and it actually would have been more difficult for her to accustom to a new lifestyle with the new technology. We hope that the device we create will not be intrusive, but instead assist her to make her life easier.

Overall View of the Weather Light

Detail of the Sensor Unit

Overall scale of the Weather Light

The Process

The original idea was to have a light strip match the color of the sky.  The most difficult part of the process was figuring out how to accurately measure the brightness and color of the sky.  At first I tried using three photoresistors with a red, green and blue filter over each one.   As a quick and easy prototype,  each photoresistor was linked to an LED with its respective color.

Colored Filters Prototype

I used colored lights on my phone to calibrate the photoresistors, but the when trying this system with actual sunlight each photoresistor gave nearly identical values.  This would make for a very boring weather light that only ever changed at sunset and sunrise.

I decided to  change my original idea. Instead of displaying the color of the sky, the light-strip would change based on the weather. I added a temperature and UV sensor, and removed two of the photoresistors.  I also replaced the system of three LEDs with an RGB light-strip.

Breadboard Prototype with new sensors and LED Light strip

With the addition of the UV and temp sensors,  the Weather light took its final from.

Detail of the Sensors

Detail of the MOSFET board

Taking the breadboard design to a presentable form was fairly straightforward.  The Lightstrip was soldered to the same board as the MOSFETs. The sensors were mounted on a piece of foam-core to secure them. I laser cut three boxes: one for the sensors, one for the MOSFETs and one for the Arduino.  I also cut three pieces of wood to make a baking for the lightstrip. Because the sensor unit needs to be outside, and the lights should be able to be placed  on a wall or ceiling, I used 3 ft long cables between the boxes.

Technical Information

Schematic

Schematic

Code

int cellR = A0; 
int uvPin = A1;
int tmpPin = A2;

int redPin = 10;
int greenPin = 9;
int bluePin = 6;

void setup() {
 pinMode(cellR, INPUT); 
 pinMode(uvPin, INPUT);
 pinMode(tmpPin, INPUT);

pinMode(redPin, OUTPUT);
 pinMode(greenPin, OUTPUT);
 pinMode(bluePin, OUTPUT); 
 
 Serial.begin(9600); // starts serial communication at 9,600 baud (the rate)
}

void setColor(int red, int green, int blue)
{
 #ifdef COMMON_ANODE

#endif
 analogWrite(redPin, red);
 analogWrite(greenPin, green);
 analogWrite(bluePin, blue); 
}

void loop() {
 int valR; 
 int valUV;
 int r, g, b;

//convert voltage to farenhieght
 int rawvoltage = analogRead(tmpPin);
 float millivolts = (rawvoltage/1024.0) * 5000;
 float tmp = millivolts/10;
 
 valR = analogRead(cellR); // do the analog read and store the value and convert to rgb data
 valUV = analogRead(uvPin);
 
//Serial Prints for Debuging
 Serial.print(rawvoltage);
 Serial.println("R " + String(valR) + " UV " + String(valUV) + " TEMP " + String(tmp));
 delay(20); // slow the loop down a bit before it repeats
 
//Values are set for indoor testing use
 if (valUV >= 512){
 setColor(valUV/4, 0, valUV/4);
 }
 
 else if (valR < 200){
 setColor(valR/4, valR/4, valR/4);
 }
 else if (valR >= 900){
 setColor(0, 0, 0);
 } 
 else if (tmp >= 60){
 for (r = 0; r < rawvoltage/4 ; r++){
 setColor(r, 0, valUV);
 }
 for (r = rawvoltage/4; r > 0; r--){
 setColor(r, 0, valUV);
 }
 }

else if (tmp <= 20){
 for (b = 20; b < rawvoltage/4 ; r++){
 setColor(0, b-20, b);
 }
 for (b = rawvoltage/4; b > 20; r--){
 setColor(0, b-20, b);
 }
 }
}

Discussion

Although the Weather Light  was satisfactory I feel that there is more I could have done. I only used three sensors, and one LED strip. If I had had more time (and the arduino had more pins), I would have added a second or third light strip to better display weather information.  I would have also liked to have more data to calibrate, as I only was able to test the project on rainy and overcast days.

Because my initial idea was to display the color of the sky I tried to use basic image processing to get that data. I used openCV in python to try and make this work, but could not install a specific dependency for an unknown reason. I would like to try and use this software on a different project and get it working.

The light strip I used was also fairly unreliable. The color was displayed correctly on the first third of the strip, but the red channel dropped out for the rest. It would also turn off and on if it was bumped. I tried to solve this by soldering it to a board but this problem continued. Even though the light strip itself was finicky, I learned  how to use the p-channel MOSFETs to power it. I also learned what RGB values created what colors.

Lolis for Loot Machine Composition

Element Composition

Infared Transmissive Sensors located across the Quarter Insertion slot.

The Reset Lock Button located in the back of the mechanism.

Typical wire wrapping procedure performed to hold components to the wire box.

Functionality

Metal Eye-Hooks screwed to the lid are used to lock the lid to a solenoid  at the base

External view of a solenoid tied into the box and attached to an eye hook ( locked position).

Quarter insertion slot of the lid

Mechanical Result of Quarter Insertion

Process

During construction of the  Loli’s for Loot Machine minor discoveries had altered the original design.

Quarter Insertion

Infared Functionality

The original infared sensor detected ANY  object that interfered with transmission.  To ensure the insertion of only a quarter  would trigger the system, 2 infared sensors were installed  at a quarter diameter apart. If a coin smaller than quarter size is inserted, both sensor emissions will not be disrupted and the basket will not unlock.

Quarter Insertion Slot

Basket Design

Box Design Process

The external design of the basket was an essential aspect to ensure its use and functionality on a kitchen counter.  Brown radiator tin enforced  with ornate metal wire was used to form the box. All essential lock components were wrapped with metal wire so they could be easily adjusted to their precise position. The user can also see through the box and know its contents without opening it.

(Top Left) Button Glued to Box

While the exterior of the design was improved. The metal components of the tin would occasionally conduct electricity through the external Reset Button and trigger the solenoids to lock. The Reset Button was glued to the box to form a non-conductive barrier and ensure proper functionality.

Discussion

Self-Critique

Overall, the design of the project had functioned as intended.  Although the exterior display was very detailed and ornate, the interior design should have received equal attention. Quarters after being inserted into the box are easy to take back by simply removing  the compartment. Another wire tie mechanism  could easily fix the issue. In addition, The electrical components are located in the same compartment in which the candy is expected to be held. A “false bottom” should be made and wire tied to hide the electric components and create space for the candy.

Surprises

Surprisingly, the decision to wire wrap all components of the box(instead of glue) enforced difficulties to break open the box.  A user must pull the ends of the wires located inside the box through the pinsized holes of the radiator metal repeatedly to remove the solenoids and hinges. The resting position of the solenoids is locked when it is not powered by an external power supply.

Lesson’s Learned

From the production of the Loli’s for Loot machine, I have learned how to properly use a transistor on items that require large voltages while protecting the arduino. Through trial,error, and sense of smell, I have successfully used one output to control numerous 9 volt mechanisms across a transistor. This set-up can be used with other motor accessories and will be extremely useful in future designs.

Next-Step

As previously discussed, the Loli for Loot Machine intentions will be successful with minor changes. The radiator material of the box should be replaced with a non-conductive material to ensure proper function of the elctronics. An internal quarter locking mechanism will need to be installed, so that inserted quarters can’t be removed. A false bottom should be installed to separate the electronic components and the candy. The metal eye hooks should be enforced with metal wire to prevent slippage.

Code

int solenoidPin = 6;
int IRPin1=A1;
int IRPin2=A2;
int reset=4;
void setup() {
pinMode(solenoidPin, OUTPUT);
pinMode(IRPin1, INPUT);
pinMode(IRPin2, INPUT);
Serial.begin(9600);
}
void loop() {
int read1= analogRead(IRPin1);
int read2= analogRead(IRPin2);
int pushbutton= analogRead(reset);
Serial.print(read1);
Serial.println(read2); // print the sensor value to the serial monitor
if ( read1==0 and read2==0){
digitalWrite(solenoidPin, HIGH); //Switch Solenoid ON
}
if(pushbutton==HIGH){
digitalWrite(solenoidPin, LOW);
}
}

Schematic

Overall View

Soft Pressure Sensor

Attached to Hand

Process

Decision Points

I had intended to attach the pressure sensor to a glove, but I needed a glove that was as unobtrusive as possible.  As it turns out, when somebody is selling a glove it is generally not for the purpose of attaching sensors, and so it has padding, seams, &c..  Eventually, I fell back to using a strip of roller bandage.

I started off using a buzzer to warn me when I was pressing too hard, but I realized that if I was going to use the device in lecture I couldn’t have a buzzer going of every few seconds, so I switched to LEDs.

Progress Images

Initial testing of the LED indicator, using a potentiometer in place of the pressure sensor.

Leads soldered onto conductive fabric. There is a hole from shaking and touching the iron directly to the fabric.

Soft sensor sewn together. The stitching is a mess.

Discussion

Self Critique

The project is a good proof-of-concept to show that the technical aspects are not particularly challenging.  The form, however, needs work.  The roller bandage is less comfortable than I had hoped, both in that it does not conform to the hand very well, and that it sticks to the paper.  Additionally, the sensor is quite thick, and interrupts my natural writing posture.  The LEDs are also fairly easy to ignore:  some form of touch feedback would work better.

Surprises

I was surprised by the range of resistances provided by the Velostat:  I was expecting a range of a few hundred Ohms at most, but it was actually a range of tens of kOhms.

What I Learned

Sewing a functional sensor is easier than I had expected:  sewing a beautiful sensor is harder than I had expected.  I would want to practice a few times on scrap fabric before trying another sensor, or use a machine.

Next Steps

I would like to try building a second iteration of the device.  I would build my own glove with the pressure sensor directly integrated into the side to reduce the fabric overhead that makes the current model uncomfortable.  I would also use a vibration motor touching the back of my hand to provide feedback.  Additionally, I would re-route the wires to be more comfortable, and place all of the electronics, and a battery, in a pouch on the back of the glove.

Technical Information

Schematic

Code

/*
 * Copyright 2018, Nathan Serafin.
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
constexpr int LED1_PIN = 2;
constexpr int LED2_PIN = 3;
constexpr int LED3_PIN = 4;
constexpr int LED4_PIN = 5;
constexpr int LED5_PIN = 6;

constexpr int SENSOR_PIN = A0;

constexpr int THRESH1 = 650;
constexpr int THRESH2 = 670;
constexpr int THRESH3 = 690;
constexpr int THRESH4 = 710;
constexpr int THRESH5 = 730;

void setup()
{
  pinMode(LED1_PIN, OUTPUT);
  pinMode(LED2_PIN, OUTPUT);
  pinMode(LED3_PIN, OUTPUT);
  pinMode(LED4_PIN, OUTPUT);
  pinMode(LED5_PIN, OUTPUT);

  pinMode(SENSOR_PIN, INPUT);
}

void loop()
{
  int sensor_val = analogRead(SENSOR_PIN);

  int led1 = LOW;
  int led2 = LOW;
  int led3 = LOW;
  int led4 = LOW;
  int led5 = LOW;

  if (sensor_val >= THRESH1) {
    led1 = HIGH;
  }
  if (sensor_val >= THRESH2) {
    led2 = HIGH;
  }
  if (sensor_val >= THRESH3) {
    led3 = HIGH;
  }
  if (sensor_val >= THRESH4) {
    led4 = HIGH;
  }
  if (sensor_val >= THRESH5) {
    led5 = HIGH;
  }

  digitalWrite(LED1_PIN, led1);
  digitalWrite(LED2_PIN, led2);
  digitalWrite(LED3_PIN, led3);
  digitalWrite(LED4_PIN, led4);
  digitalWrite(LED5_PIN, led5);
} 

GitHub Repository

The “de-icer” senses temperature and either sets my faucet to a drip or stops the drip.

The project in action (manually triggered the servo using a switch for demo).

A continuous rotation servo drives the wheel. LED lights indicate sub-zero/above-zero temperatures.

In real-life use, the temperature sensor would be placed outside.

Process

One major decision point was deciding the mechanism to lift and lower the faucet. I went through many mechanism ideas during the iteration process. Some mechanisms that I considered were a rack and pinion mechanism (shown below) and a gear assembly. The rack and pinion was difficult because it is difficult to constrain the motion in a reliable way, especially given the limited space I had to work with. Similarly, it was difficult to implement gears because I would need at least 4 gears to get a meaningful mechanical advantage. Also, for both of these ideas, meshing was a problem, because besides the inaccuracy in the laser cutting, I had a difficult time installing the laser cut pieces to the motor attachment because there are no features that make it easily mountable.

Another major decision point was to use the continuous servo motor. Other ideas that I toyed with were stepper motors and a DC motor paired with an encoder (testing process can be seen below). There was no simple way to attach the encoder to the DC motor while also turning the faucet, as I had trouble performing even simple tests. The reason I chose the continuous servo motor in the end was because it had a high torque output while being relatively easy to control. However, this did come with the caveat that the motor was not meant to stop at a particular angle. I was able to compensate for this by starting and stopping the motor at the appropriate time (after much trial and error).

Trying to test (unsuccessfully) the DC motor, paired to a rotary encoder.

Calibrating the continuous rotation servo motor with a potentiometer.

Testing the TMP36 sensor and reading the ambient temperature.

Putting together the laser cut pieces.

Discussion

I am relatively satisfied with my project. For this project, I wanted to focus on making something that was actually practical and something that I could actually use. For this reason, I decided to go with a simple design with few bells and whistles. During the ideation process, I thought of different features I could add to this project, such as an LCD display showing temperature readings. However, I thought this would not be very practical, as I do not really care about the exact temperature – I just don’t want my pipes to freeze during the night.

Once I started making this project, I quickly realized that it would be very difficult to make a device that can work on any faucet. Originally, I had an idea of clamping the device to the faucet so that it would be a more generalizable solution, but I realized that this would not be ideal for my faucet, because there is no good place to clamp the device. To make this device more useful for me, I decided to make it something that would work for my faucet, even if it isn’t something that would necessarily work with other faucets.

I learned that laser cutting is a useful tool, and that I can make clean looking enclosures. For this project, I chose 3mm acrylic to make the enclosure and wheel. Another thing I learned was how difficult it is to make a robust mechanism. Although I went through a number of design iterations, I ended on a simple solution, which turned out to be an effective solution to my problem. If I were to give advice to my past self, it would be to start the design iteration process as soon as possible. By doing this, I would be able to find the most effective mechanism for this project early on and focus on coming up with a device that works on more than just my toilet faucet.

I do not expect to build another iteration of this project. Although I am pretty satisfied with the end result, if I were to build another iteration, I would make a device that is more compact/subtle. This could probably be achieved using a smaller motor and appropriate gear reductions. Another issue that I would like to address (that was also brought up during the design critique) was to make this project a more general solution to this problem. At the moment, my device only works at the faucet in my bathroom sink, so it would be great if I could think of a solution to this problem that is more generalizable.

Schematic

Code

#include <Servo.h>

Servo my_motor;
const int TEMP_PIN = A0; // read temperature from this pin
const int SERVO_PIN = 3; // actuate servo from this pin
const int ON_PIN = 8; // led indicates whether activated or not
const int OFF_PIN = 9;
const int BUTTON_PIN = 5; // manually activate

float threshold_temp = 0.0; // will activate when temperature reading falls below this
int sample_time = 100; // how often to measure temperature
bool on_state = 0; // whether activated or not
bool manual_mode = 0;
int servo_speed = 28; // how fast servo rotates
int servo_delay = 200; // how long servo rotates
int off_speed = 28; //turns servo off
int prev_button_read = 0;

void setup() {

    pinMode(TEMP_PIN, INPUT);
    pinMode(ON_PIN, OUTPUT);
    pinMode(OFF_PIN, OUTPUT);
    pinMode(BUTTON_PIN, INPUT);
    my_motor.attach(SERVO_PIN);
    my_motor.write(off_speed);

    Serial.begin(9600);
}

void turn_motor(){
    my_motor.write(0);
    delay(servo_delay);
    my_motor.write(off_speed);
    on_state = 1;
}

void reverse_turn_motor(){
    my_motor.write(255); // reverse rotation
    delay(servo_delay);
    my_motor.write(off_speed);
    on_state = 0;
}

void loop() {
    int reading = analogRead(TEMP_PIN);
    int button_read = digitalRead(BUTTON_PIN);

    delay(sample_time); //debounce and regulate number of temperature measurements
    float voltage = reading * 5.0;
    voltage /= 1024.0;

    float current_temp = (voltage - 0.5) * 100;

    Serial.println(current_temp);

    if ((current_temp < threshold_temp) and (! on_state)){
        turn_motor();
    }
    else if ((button_read) and !(on_state) and (prev_button_read != button_read)){
        turn_motor();
        manual_mode = true;
    }
    else if ((current_temp > threshold_temp) and (on_state) and (! manual_mode)){
        reverse_turn_motor();
    }
    else if ((button_read) and (on_state) and (prev_button_read != button_read)){
        reverse_turn_motor();
        manual_mode = false;
    }

    if (on_state){
        digitalWrite(ON_PIN, HIGH);
        digitalWrite(OFF_PIN, LOW);
    }
    else{
        digitalWrite(ON_PIN, LOW);
        digitalWrite(OFF_PIN, HIGH);
    }

    prev_button_read = button_read;
}

A container incorporated into the structure of a refrigerator that shows how long an item has been inside of it.

Images

Overall Photo:

Fig(1): This image displays the full container meant to show scale. A bowl is placed to show volume of container. There is an LCD screen in the front which notifies the user of how long an item has been placed in the container as well as a pause switch to continue the timer if an item is taken out of the container. The wooden housing contains both the emitter and detector of the break beam sensor with the Arduino and breadboard located underneath the blue acrylic.

Detailed Views:

Fig(2) Pause Switch: This switch is used when the user wants to take something out of the container to eat but still wants the timer to run for the item. They can flip the switch up to make the timer continue to run even if the break beam sensor does not show anything in the container. The switch in normal mode means that the timer will reset once the sensor no longer detects an item in the container.

Use Images:

Fig(3) LCD Timer Screen: This picture shows the LCD screen which shows the user the amount of time an item has been inside of the container. The timer shows days, hours, minutes and seconds and increments as long as an item is inside.

Fig(4) Full Working Photo: As seen in the photo, as the break beam detector (taped in the back) no longer can detect the light it means that an item is in the container. The bowl causes the different reading with the sensor and thus starts the timer and lights up the LCD screen as seen on the bottom of the picture.

Process

Decision Points:

1. The first major decision point was determining which type of sensor to use in the application. This would effect the overall structure of the container as well as become the main input into the system. The decision to go with a break beam  sensor was made due to the conditions the container when used in the actual application. As a refrigerator has no light when the door is closed this meant that a photoresistor could not be used. Other sensors considered were proximity sensors and ultrasonic range finders but these sensors were not as useful in this application as a break beam sensor. The input the system wants is simply whether an item is in the container or not and those sensors mean that there would be an extra step of converting distance to presence. The break beam sensor was perfect because it tells simply whether an item is present between the detector and emitter is all we wanted. This choice was important as the container was made to house the sensor at a distance and placement that it worked well.
2. The second major decision point was to use laser cut components and glue to build the structure of the container. This led to changes in design from the front and back wooden structures to the acrylic center. Deciding to glue the structure meant everything needed to be flush with one another. It also led to the need for certain pieces to have lips built on in order for different pieces to easily fit on top of the lips. This made the design process easier in the sense that there was no need to drill any holes or use any fasteners besides with mounting the LCD screen.

Process Pictures:

Figure(5) Circuit Design: The first step was to build the circuit and write the code for it. I began by wiring the LCD display the the Arduino and creating the code to run the timer. As this was the basis of the system it was important to get the timer to work first. From there I added the break beam sensor and made it turn on and off the timer based on waving my hand to break the beam. Then I added the pause switch which made the timer still run no matter what the sensor input was. From here I had all the functionality I needed out of the different components and would later have to solder connecting wires to the different parts of the break beam sensor and switch in order to add the length to reach the breadboard.

Fig(6) SolidWorks Model. Once I completed the circuit I was able to get all the dimensions of the different components in order to create the SolidWorks Model. I began the model by making the front wooden structure which houses the LCD display, switch, and break beam emitter. Then I was able to copy a similar structure to create the housing in the back of the container. Then I was able to create the plastic center walls/base based upon how large a container should be to properly house everything from plates to leftover boxes. I was able to create the assembly to make sure everything would properly mate together and then created the drawing files to cut the parts on the laser cutter.

Figure(7) Laser Cut Parts: I then laser cut the 20 parts necessary to create the container. The high number of parts is due to needing to house the LCD display and sensor in the wooden structures as well as having a raised platform in order to house the Arduino and breadboard below the container. I was able to take the laser cut parts and quickly test how they matched up to see if I could successfully build the structure.

Figure(8) Fully Built Prototype: Then I was able to fully build the structure and incorporate the circuit. I began by building the wooden structures, drilling the holes to screw in the LCD display, and fixing the switch and sensor in their proper locations. From there I was able to add the acrylic sections which served as the bottom of the container, the raised platform and the surrounding walls. I was able to glue what I could and then added tape to provide last minute rigidity to the structure to make up for tolerance issues with some of the dimensions of different parts. The hole where the battery is attached was originally meant for the usb cord in case I needed to make any coding changes after construction. Overall everything was able to fit well within the structure and it was able to successfully work.

Discussion

Self Critique:

I am pleased about certain aspects of how my project came out. From an aesthetics stand point I would have liked to not have had to use tape to hold certain parts together. The wood sheets were slightly undersized which led to everything not matching up perfectly as planned. I should have taken the time to add fixtures to the design rather than have everything be flush to one another and glueing it. The CAD design had white acrylic which gave it a more distinguished look and would better fit in with the white inside of most refrigerators but there was not any large white sheets of acrylic that I could use. From a technical standpoint I think the use of the break beam sensor worked perfectly for the application. It never had a problem not detecting an object. I was happy with the timer on the LCD display and thought it worked well.

The biggest surprise along the way had to due with building the actual structure. Not having all the correct materials that I wanted led to having to change certain things from using different color acrylic to using tape to hold things together. The break beam sensor worked better than I thought that it would in that it did not have a lot of noise when putting an item in or taking an item out that led to the timer being messed up. From a project overview perspective there was some critique about the functionality of the product and if it was necessary. I think largely for people who live alone or are more organized this product may seem unnecessary. I think it can still be beneficial to everyone but can largely help in houses where a lot of people live and fridges can be stocked with many different random items/leftovers. It will help to distinguish some of the clutter and become more organized.

I learned many things throughout this process. I think that I was able to get through the electronics hardware/coding parts relatively easily. This has given me the confidence to try harder and more involved projects in the future. Not having any experience coming into this class I think I have picked up on things well and am looking forward to trying to create more difficult systems in the future. I also learned a lot about building in tolerances to my design. As I simply made every piece fit flush on my CAD model with the thought that I would glue it it leaves little room for error. If I were to have designed the structure to be fastened with screws or different fixturing methods I would have had an easier time putting slightly ill fitting pieces together. I think putting more time and effort into the structure would have been very beneficial in the end.

If I were to build another iteration of this project I would focus more on how to integrate the structure into an existing fridge. Whether this would be working on creating a drawer with a similar functionality or creating a shelf that could detect the same thing I think in order to make the design more robust I would have to make it work in an actual fridge. From this process I think the break beam sensor has proved that it is a good option to use. I think possibly adding multiple break beam sensors in almost an array pattern would be able to tell if items were in different parts of the container and not just simply in the middle. Overall I think the functionality of the product could be incorporated many different ways into a refrigerator so it would be interesting to test different options to see what would work the best.

Technical Information

Circuit:

Code:

code language = "C"
 #include <Wire.h>
 #include <LiquidCrystal_I2C.h>
 #include <Math.h>

LiquidCrystal_I2C lcd(0x27,16,2); // set the LCD
 unsigned int Seconds = 0;
 unsigned int Minutes = 0;
 unsigned int Hours = 0;
 unsigned int Days = 0;
 unsigned long Timer = 0;
 const int Sensor = 2;
 const int Switch = 7;
 int SensorVAL = 0;
 int SwitchVAL = 0;

void setup(){
 lcd.init(); // initialize the lcd
 lcd.backlight();
 pinMode(Sensor,INPUT);
 pinMode(Switch,INPUT);
 Serial.begin(9600);
 }

void loop(){
 SensorVAL = digitalRead(Sensor);
 SwitchVAL = digitalRead(Switch);
 Serial.println(SwitchVAL);
 if(SensorVAL == LOW && SwitchVAL == LOW){
   Serial.println(millis());
   Serial.println(Timer);
   Serial.println(round((millis()-Timer)/1000));
   Seconds = (round((millis()-Timer)/1000))%60;
   Minutes = (round((millis()-Timer)/60000))%60;
   Hours = round((millis()-Timer)/3600000)%24;
   Days = round((millis()-Timer)/(3600000*24));
   lcd.setCursor(8,0); // sets cursor to 3rd line
   lcd.print ("Hours ");
   lcd.print (Hours);
   lcd.print (" ");
   lcd.setCursor (0,0); // sets cursor to 4th line
   lcd.print ("Days ");
   lcd.print (Days);
   lcd.setCursor (0,1); // sets cursor to 2nd line
   lcd.print (Minutes);
   lcd.print (" min ");
   lcd.setCursor (8,3); // sets cursor to 1st line
   lcd.print (Seconds);
   lcd.print (" (s) ");}
 if(SensorVAL == HIGH && SwitchVAL == LOW){
   Timer = millis();}
 if(SwitchVAL == HIGH && SensorVAL == HIGH){
   lcd.setCursor(0,0);
   lcd.print ("Paused");
   Seconds = (round((millis()-Timer)/1000))%60;
   Minutes = (round((millis()-Timer)/60000))%60;
   Hours = round((millis()-Timer)/3600000)%24;
   Days = round((millis()-Timer)/(3600000*24));
   lcd.setCursor(8,0); // sets cursor to 3rd line
   lcd.print ("Hours ");
   lcd.print (Hours);
   lcd.print (" ");
   // lcd.setCursor (0,0); // sets cursor to 4th line
   // lcd.print ("Days ");
   // lcd.print (Days);
   lcd.setCursor (0,1); // sets cursor to 2nd line
   lcd.print (Minutes);
   lcd.print (" min ");
   lcd.setCursor (8,3); // sets cursor to 1st line
   lcd.print (Seconds);
   lcd.print (" (s) ");}
 if(SwitchVAL == HIGH && SensorVAL == LOW){
   lcd.setCursor(0,0);
   lcd.print ("Paused");
   Seconds = (round((millis()-Timer)/1000))%60;
   Minutes = (round((millis()-Timer)/60000))%60;
   Hours = round((millis()-Timer)/3600000)%24;
   Days = round((millis()-Timer)/(3600000*24));
   lcd.setCursor(8,0); // sets cursor to 3rd line
   lcd.print ("Hours ");
   lcd.print (Hours);
   lcd.print (" ");
   // lcd.setCursor (0,0); // sets cursor to 4th line
   // lcd.print ("Days ");
   // lcd.print (Days);
   lcd.setCursor (0,1); // sets cursor to 2nd line
   lcd.print (Minutes);
   lcd.print (" min ");
   lcd.setCursor (8,3); // sets cursor to 1st line
   lcd.print (Seconds);
   lcd.print (" (s) ");}
 }

/code