Introduction

After our initial interview with Jim (which is documented here), we decided to have a follow-up interview to more specifically nail down an idea. After a substantial and creative conversation, we came up with a our idea.

A main feature of Jim’s living room is a large Boston grand piano which both Jim and his wife use extensively for pleasure and entertaining. One hassle, however, is that the piano requires a certain humidity to maintain its condition during the winter. In addition to their love of music, Jim and his wife also enjoy the sights and sounds of indoor fountains. After some discussion, these two themes seemed to complement each other nicely. 

Our Idea: Build them a controllable fountain that provides both the tranquil sounds of moving water and also actively monitors and maintains the correct humidity for their piano.

Below we outline the process of creating our initial prototype for Jim’s new fountain.

Prototype

Our prototype has two separate parts: a fountain module (in the middle) with the pump, LED strip, humidifier and a radio receiver, and a remote module (top right) with a humidity detector and a radio transmitter.

Since our group had a relatively late start, we focused on finishing most of the technical components instead of the aesthetics. We decided to divide our project into two physically separate parts: the first one is the main fountain module with a pump, a humidifier, and LED indicator that shows the humidity level, and the second part is a remote module that detects humidity from a distance and sends radio signal back to the main module. Right now, the remote module will send signals back to the main controller every 5 or so seconds. If the primary module detects that the humidity is too low, it will simply turn on the humidifier until it detects that the humidity is no longer too low. The LED will accordingly respond as well. Currently rainbow colors indicate a correct humidity while red or blue indicate either too low or too high respectively. The pump’s power too can be adjusted using a small dial though it wines when it gets too weak as the our current model is not intended for varying speeds. 

In the end, we intend for Jim only to have to interact with the primary fountain module. With full battery, the remote module should continue transmitting normally for ~6 months to mitigate the hassle for Jim, at which point he will simply have to replace a couple of AA batteries. 

For the prototype, we have solved most of the technical challenges:

The “actual” fountain with the humidifier in shallow water, an LED strip and an adjustable pump. The humidifier disk has to be on the surface of shallow water to make the mist (this will be an important design consideration). The LED strip currently shows red because the humidity level is below the desired threshold.

The radio transmitter for the main fountain module. This will be responsible for communication with the remote humidity module located near the piano.

For the main fountain part, we have:

• An adjustable pump
• LED strip that displays the humidity
• A humidifier that turns on when humidity is below a settable threshold
• A radio receiver

The remote module separate from the main fountain has a humidity detector (to the left) and a radio transmitter (to the right). These will be incorporated into a more compact package which will include a battery pack.

For the remote part, we have:

• Humidity detector
• A radio transmitter

Combined humidity and temperature sensor for the remote module.

Radio receiver in the main fountain part (to the left) and radio transmitter in the remote module (to the right).

Breadboard that has a button to manually turn on the humidifier and a potentiometer that adjust the pump power.

A potentiometer on a breadboard that adjusts the pump level

Process

The process of putting it all together:

Here the separate radio modules are wire up together for the first time. At this point, either radio can act as a transmitter or receiver of data.

Here we are completing our first tests with the jerry-rigged humidifier module. We’ve attached our own wires to the pins we needed to the turn the attach pcb circuit on and off with our own button.

The updated design for the box that will hold our remote humidity sensor, transmitter, and battery is being 3D printed here. We had to increase the volume of our design in order to hold the necessary number of batteries.

Different parts of the project start to be integrate. At this point we have a humidifier attached to the primary radio module while the humidity sensor and transmitter module are still sending data (picture at right).

All of the major components of our main module are combined. Now the pump is connected along with a potentiometer to control its speed. We tested both the humidifier and pump using a simple bucket of water.

With the main module complete with an LED indicator strip, we demonstrate the basic functionality. At this point the humidifier is automatically responding to the readings from the remote humidity sensor module. Any time it senses humidity below 40%, it begin to atomize the water.

Adjustable LED strip: the LEDs turn red when the humidity level is below the threshold (40-), turn rainbow if it’s right above the threshold (40-50), and turn blue if it’s too much above the threshold (60+).

Discussion

We had a really great discussion with Jim during our hour-long conversation last Tuesday. Though we were initially a little unsure about whether we would be able to fill such a long stretch with continued conversation. To our pleasant surprise we learned a lot from Jim who seemed pleased with our progress so far, but was also very adamant and prepared to offer his own opinions on many different aspects of our product from design to hardware to the way we were implementing state-machine-like behavior in our code. One aspect that he had some great suggestions on was the remote humidifier module that we are developing. We learned that he would like to last for at least 6 months using battery power with a low-profile and a method for indicating low-battery power. All of these seemed feasible to us and were not something we had initially considered implementing. In addition, probably spawned from his love and background in physics, Jim also mentioned that he it would be great if the fountain could include a visual display showing things like humidity and estimated humidifier completion time (calculated using the diffusion equation, he added).

On the UX side, we tried to probe Jim on some of his preferences in terms of visuals or sounds. An interesting snippet from him was his mention of falling water and how much he loved the water pooled then trickled then splashed as it made its way through the property. To us, this Pittsburgh icon seemed like a great source of inspiration for us as we considered the aesthetic and design of our indoor fountain—especially since Jim has mentioned to us his love of architecture before! For the texture, we agreed that both smooth and rough landscapes had their charms, but agreed that for a fountain of this type, a rougher landscape could be more enjoyable and allow for a more dynamic flow of water into the basin. Small pebbles and shrubbery were also other elements that Jim had added to other fountains around his house and had enjoyed.

One idea of which we were a little skeptical was Jim’s suggestion that we use a pre-existing green ceramic basin that he had at his home. It seemed to us that it would limit the possibilities of the fountain’s footprint, we well as the kinds of I/O elements we might have wanted to integrate to the base (such as indicator LEDs and a small screen)—not to mention the fact that it didn’t seem big enough to fit a basin, pump, and electronics. Later on, however, Jim joined us in this sentiment with an email he sent us later on expressing that his basin was probably not ideal and he had enjoyed some of the sketches we had made up in class.

Moving Forward

Looking ahead, work will be divided into three primary areas: Fountain Design and Manufacturing, Electrical Miniaturization, and Final Assembly. In general, we are almost completely finished with most of the technical implementation of our fountain and its features. This just leaves miniaturizing all of our components to be neat and easily installable in our final fountain. The most difficult challenge facing our group from here on out will almost certainly be the design and manufacturing of the actual fountain. There will have to be a significant amount of time spent on the CAD of the fountain’s topology and figuring precisely out we will go about vacuum forming its bowl and other features. Some of the biggest features we will need will be an easily refillable reservoir, small pools in which to place the humidifiers, and a small OLED/LCD screen to display important measurements and metrics. Finally, with all of this (hopefully) finished, we will have to proceed with assembling all of our components. By now, everything should have been individually tested and then wired together and tested that way so that all the entire system requires is placing and securing components in our final package. At this point, our wireless transmitter is nearing this point, but we have been unable to reach a similar point until other components we have ordered have arrived. To ensure steady progress, we plan on having at least one of us working in Hunt every evening, especially for those nights when we have to finish especially time consuming tasks like CAD.

More specifically, we hope to keep ourselves to this timeline:

• Wednesday, Nov. 20th – Finalize fountain design CAD, and Electronics container
• Friday, Nov. 22 – Finish all electronic and integrate new parts
• Saturday, Nov. 23 to Nov. 24 – Begin and Finish fountain manufacturing (vacuum forming the bowl and all other 3D printing)
• Monday, Nov. 25 – Begin assembly and integration of all parts
•  Sunday, Dec. 1 – Dec. 2 – Continue and Finish final integration
• Tuesday, Dec. 3 – Final Crit

What if we all possessed enhancive devices that would turn any boring, house chore into a playful activity between us and our family? Then, wouldn’t chores become a more joyful and engaging activity of our daily routine? Imagine for example washing the dishes and at the same time interacting with your body to answer questions concerning your favorite topics like films, books, sports, cooking, etc. That kind of adrenaline rush could render dish cleaning playful, transforming forks, spoons, knifes into checkers of an interactive game.

Our prototype reconstructs a trivia game into a cards-free interaction game. Choosing the right answer becomes a bodily experience in the kitchen,  turning cutlery and utensil into participatory game pieces. Each answer of the multiple choices corresponds to: a) a different color and b) distance range, so that players choose their answer locating their hand or checker at a particular distance of the sensory box.

Game board and ultrasonic sensor

Inside of the box – organization of components

Process

Overview of the kitchen

Integrating the device in the kitchen 1

Integrating the device in the kitchen 2

I2C SD card reader – SD card loaded with Trivia questions

Close-up of the ultrasonic sensor – this is what will determine the answer picked

Planning out the different parts required a lot of testing!

Corresponding the answers to distance range

2 LCDs 20×4,  LCD1: scrolling questions, LCD2: Multiple choices

Enid choosing answers

Enid chooses the correct answer

Schematic diagram of the prototype

Discussion

Though it was difficult to converge onto an idea to execute, once we decided on the project, it was clear that an interactive trivia game was the perfect task for our team and Enid. However, it was very unclear what technologies we wanted to use to accomplish this. During our brainstorming phase, we looked into potentially using a wireless-enabled device to present questions via an online text-to-speech service. This proved to be too ambitious for numerous reasons: A.) We would need to order additional parts, delaying our design process and B.) We learned that Enid wanted to avoid having another online device that competes for bandwidth. In the meantime, we decided to load trivia questions onto an SD card, and display the texts on LCD screens.

We had some difficulty working with the SD card and LCD screens in tandem, but some refactoring of the code into helper functions allowed us to re-implement the way we displayed answers. Though we still do not know what the original problem was, this reorganization helped us move forward. The next challenge is an ongoing one. Because of the limitations of the LCD screen, we needed a way to display questions that are longer than the number of spaces on the screen. Tentatively, we decided on scrolling through the text on the top line of a screen, but Enid raised the concern that it is too difficult to keep an eye on the screen constantly while doing the dishes. This will be discussed further soon.

We are also using the built-in Arduino random library to shuffle questions and answers. The library uses a (presumably) random voltage reading of a disconnected pin as the “seed” of the generator. However, it seems that the seed is not entirely random, and on each round after the device restarts, there are only a few possible starting values. This means that we are only able to access a small subset of the questions.

The critique we had with the class and Enid was very useful to our group. The prototype we showed was meant to be placed on the countertop, with the understanding that as one is cleaning up, they can merely put an object in the right location a convenient distance away from their workspace.  Enid mentioned that we should consider resizing it. The project as it stood right now would not be practical to put on the countertop, as it would take up way too much space. In fact, she would prefer if we didn’t have it on the countertop at all, what if it were on her window instead? In this orientation, it would be in her line of sight as well, and would be easier to view questions and answers. In order to do this, we plan to have the range to pick answers lining the box the electronics are housed in, rather than coming out of it as shown in our current prototype. This is a slight modification that would greatly shorten the total space used and be more effective for Enid to use. In addition, she preferred this not to be a permanent installation. If there was a way we could easily remove our project, this would be ideal.

She also mentioned that she has trouble reading the single-line scrolling question. She brought up good points like what if she missed a part of the question? Or forgot what it was while answering? She would like to see at least the way we present the question be reformatted, say maybe filling up the screen, or repeating in case she forgets.

Overall, Enid really liked the approach we took with this project. She was super excited to play the game and answer the questions, and told us that she would definitely play this with her husband during clean-up sessions. Later, we went back to her house to take some final measurements of the kitchen and showed her husband the prototype as well, and he also seemed excited about the idea. It was a very positive critique session, and we were still able to get a clear picture of what had to be done in the coming weeks to complete the project.

Moving Forward

Our main things to focus on are the things Enid mentioned in the crit. The first focus would be to refactor the fabrication and presentation of the project with minimal changes to the software. This would include creating a smaller box of similar proportions to the one in the process pictures. It would also require shortening the ranges of the answers to match the length of the new box, but the wiring would remain largely the same. We would also have to find a way to better present the question and eliminate/improve on the scrolling text. We also plan on adding more questions of more variety based on preferences Enid had told us, and improve our current method randomization. We could also add things such as keeping a scoring system or a way to pick the categories, but these will only come after we fix those primary issues.

General Timeline for Final Project:

• Nov 17th: Meet with Enid to get more feedback/take measurements
• Nov 19th: Fix scrolling and randomization issues, start planning out new fabrication design
• Nov 17th – 22nd: Create new fabrication
• Nov 23rd – Dec 3rd: Add last-minute tweaks and improvements, change fabrication if necessary

The goal of this project is to create a an assistive device for an older person, in our case, this person was Jan. In our last post, we visited Jan in her home to discuss what day-to-day problems she experienced, and propose potential projects to  aide her. By the end of our visit, we had settled on a device which would help her remember to exercise, and keep track of how active she was being.

Since that post, we’ve been able to construct a prototype of our device, which implements many of the core features we had planned in our first post. On Thursday, November 14th, we met up with Jan again to show her the device, and collect her feedback on how the device had evolved.

Prototype

Our initial prototype for the workout clock.

The clock is able to display a simple bargraph of the past two week’s worth of exercise times.

We selected a large, easily pressable button to activate and stop the timer. Here, the clock is counting how long the timer has been running.

To solve the goal of reminding Jan to stay active, our group constructed a countertop clock, which keeps track of her exercise habits. When Jan leaves her house through the back door to exercise, she presses the large button to start a timer. Upon her return, she presses the button again to stop the timer, and log the time she spent exercising, which the clock can display as a graph on its screen. The clock also features a motion sensor, which is used to occasionally remind Jan if she hasn’t exercised for the day and is in the room.

Process

Sketches of ideas for how the final product might look, and how the information could be displayed. We weren’t looking to settle on a design, but wanted to get a good idea of what components to include in the prototype.

The LCD screen with the displays being tested. Early on the LCD screen and the clock were worked on separately, and were later merged together.

The prototype in the middle of development. The green LED was there to test the motion sensor, and was replaced by the speaker in the final prototype.

A test to make sure that the time spent exercising is being tracked when the button is pressed and that the graph is displaying the information correctly.

The display showing the time and date, although it isn’t the right time or date.

A timer that will be displayed while Jan is exercising, so she can see how long she has exercised for.

A graph that will display how long Jan exercised each day for the past two weeks. It currently displays the time between button presses with each pixel being one second.

George testing the motion sensor by walking in front of it. The idea is that if the motion sensor senses Jan walk into the room, it will make a noise to remind her to exercise.

Prototype of the lights we want to use to display the exercise history for the past week. They weren’t a part of the prototype since they are still being worked on, and the final version will most likely use seven LEDs that can be red or green instead of 7 red and 7 green LEDs.

Discussion

Our project features many technological features that worked relatively independently, so we were able to each work on a different problem for much of the prototyping process.  While efficient, this parallel method of working created challenges when combining the parts.  Because different aspects of the code were designed by different group members, many connecting details like variable names had to be corrected.  Furthermore, time was needed for each individual to learn how the others hardware and code functioned.

Another challenge in prototyping came from the physical limitations of the Arduino.  We planned to use 7 lights which can be either red or green to visibly represent Jan’s recent workout history.  However, using conventional wiring practices, this would require 14 Arduino pins, which there is not enough pins for.  To solve this problem we decided to use transistors to reduce the number of pins to 7.  This method is possible because each light can be either red or green at a certain time.  Eventually this method was effective, but it took a large amount of time to learn an effective wiring and was not able to be incorporated into the prototype by the critique.  Thankfully, this was more of an additional feature than a core functionality.

The critique on November 12th gave us insight into how to better personalize our final project for Jan’s own use.  We found the personal conversation with Jan to be the most useful part of the critique and were surprised how easy it was to fill an hour with meaningful conversation about our assistive device.  We were originally unsure about the timing of our reminder system, but Jan mentioned that a beep every 3-4 hours between 9am and 9pm would be sufficient.  She also raised several concerns such as her neighbors coming to feed her cat when she is away and her wanting to be able to change the reminder time if necessary.  Therefore, we think it would be useful to include an option to turn off and change the reminder system.  Furthermore, we discussed ideal room placement and size for our final project, and Jan sent us measurements when she returned home.

While there were many useful suggestions from the critique, not all criticism could be acted on.   Jan pointed out that her cat could set off the infrared sensor and asked if there was any way to prevent this.  However, our current PIR sensor returns a single binary value, and  a correctly interpret an analog signal from a different sensor would require extensive and invasive testing.  Therefore, we believe it is best to ignore this specific problem.  Also, in the full class critique someone pointed out a small break in our LCD display’s bar graph.  This problem is caused by the physical limitations of the display (not having any pixels in the area of the break), and would require a different display to be used.  We have chose to ignore this criticism, because we believe time spent incorporating a  different display could be better used elsewhere.

Moving Forward

Having gotten some useful feedback from Jan, we’re ready to proceed with this project to completion. One major addition that we plan to make to this project is the construction of an aesthetically pleasing enclosure for our electronics. Additionally, we intend to add the following features over the next few weeks:

• (11/19/19) – Add the LED bargraph to the main circuitry
• (11/19/19) – Implement a “power off / mute” switch
• (11/21/19) – Implement a dial interface for setting the time
• (11/21/19) – Begin construction of the plastic enclosure
• (11/26/19) – Final assembly of project
• (12/3/19) – Final project crit
• (12/5/19) – Last minute bug squashing and tweaks

Our initial meeting documentation can be found here.

Prototype:

Overall photo of the device in its off state.

Frontal view of the device at cool color temperature and low intensity.

Detail view of the top surface of the prototype, including the LCD display, knobs, and buttons.

Demonstrating the features of the prototype.

The device is intended to be a light source that is capable of simulating natural light based on different parameters of weather and time of day. It has two knobs that correspond to color temperature and intensity, as well three buttons that correspond to a sunny, cloudy, and sunrise/sunset preset condition. It was designed as a portable device that Jeff could bring to the homes of his clients and hold up behind different samples of blinds in order to demonstrate their unique qualities (e.g. blackout, semi-opaque, sheer).

Process:

This sketch shows the notes on the initial parameters we intended on incorporating in the prototype. The design of the prototype was also fleshed out through drawing.

We focused on getting the color temperature and intensity features working as a first step. This was done with the Arduino Uno, an LED strip, and two potentiometers.

Early on, we were considering a battery powered design for the device to be more portable. However, we decided to make a plug-in prototype in order to concentrate our efforts elsewhere.

In terms of design and fabrication, the CAD work was done in Fusion 360 and 3D printed. A progression of the design can be seen as follows.

We included holes to wall mount the encoders, buttons, and LCD screen. We also chose to add an indent on either side to provide an easier grip.

At this point, we began adding material appearances in order to visualize what the 3D printed outcome would look like.

We also tried to render the form with a emissive appearance that was intended to represent the panel of LEDs. However, it did not come out very well.

In unifying the electronic and fabricated components, we began by laser cutting a sheet of acrylic that fit inside the box, and bending the LED strip so that it covered the sheet. The LED strip had an adhesive backing so it was easy to apply. Later on, we had to remove the strip and remount it to a smaller sheet of acrylic, since this one did not fit.

This is a photo of all the components we had working at this point. After programming the encoders (which were previously potentiometers), we added the LCD display.

A close-up of the LCD display showing color temperature and intensity values.

A photo of Larry writing the code for the button presets.

A gif that shows a piece of support going flying after being chiseled off.

Discussion:

Various challenges faced the development of this prototype, from the initial design to its exterior appearance. We had struggled for days to find a suitable design that could be of use to Jeff, but we eventually came up with the idea of this light that could potentially aid in his professional business and be within the scope of our project. From there, the basic design for a prototype came fairly naturally, such as the features of tunable controls and a few convenient presets. But we faced a certain problem when trying to transition between controls and presets. The potentiometers we initially used had limitations on the extent they could rotate, making it hard for a seamless transition from a preset setting to whatever we tuned it to, as we had to jump to whatever the potentiometer position was when we tuned the color away from a preset value to ensure that the knobs wouldn’t be at a, let’s say ‘high’ value while displaying a lower value, as turning the knob higher wouldn’t allow it to go much further, despite having more range available that the LEDs could display. Encoders resolved this issue since they had no limitations on how far they rotated. We also encountered some issues with removing the support material on the casing, since the device needed to do so was out of commission. Thus, we chipped away at it by hand. The end result might’ve suffered slightly in appearance, but fortunately, it performed as desired.

After our formative critique with Jeff, we were able to gain many valuable insights into the future steps for our project. Jeff informed us that, although he had used simulate lighting demonstrations in the past, they were large setups that are hardly portable within the trunk of a car. Thus, a portable light source that could do something similar, albeit on a smaller scale, could give him an edge over competitors who wouldn’t be able to show them such a presentation. This can be especially practical in an often cloudy city like Pittsburgh or when no daylight is available, where it can be hard to show customers how some blinds might appear on sunny days, or how well they can block out intrusive artificial light from the neighbor’s yard or light from the interior to protect the customer’s privacy. Part of Jeff’s job is showing the customer what are the best blinds for their needs, and this could certainly help with that. Thus, our concept had been met with approval, and we were also able to receive significant critique on our design regarding how we could improve it to fit Jeff’s needs, making for a very productive critique session.

Critique Inputs and Moving Forward

Among the the many pieces of advice we had received, several important points stood out. Since we had been aware of this drawback in the prototype, we weren’t surprised when the subject of the lighting brightness and color was brought up. Our prototype was using an RGB LED strip, but it wasn’t close to intense enough to achieve bright enough lighting that could actually simulate how sunlight would appear, which we intended to save for the final version when we knew we had a good prototype concept. Jeff also requested that we change the dimensions from a fairly square width and height to a rectangular one. Furthermore, he was interested in a slightly elevated design so he wouldn’t have to hold it up, freeing his hands to demo his blinds. We proposed building a stand and using it as a storage device as well,  which worked for Jeff. Our prototype also didn’t diffuse the light enough, but we’ve got several solutions in mind, such as moving the light source further back from the frosted acrylic pane, since we had it fairly close in the prototype. Jeff had mentioned adding a heat feature of some sort, which we think the high intensity LEDs may make possible as an added bonus, although the intensity of this heat is uncertain.

Aside from those major goals, there were several other minor changes we also discussed. While we had initially brought up storing more presets with Jeff, which was a good idea, we eventually learned that he probably wasn’t going to need more than 3 presets like we had on the prototype, so any others could be tuned himself. Jeff had mentioned using a rocker switch as he didn’t need the fine control, but we concluded we would probably stick with the current input design as it worked anyways and didn’t suffer from bouncing. On the aesthetic side, Jeff requested that it come in black, which would be doable. While he had been fine with the tactile interface as it met all practical needs, it was not without possible improvements. We considered that slightly larger knobs might be nice, but since we had already ordered buttons previously that were similar to our current ones, we were probably still going to use them.

Overall, our priorities were going to be programming and wiring up a new light source, setting up new presets and adjusting the acrylic window to approximate real world lighting conditions, adjusting the dimensions, and building a stand. Following those will largely be aesthetic goals that we hopefully can accomplish after taking care of our priorities.

Timeline:

Fri. Nov. 15 – Research and submit request for brighter LED module

Sun. Nov. 17 – Finalize CAD for new design, submit to Stratasys

Tue. Nov. 19 – (in class) If printing is complete, remove support material. Otherwise, design and laser cut acrylic pieces (LED backing, diffusing cover, stand elements). Programming and hardware.

Thu. Nov. 21 – (in class) Design and laser cut acrylic pieces. Programming and hardware.

Sun. Nov. 24 – All electrical components finalized and working, stand fabrication complete.

Tue. Nov. 26 – (in class) Finish 3D print (sand and spray paint)

Thu. Nov. 28 – (in class) Finish 3D print (sand and spray paint)

Fri. Nov. 29 – Finishing and spray paint complete

Sat. Nov. 30 – Final assembly

Tue. Dec. 3 – Final project crit.