Inness and Neil R: Week 5 Pseudo Code

We’ve been getting down to the nitty-gritty of how to build the components of our pitcher this week, and have found that the most essential part of our design is also the most complex. Our concept hinges on the ability to A) transmit audio wirelessly from microphones to a receiver and play at a high enough quality that words can be discerned, and B) have the receiver switch between different microphone channels. To solve for the first essential need of our design we’ve purchased a baby monitor from Goodwill. Because of the important function of a baby monitor this device has a high enough quality to suit our purposes. It also has four channels, so that theoretically we could set up microphones transmitting on each of those channels and have them all be picked up by the receiver portion of the monitor. It’s in the channel switching that things become complicated. The switch is a complex mechanical slide, so because we don’t want to build automated mechanical parts to move the switch, our plan is to break the switch and sodder each frequency to a different wire. Each wire would be linked to its own transistor, with their gates linked to arduino pins that would alternately be programmed with one HIGH and the others LOW depending on the pitcher’s orientation. However, before we more onto installing a compass our goal os to figure out this audio transmission portion of the device, and incorporate a tilt sensor to initiate a ten second audio feed.

After thinking through the approach we were going to take in building the audio transmitting pitcher, we conceptualized how our program might look. What we would need the code to do is set a variable based on the angle of the pitcher and then activate a predetermined receiving frequency. If a tilt sensor is activated, then we want to turn the volume or power to the receiver on, and allow it to play for 10 seconds before turning off, staying dormant for a minute afterwards.

pseudo code:

if liquid is greater than minimum threshold, turn on

find directional angle of pitcher based on degrees from directional sensor

if angle of pitcher is >=0 and <90

{

then match pitcher receiving frequency to frequency A

}

if angle of pitcher is >=90 and <180

{

then match pitcher receiving frequency to frequency B

}

if angle of pitcher is >=180 and <270

{

then match pitcher receiving frequency to frequency C

}

if angle of pitcher is >=270 and <360/ 0

{

then match pitcher receiving frequency to frequency D

}

if pitcher tilt sensor is activated

{

then activate pitcher walkie talkie receiver to on state, and play sound from corresponding frequency transmitter (A,B,C, or D)

delay for 10 seconds

end pitcher transmission

delay 1 minute

}

if liquid level is less than minimum threshold, turn off

Week 5

Katie Hendricks & Scott Lui

Current Plan:

We have currently designed our object to be a modular floor panel. The input sensors would be buttons. Shifting away from the DDR idea, we now plan to have the majority of the floor be stationary. There will be many small circular buttons spread evenly across the floor. The output will be light from the buttons and sound.

Materials:

We are in the process of ordering sensors and deciding what our best options are. Here are some of the questions we have been working through in regards to materials with our current resolutions:

-What is the best type of LED Light to create an obvious change from off to on? (Colored LEDs, with clear bulbs, and high mcd)

-What type of sensor should we use to indicate when someone has entered the elevator? (Infrared motion sensor to detect door movement)

-How to we store music in the arduino? (Sound shield)

Not Enough Pins:

The biggest issues we have discovered thus far is the limited number of pins on the arduino since we are attempting have all of our buttons act as unique, individual inputs. We found multiple solutions to this problem on the web. One was to create a grid of wires that would function as a coordinate system to trigger specific lights so less output pins would be required. A second solution would be to purchase a shift register to expand the arduino input pins. The diagram below shows how this connection works. Our last option is to purchase an arduino mega that has 54 digital pins.

PB & A #2

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

Prior to this class, Ben and I had had no experience whatsoever working with the Arduino open-source prototyping platform, however, we were more than excited to jump in and actually start learning how to build the interactive environments we were beginning to envision.

Fortunately, between the two of us, we have had a fair amount of experience writing code in various programming languages ranging from Java to PHP to ActionScript. And with a dash of electrical engineering education to add to that experience, getting acquainted with some of the more basic aspects of the Arduino programming environment and hardware has been a relatively easy and enjoyable process.

Just as the "Hello world!" statement is a standard for introductory programming courses, blinking an LED seems to be the first little introduction into the world of Arduino. Of course, being the hyper-active, humorous individuals that we are, we took this introductory project a few steps further and within a few minutes of learning how to set up this basic circuit and write the program, we had our own variation -- an extremely annoying, though amusing LED light show:

If you're interested in seeing it, the code is available here.

Taking this project a step further, and utilizing our basic understanding of the programming language as a whole, we put together a short light show controlled by a simple button, starting with an ordered succession of blinking lights, a randomized succession of blinking lights, and finally a series of fading LED's using the Arduino's inherent PWM outputs:

If you're interested in seeing it, the code is available here.

More recently, we began exploring different kinds of controllable input. In this example, we used a potentiometer to control the brightness of two LED's inversely; as one LED becomes brighter, the other decreases in brightness:

If you're interested in seeing it, the code is available here.

We've also started looking into different kinds of sensors in the hopes of finding the appropriate hardware for our final project. This past weekend, the nice folks at Metrix introduced us to a series of pressure sensors that could be used to measure the amount of liquid in a container based on weight. The first was a low cost, home made pressure gauge:

The second option was a pre-fabricated pressure sensor costing around $9:

With these sensors in mind, our vision for the perfect Arduino enhanced social beer drinking experience is one step closer to becoming a reality!

As usual, more pictures and videos of the fun stuff we're doing to come...

Team Tupperware:Week 4

Emily +Mitch

Now that we have a direction we still have a few questions we needed to hash out. We started answering what we are detecting, mold.

How can you see if something has gone bad, sight, smell, taste, chemical reactions. This seemed to complex and difficult to analyse in one quarter. Maybe a two year research grant and a fully stocked lab could handle that. So we needed to a novel and simple solution to suggest to the user that food had spoiled. We ask ourselves what makes food spoil. Being over 40 degrees for 4 hours. If kept under 40 most food is good for 4 days. With these parameter we decided on a novel solution to manage food spoilage. Time, Type, and Temperature by tracking these we are able to suggest fairly accurately a safe time to eat food stored in tupperware.

This week was really about how and with what we will using to detect these things.

We identified our 3 variables that needed to be addressed.

Time

Luckily the arduino has a built in crystal and we can track the vibrations for that. Since we are only timing for a relative time, its accuracy doesn't need to me militarily accurate. It seems like for this just some nice coding will do the trick.

Temperature

When the food item gets too warm we need to decrease the amount left of the timer. On the market there are plenty of temperature and humidity sensors but the easiest way to achieve what we need is through a thermistor. It tracks the resistance caused by the change in temperature in the resistor and coverts that value to a temperature. Once again a fairly easy sensor with a chunk of coding to pull it all together.

Ambient Light

The last main component we want to track is the ambient light. there is no need to display data if the tupperware is in the fridge an out of sight. For this, on the market are a variety of cheap

light sensors and simple code that we can use.

Now its time to dive into some coding and see if we cant pull it all together.

PB & A #1

Patrick, Ben, and Arduino: What we've been up to

Here's a quick recap of how our project has been evolving.



Social Beer Drinking

We've been designing around the situation of social beer drinking--partially because it's a situation that we're both quite familiar with, but also because it's a situation that's teeming with interesting interactions that are just begging to be messed with.

First we brainstormed around the items involved with social beer drinking:

• Glasses
• Pitchers
• Stools
• Chairs
• Tables
• Coasters
• etc.

Then we focused in on the vessel itself--all of the information that can be gathered and what that could say about what is happening between the drinkers, each other, and their drinks. The beer-cology started to take shape. Some things we looked into:

• Temperature
• Head
• Drinker/Owner
• Act of Pouring
• Amount of Beer
• Proximity to Pitcher
• Proximity to Drinker/Owner
• Beer "Identity"
• Viscosity

We started to get a feel for the situation and some of the possible effects of learning from these variables. Still, we weren't sure how to manifest potential feedback in a way that would affect the social situation in a really interesting (and maybe fun) way.

Back to the drawing board.

Instead of wrapping our heads around the pint glass and working outwards from the object, we attempted to get a fresh look by zooming out and examining the situation as a whole, once more. As we examined closely some of the other objects present in the situation, one seemed to stand out against the rest.

The table is always there, doesn't belong to any one person, and acts as the intermediary between the drinkers and their drinks--providing the surface necessary for these things to come together. Conveniently enough, it's also able to contain all of the sensing, processing, and actuating equipment we need to use. It is also positioned in such a way that would make it easy to interact with in a tactile, visual, and even aural way.



So a Supertable? What does it do?

Our device intends to measure one variable (to start with): Amount of beer.

It measures the amount of beer in the pitcher and in each member's glass by providing affordances that indicate where the glasses and communal pitcher should be placed (these areas contain sensors that can gather this information).

By reading this information, we intend to inform the user of a few things:

• How many beers have been consumed by each member
• How "drunk" that member might be (ballpark estimated by time vs amount)
• How much money they need to contribute to the group for the communal beer
• Who has had the most, who has had the least

We've also considered the concept of having the table decide who's next in line to buy a pitcher (randomly selecting a member of the group, and eliminating them from being chosen in the next random selection).

By working in this space, we're not trying to solve an existing problem--just make one of the solutions to life's problems a little more interesting. A hat-tip to Neil and Inness for presenting during class the situation that gave us the initial kick in the right direction.


Pictures, Fun Arduino experiments and more to come...

Week 4: Sensors

Amy & Amy

We decided to pursue a route in an opposite fashion from what our original thoughts were from the last week: Why try to make the deaf conform to a hearing world?--Let's utilize the unique way the world can be experienced without sound. So, we started off this week by looking at projects already out there and what was possible if we were to take on similar projects.

Our input was focused on pressure and movement and we found a project called "Joy Slippers" that used analog pressure sensors that coordinated output to left/right/up/down sketches onto a computer.

We also started looking into malleable shapes, soft circuits and fabrics where we had a few ideas. Since our idea was inspired by the deaf culture, we decided to look into pressure sensors embedded into neoprene gloves where expression could be explored through hand gestures and movements.

As far as output, we focused on both tactile and visual stimuli. We agreed that lights (LEDS) could be an exciting route to go, especially since there is room for creativity and we could include both color and position for expression. We imagined a board with lights in a grid formation and the gloves would be connected to it, allowing the user to interact with it. (one idea)

For a second layer of the project, if possible, we would venture in the route of connecting another tactile element that was more expressive tactile approach than the light direction. 

Materials that are vital:

- LEDs--multiplexed single LEDs (depending on price and ability for color choice, could use cheaper xmas lights/ bulk strands)

- position or proximity sensors (reed)

- neoprene fabric for gloves and covering exposed parts

- analog pressure sensors

- connection wire from gloves to connection into LEDs (telephone wire would be inexpensive)

- some sort of sturdy casing for lights

The blinking/fading is only the beginning for us...

Week 4

Katie Hendricks & Scott Lui // Super [Mario] Elevator

Sensor Possibilities

The most important input that our object has to be able to sense is the location of a person in the elevator. We have discussed a variety of options that we think could be possible and are still researching to decide which will be the best (easiest to implement and most cost efficient.)

1. Pressure Sensors

An obvious way of detecting a person’s location is by the pressure they are exerting on the ground. This would produce an analog output, which would work but is not necessary for our project.

2. Physical Buttons

One existing system that shares similar characteristics to our project is DDR. The game needs to be able to identify where are on the game board the player is stepping. We found one example of a DYI arcade style ddr mat that turned each tile into a physical button that completed a circuit when pressed. This would produce a digital output if pressed or not pressed, which if fine for what we are trying to create.

3. Infrared photo sensors

Infrared photo sensors are another possibility we have considered. Just as a computer mouse can determine if it is being held in the air or on the table, we think the same concept could be applied to detecting a person’s location. If a person were standing over the infrared LED the infrared sensor would detect their presence. This would also create a digital output.