H2duinO

This past week has been exciting as we have made a significant amount of progress. Our code is now fully functional and our final bottle model is nearing completion. The transition from paper cups to a water bottle required a few slight code alterations, as the thicker plastic walls made the capacitive sensors less sensitive to changes in water level.

This video shows our code working on a paper cup. The LED is set to blink every 10 seconds if water is not consumed (it will probably be 1 hour in our final model). The LED turns off/timer resets if the water level goes down.

Some process photos of water bottle construction:

Video demo testing water bottle prototype using same code from previous video:

Week 9: Finalizing

Amber & Meleigha

This week we continued the process of constructing the umbrella. Today we focused on the cover and the sensors inside. This proved to be more of a challenge than it would first appear. First off, the umbrella bends inward and isn't meant to collapse like a normal umbrella. This leads to the fabric sagging. Which would be okay except our sensors are activated/the circuit is completed when the top layer of fabric touches the under-layer of fabric. The sagging of the edge, therefore can trigger our sensor.
To help the sagging, we added wire "framing" between each of the arms (this was done with amber holding the umbrella while Meleigha laid on her back and wove it around)Our next challenge is to attach the motors in a stable way and attach the strings to the spooling system in a way that pulls each of them evenly and from the correct angle.
Our code is in progress. We have written what should be functioning code, but when tested with LED lights, the program does not respond as expected. So we have some trouble shooting ahead.

Week 9

Amy & Amy


All that is left for this project is fixing our code and making a more permanent system within our hoodie. We have our main code, but are having issues with transitioning form color to color within the PWM range (to work fluidly together). 

As far as assembling our "Expressive Hoodie", we have started to solder a permanent breadboard for the housing of the LED's and need to hook up the appropriate wires. From there we just need to sew and attach the wiring and pressure sensor onto the hoodie, as well as hook up a battery for portability.

Week 9: Neil R. & Inness

Debugging and building are all we have left to do to complete this project. All of our components have been soldered onto our protoboard including the receiver chip and both battery packs. We are able to code all of the functions of our device, but are still having some issues with the device working consistently.

We also need to write a fully functional comprehensive code as far as making the device transmit audio from the moment of pouring and continuing for ten seconds. This should be a quick and easy code alteration.

We have finally purchased a second monitor transmitter (Thank you Neil for driving out to Sumner), so we can now transmit and receive from two separate locations, changing channels through the direction we pour (180 per channel). With all of the coding and electronic components functioning, packaging is now our biggest challenge. Because there is so much exposed metal in the configuration we have, there is a large risk of shorting out the device if we just pile the chips on top of each other. Therefore we will need to find some plastic cushioning to protect our electronics.

We are still planning on housing our device in a squat cylindrical base attachment to our pitcher. We are now planning on using yellow foam rather than wood to construct this base, as per some recommendations we have received. Once we construct this, we will have to figure out how to safely nest our components and attach the base in an easily removable way.

Week 8: Building

Meleigha & Amber


Today we spent our time constructing a one panel mockup of our umbrella to test the required torque to pull in the arms and to test the overall soundness of our design.
First, we started with the center piece that holds all of the arms. Our first design was made of many pieces glued together (one for each arm) and we realized this was dumb. Why not just make one piece with 6 holes? 2 hours of work later this second idea took us very little time to construct and was much stronger.
Second, we cut the arms to length (23.5 inches) then attached Teflon floss (slippery!) from the center pole to the arms. We learned that the when the floss was attached to the pole making a straight line to the bent arm, the amount of force needed to pull the floss was less than if it were tied higher on the pole.Next, we created a template for the covering of the umbrella.Our next step is to finish the fabric covering and attach the sensors. We have begun to figure out the code to drive the motor but that will become our main focus soon.

This Week With Our Duino

Katie Suskin/Jon Lai




















We have recently made headway in our hardware exploration of sophisticated capacitive sensing systems involving aluminum tape, a 9V battery and cups from Parnassus. By applying the aluminum tape to precisely calculated positions on the cup... on opposite sides, a capacitive field can be generated that is capable of measuring the quantity of water in the cup. This is made possible with the CapSense library and a 1 mega ohm resistor. By utilizing a high level of resistance in the circuit, the capacitance and in turn the volume of water can be measured precisely.

In the following video you will observe the capabilities of our duino in measuring the quantity of water in a cup. An l.e.d. as been attached that has a brightness based on the measured quantity of water. The light increases and decreases in brightness as water is added and taken away respectively. Additionally you can see the rave response our duino received from its critics.

Arduino: Water Power from Katie Suskin on Vimeo.

Week 8

Amy & Amy


Our project has really started to come together this week. We have constructed our sensor and figured out how to solder a more refined version of our "expressive hoodie" with the LED's. 
We are now fusing around with the code, making decisions on what would be the best outcome for the pressure sensor. There are two routes we could go:


1) Be able to 'toggle' through different colors and fade in and out. 
2) Have the amount of pressure correlate to the color; for example, a light touch would be blue, whereas a medium amount of pressure would fade to green, and very high pressure would be red.


We are leaning towards the second outcome in this instance. Overall, a very productive week. 

Week 8: Inness & Neil

Everything with the code and electrical components is coming together this week. We have created two different codes, each comprising of half of the functionality of our design, and plan on combining them tomorrow. One controls the channel we receive based on a reading from a compass sensor- 120 degrees per each channel. The other initiates battery power to the receiver based on input from a tilt sensor. All of our electrical components have been compiles and are working. We have 2 battery packs, the Arduino board, a large breadboard, the computer chip from the receiver, a speaker and numerous wires and transistors. The configuration is currently pretty large and jumbled, but we've purchased a protoboard and a soldering iron and intend to consolidate considerably, which will both save space and provide clarity in the design.

In the realm of industrial design we have decided to create an enclosure to attach to the bottom of a premade glass pitcher. Neil purchased a carafe from Ikea, which is 8" tall (shorter than an average pitcher) and has a 5 1/2 " diameter - which is ideal for housing our components. Adding height to the pitcher won't make it appear strangely tall, and there is a lot of horizontal space inside so that adding the housing shouldn't create balance problems. We're planning on creating a cylindrical container our f wood that cn screw onto the bottom of the pitcher to allow the changing of dead batteries. We will also have to figure out how to create small holes in the base to allow sound to be audible.

Scott/Katie (Wk 7 repost)

Our week 7 posts somehow got deleted.

Here's our New Arduino Mega - More power and more pins!

Week 6 + 7

Mitch + Emily

We have been at a discouraging stand still with getting our 100K thermistor working. We have learned a lot in the process about all the different parts of thermistor codes we've sifted through and expect that with a new, different type of thermistor sensor our code will come together nicely with our new understanding of its components.

Therefore, we have decided to scrap it and order a new thermistor along with some other final parts. Our next step will be to meet and create our own tupperware with the UV sensitive paint we ordered. This will encase our Arduino as well in the end hold the UV lights that will activate the UV paint in the tupperware's plastic.

We're excited to start pulling everything together over the course of the next week! Updates + pictures to come soon.

Week 7

Amy & Amy


After getting most of the necessary materials, we realized we were still missing a few elements to properly prototype the pressure sensor. We tried an anti-static plastic called velostat and various materials that were quite unsuccessful.

Finally, in class our gracious classmates let us have the exact carbon foam that we needed to complete it. Credit goes out to Ben and Patrick for this key part in our project!


We also started to practice soldering and began to construct a sketch on how the breadboard would house the LED's (with proper wiring).

In the next week we will solder the LED's to the breadboard and connect them to the arduino. Since this project requires to be disconnected from our computer, we are going to solder together a battery clip to a battery adapter (that will have a mobile energy source).


We already know what will house all of these pieces, so we mocked up the basic construction of our "Expressive Hoodie".

Neil & Inness Week 7

This week we encountered a problem with compatibility regarding the hardware we were planning on using. Our intent was to combine a wii nunchuck accelerometer to sense tilt degree with a compass the sense direction, in order to initiate and select transmitter for receiving. Unfortunately both devices used the wire.h library, which depends on the analog input pins A2-A5. Looking into this library we couldn’t find any reference to these pins so that we could change them, and because we couldn’t have both devices using the same inputs, we’ve given up on using the nunchuck in favor or a more simple tilt sensor.
Due to the fact that we now have to wait for the tilt sensor to combine its functions with the compass, we decided to instead focus on writing the code for the compass, and ended up dividing the 360 degrees of the compass between channels A, B and C. Because we still only have one transmitter it can only work for one channel at a time, but the set up seems to be working.
An additional challenge we must address is the fact that when there is no signal being received by the receiver it makes an obnoxious beeping. This is a good feature for a baby monitor as the user needs to know if he or she is receiving data or not, but for us a pitcher that beeps when it isn’t transmitting would all but ruin the fun of our device. Therefore we need to use a transistor with a battery-operated power-source to turn off the receiver when it isn’t activated. We believe this coding should be relatively simple.
Our main focus going forward is building the pitcher. Our plan is to buy a clean, simple looking pitcher and attach a base in the bottom to house our hardware. This base will have to be weighted to keep the pitcher stable, and we will probably do some soldering to make our boards and wires as compact as possible.

Week 7

Meleigha and Amber


So after constructing our first pseudo prototype, we have discovered some major problem areas.

First of all, we need a very high torque motor to pull the strings that would ultimately retract the arms of the umbrella. To address this, we decided to change the material of the arms from steel to hdpe (high density polyethylene) plastic. HDPE is highly flexible so it will allow for a smaller gear motor.

Next, we wanted to change the way the arms bend. The problem currently is that the arms are made of a single flexible rod. The entire arm bends when the string is pulled which creates the "inelegant bulge." To fix this, we imagine having wooden/inflexible dowels for half of each arm with the new plastic attached to the dowel. This will make it so only the tips of each arm are flexible, and therefore creates a more gentle curve.

Our plan of action is to buy a new set of materials and play around with the assembly to improve upon our preliminary thoughts.

Along with an effort to reduce the amount of torque necessary to pull all of the strings, we are also researching the appropriate motor to drive our umbrella. In addition, we are trying to resolve how the motor drives the center ring that pulls the strings and releases them, and how this stays stationary on the shaft until moved by the motor.

Components

Functionality:

The system works similarly to a piston and cylinder. Instead of timing the up and down motion, the up and down motion occurs depending on the input that our sensor receives from the environment that it is in. As a specific object nears or backs away from the unit, the “piston” moves up or down accordingly.

Motors

Motion: up and down

Kind of Motor: Servo motor

Number of Motors needed: 1

Added Components:

-cylinder (3-4” in diameter)

-circular plate (3-4”in diameter)

-wheels/bearings

Sensors

Sensing: Proximity to unit

Kind of Sensor: Infrared Detector & Infrared Light

Number of Sensors needed: 1

Added Components:

-animal collar

Unit Build

Materials:

-Foam Core

-Thin Plastic

-PVC Piping

Let's Dance!

Ideation boards:

To dance or not to dance? That is the question.

Composing music is difficult on it's own, so how do you create an experience that is accessible and relatively easy to learn?

The answer: Scaffolding.

The Music

Choose a song and break it up into it's separate musical tracks. Drums, bass, guitar, sax, synth... whatever it may be. Assign an order of importance to the tracks. i.e., user number one will be assigned the rhythm, user number two, bass, etc.

The Experience

Press play.

A simple rhythm tracks starts to play (audible)

All of the other tracks start to play as well (inaudible)

One person starts to dance.

The main rhythm track increases to an audible volume.

All of the other tracks continue to play inaudibly.

A second person starts to dance.

The baseline kicks in.

All of the other tracks continue to play inaudibly

And so on, until the entire set of tracks is being heard... As long as you are dancing your track can be heard. And the harder you dance, the louder your track becomes.

The Code

Has the user pressed play? If yes, start all tracks w/ track 1 volume set to 100 and the rest set to 0.

Wait.

Are users dancing? If yes, how many? and in what order did they start to dance?

Assign the first user that dances to track two. Vary track two volume level between 50 and 100 based on the energy level of her dancing. If she stops dancing for more than 20 seconds, slowly fade the volume back to zero.

Assign the second user that dances to track three. Vary track three volume level between 50 and 100 based on the energy level of her dancing. If she stops dancing for more than 20 seconds, slowly fade the volume back to zero.

etc.

The Sensors

Time to experiment.

First with 3-Axis Accelerometers.

Then with Tilt sensors.

Ideas moving forward

Instead of playing all tracks at once, when a user hits play, what if the tracks started separately, as they would in the actual song? As if the dancer is indeed the musician, controlling when his instrument comes in? We would have to code such that tracks can only start at the beginning of a measure.

Happy Making !!!!!!!!!!!!!!!!

PB & A #4

Patrick, Ben, and Arduino: Sensor Actuator Schematic

At this point we've ordered the parts we need to actually build our interactive table top beer drinking enhancement device and are now patiently waiting for said parts to appear in the mail. Before we were able to do this though, we had to be completely sure about what parts we needed and how it should be assembled. So, we broke down the project into it's specific individual components and laid it all out:



We tried to make it as simple as possible -- essentially, a single station requires a demultiplexer, several LED's and the Arduino -- and that's it! For the level of complexity of the system we're going, it doesn't get much simpler than that. We expect to build our first working station some time in the next few days.

Week 6: Construction

Amy & Amy


This week we worked on our code and construction of our pressure sensor to our LED. After receiving the conductive fabric and alligator clips we were able to construct a pseudo version and more refined code for the actual construction of the project, which will be encased in fabric. 

 We were able to code and construct a working version with the conducting fabric and velostat, which served as an in between anti static fabric so the fabric would be able to stay out of contact when not pressed.
We talked a lot about the interaction between this sensor to the LED and what sort of situation it would be most beneficial while considering our original idea towards the deaf community. We found different sensor projects online and began getting more materials to begin a more refined prototype towards inserting an almost 'invisible' pressure sensor into a wearable garment. From here we'll start designing a finished workable project in context. 

\

Week 6: Prototyping

Meleigha & Amber

This week we worked on making our sensors and our pulling mechanism (figuring out how to make it contract). This involved a lot of experimentation and prototyping.
Last week, we talked about using "roach" sensors. These proved to be too delicate. Another problem was that each was it's own circuit. We decided a more elegant solution would be to have one circuit for the entire perimeter of the umbrella. When the edge of the umbrella is bumped, the circuit is completed and the umbrella will contract.
To make this "circuit" we put aluminum foil on two sheets of fabric spaced by felt. This is better demonstrated in the video and images below:

This is the general idea of how our umbrella will contract: (yes, I look very proud)

Inness and Neil R: Week 6 Construction

This week we've gotten into the mechanics of constructing our device. On Saturday we visited Metrix and used their soldering room to hook up elements of our switch to a bread board to enable control from an Arduino. We deconstructed the switch used to change frequencies on our baby monitor receiver and hooked its elements to a bread board in a way to enable us to change frequencies by moving a wire between the various pins. Our next step is to attach all the frequencies to the Arduino, so that we can control them with a program. We would then modify the program so that it would be initialized with a tilt sensor and change frequencies based on a serial reading from a compass. We are currently trying to configure our board using transistors to enable this type of control. Our biggest challenge once we figure this out will be to find other transmitters that use the same frequencies as the ones the monitor receives. We are envisioning either buying more Fisher-Price monitors or hacking a walkie-talkie to solve this problem.

PB & A #3

Patrick, Ben, and Arduino: What we've been writing

Now that we've established exactly what we want to do with our Arduino project, we've begun to put together a rough layout of how our code should look and work. It's definitely still leaning towards the side of pseudo code since we haven't been using all of the proper syntax and haven't decided which pins should connect to what and where, but we've been attempting to write in a way that will translate easily into an actual program when we start putting things together.

Here's what we've got so far:

http://patrickmcleandesign.com/arduino/pseudo_code2.html

It lays out exactly how we want our program to work, leaving room for any changes we may need to make down the line. Though it's changing almost everyday, the code is starting to look how it actually should. More to come soon!

Scott and Katie - Progress Video (Wk 5)

Here's a video of where we are. We have been able to hook up 4 buttons and made them control 4 different LEDs and make sound through 1 speaker. We're using a total of 9 pins so far. Our final artifact is going to have 24 buttons so we'll need a lot more pins..

Week 5: Sensor Experimentation

Amy & Amy

This week we began experimenting with various ways to control a multi colored LED. This will be the basis for our final prototype. 

Our first step was to figure out how to get the LED to display red, then blue, then green light. After successfully coding that, we tried to transition from one color to another and have all three colors fade simultaneously. Our third step was to hook up a potentiometer to allow for the changing of the brightness of the LED. We started with a dial potentiometer, which could be twisted to fade in or out the light. From there we coded a soft potentiometer in addition to the dial. Depending on the area and how much pressure was exerted on the soft potentiometer, the LED would vary in color and intensity of color while the dial still controlled the brightness.


Pseudo Code:



//this sketch was using a conductive fabric controlling the current when in contact


#define REDLED 9 
#define BLUELED 10 
#define GREENLED 11
#define POT1 A0  


int i = 0;      // We’ll use this to count up and down
int brt = 0;    // pot value


void setup() { 
  pinMode(REDLED, OUTPUT);        // tell Arduino LED is an output
  pinMode(BLUELED, OUTPUT);      // tell Arduino LED is an output
  pinMode(GREENLED, OUTPUT);   // tell Arduino LED is an output 
  pinMode(POT1, INPUT);                // tell Arduino LED is an output 
} 


void loop(){ 


    brt = analogRead(POT1);
    
    analogWrite(BLUELED, brt/5);      // set the LED brightness
    analogWrite(GREENLED, brt/5);      // set the LED brightness
}

Code + circuiting progress

Moving forward we have created some pseudo code as well as have started some real code. We determined that our device only has to be temperature based now which simplified our circuit substantially and the core of our processing will take place in the code. Here are a few pictures to show our circuit with our thermistor and light sensor connected:
















Here is the stage our real code is at as well:


// set device to turn on time if temp is above safe

//check if box was just closed
//ask for category

//# define BUTTON 6, defines which pin button input is in
# define THERM // 13, defines which pin thermistor is in
# define LIGHT // 9, defines which pin light sensor is in
# define LED 10 // placeholder to see if works

int temp = 0 // stores temperture read by thermistor
int val = 0 // stores light val from light sensor
int unsafe > 40 // sets unsafe temp to be greater than 40 degrees

void setup()
{
pinMode(THERM, INPUT); // sets the digital pin as input
pinMode(LED, OUTPUT); // LED will show detection
}

void loop()
{
temp = digitalRead(THERM); // read input value and store
unsafe = temp > 40 // not sure if this will work

if temp = unsafe + tcount = 1
{
timestamp = timet()
}

if temp = unsafe + count > 1
{
timeelaspe = timet - timestamp
}

else {
count = 0
time = time - timeelaspe
timeelaspe = 0
}

}


// void loop()
// {
// val = digitalRead(LIGHT); // read input value and store

// if val >







Finally, we decided that the actuator/affordance we are going to display is a mold pattern in photo-chromatic paint (sensitive when exposed to UV light). More to come!

Week 5: Pseudo Code and Sensor Decisions

Alana Robinson // Daniya Ulgen

On Monday April 25th, we narrowed down the functions of our teddy bear to a more singular interaction: storytelling. For the simplicity of our project, we'll put this storytelling experience in the context of night time, to encourage the process of falling asleep. 

Our first attempt at coding the interaction took inputs and outputs into account:

WAKE UP

Child jiggles or squeezes teddy (belly?) to turn it on

Light fades on

plays audio greeting

     asks  whether child wants to resume old story or start new one.

START STORY

starts story at full volume

     

     starts new story

     or 

     resumes old story from slightly before it faded out last time

     

INITIATE FADE SEQUENCE

initiates volume+light fade and timer (each sequence is 15 min broken into 3, 5min sections)

significant jiggling (passive or actively triggered) restarts volume+light fade timer & kicks volume up one level from current volume or down one level from initial volume) (3 defined levels + off)

(PASSIVE OFF)

ACTIVE OFF

squeeze to turn light and audio off

After writing up this sequence of events, we began narrowing down which types of sensors we would be using for this process. We realized we would need a way to store and play back audio. We decided on the Adafruit Wave Shield, for it's ability to read off of a sim card and adjust volume. We also need sensors in order to detect vibration or movement when the child wants to increase notify the device that they are still awake. For this we decided upon flexible jiggle sensors, with weights on the end to make the shake more noticeable.

Our second attempt at pseudo coding was more detailed and took into account sensors we might be using:

if bear is squeezed or vigorously jiggled

{

fade light on

play audio greeting 

}

if audio playback marker is >0 && <end of play back {

play intro question "We were in the middle of the story, squeeze (x) my hand (y) if you want a new story." 

if ____(x)_____ is squeezed(y) {

play intro 1 "here's a new story..."

start new playback

}else{

play intro  2 "this is where we left off..."

start playback at marker -3(?) minutes

} else{ 

play intro 2  "here's a new story..."

start new audio track

}

countdown starts

if teddy is jiggled { 

- x minutes  from the countdown restarts

}

if countdown timer is  at y 

        - audio slowly fades out 

We envision our teddy bear to tell a story with ample time for the kid to fall asleep. While story is told, lights will fade to encourage the process. If the kid is still awake, the kid notifies the device and the story will continue forth until the kid falls asleep.

Sensor Explorations

Jon Lai / Katie Suskin

Since our last post, we have decided to focus on the water drinking situation. We want to create a water bottle that can remind the average, busy person to drink water while they are sitting at work or at school. We explored several possibilities for sensors that we could use to measure the water level in a bottle. Initially, we wanted to build some sort of water flow sensor that would detect the amount of water that passed through the spout of the bottle. We were inspired by one of Teague’s explorations measuring water used from a tap. However, this seemed too complicated to apply to our water bottle scenario. Our other options were:

• An optical sensor that would work with water’s refractivity to measure the level visually
• Contact liquid sensor (less elegant, water eventually corrodes metal)
• Weight sensor to measure changes in amount of water (maybe not very accurate)
• Capacitive level sensing: strips of foil on either side of bottle measuring height of water

After some research, we discovered an instructable in which the author created a capacitive level sensor for liquids in a bottle and also hooked up a small LCD display to show the levels visually. We looked over his code and discovered that arduino.cc has a preexisting library that can turn two or more pins into a capacitive sensor. Instead of an LCD display, we plan on working with LEDs to alert the user when it is time for them to drink water again. Below is a pseudo code diagram of how we envision our system to work.

We experimented in class with the capacitive sensor code from the arduino website and had some exciting results. The original code just printed the different capacitance levels detected, but we added an LED that would turn on when it sensed certain levels of capacitance. We merely had to wave our hand over our sensor for the LED to turn on.

Our next task will be to measure water levels in a bottle with capacitive sensing.

Week 5: Sensor/Actuator Schematic

Amber and Meleigha:
Initially we were going to use infrared proximity sensors to sense when people or objects came near the perimeter of the umbrella.
The limitations of this were:
-Cost: $12 a sensor limited number of sensors we could afford
-Horizontal Range: The sensor was a single beam that did not sense in a radius making many sensors necessary in order to not have lots of blind spots.
-Size: Although fairly small, they were relatively large for an umbrella. Again, if we were to use many sensors, our umbrella would weigh a lot and sag.
Solution:
"roach sensors" which are a very basic type of switch. It can be home made with a coil of wire suspended around a central wire. When the center wire is bent (showing contact with an object), it hits the coiled wire and a circuit is completed.
We will be able to make lots of these cheaply and place them all around the outside of our umbrella.




Secondly, a motor is needed to pull the umbrella edges down. The first motor we ordered was awesomely small! But also oh so weak. We'll have to re-think this one: