Premise:

Have you ever been on a date and the other person begins to be… a little too handsy?

Well say no more, because the “Can’t Touch This Sweater” is the perfect product for you.

Not only will you know that your date is being rude because of their hands, but the flashing red light will show other people that your date is being a bit too handsy.

What do I mean? How does this product work?

The product comes in an adorable black colored sweater, with a cute traffic light on it.

Ok ok, so now you know how it looks, but what exactly does this thing do?

Well, the sweater is at a constant green light as such:

 

 

 

 

 

 

 

 

And in the circuit, there is a soft potentiometer. This is the analog input source.

This potentiometer is meant to be around the chest area of the woman.  (Sadly, this was not possible to do on my model due to technical problems.)

Therefore, when there is no contact on the chest area (ie, the soft potentiometer) the light is green. This means everything is ok.

On the outskirts of the soft potentiometer, if there is a pressure, it will still be green. BUT THIS IS ONLY FOR A VERY SMALL SECTION OF THE POTENTIOMETER. 

When the person’s hand begins to come too close to the soft potentiometer area, the light will turn yellow as so. (This area means it is approaching a place it shouldn’t be, but is not quite there yet.)

 

 

 

 

 

 

 

 

And then finally, when the person’s hand is about to reach the chest zone, the light turns red. This indicates that their hand has gone too far and they need to BACK OFF. (Unless consent is given; then by all means continue.)

 

 

And so, here is a video demonstration.

How I made it:

From there, came the physical sweater part.

INSERT IMAGE

In my circuit, there is a soft potentiometer and an RGB LED.

Here is the website that helped me set it up.

https://learn.sparkfun.com/tutorials/sik-experiment-guide-for-arduino—v32/experiment-10-reading-a-soft-potentiometer

As for the code, the soft potentiometer works in a range of 0-1023. Taking this, I divided the strip into approx:

green —> 20% of the strip

yellow —> 50% of the strip (yellow in an RGB LED is done by activating both the RED and GREEN)

red —>  30% of the strip

(in this order.)

Here is my code:

*The sweater will not soon be in stores. It was inspired by light-up Christmas sweaters. The next model will have a switch to turn off the green light.*

1) I wanted the LED to light up when the brightness was low and vice versa using the LDR. I had multiple ideas of how to build the circuit, but every-time I tried executing my idea I struggled with actually getting the plan to be successful. One thing I could do better next time is to actually sketch out my idea using diagrams. I looked at an Arduino tutorial to help clarify how I should set the circuit: https://www.youtube.com/watch?v=4fN1aJMH9mM. However, I wired it in a different manner that was more familiar to me.

2) I wanted to take one step further and work on fading the lights in and out instead of the lights abruptly changing every time it was dark and bright. I wanted the LED to vary in brightness depending on how dark the setting was. I implemented the code as seen below, however that only contributed to the dimming of the LED. I did not achieve the results I desired.

3) I learnt that the problem arose from the fact that the ledPin was at 7, which was not an analog output (PWM). Only when I switched it to a PWM would the LED fade. Adham helped me write my code more efficiently (ex. adding a map function instead of doing the analogRead under the loop function in the Example #2). However, even after writing the code efficiently and switching the ledPin two its proper location, the LED would brighten very subtly when it was dark. The change almost appeared non-existent. Only after switching around the values in the map function (by looking at the highest and lowest values from the serial monitor) was I able to see a difference in the fading of the light.

I thought about what ‘unexpected’ was supposed to entail for a long time. I was thinking about what could be ‘unexpected’ from an LED and all I thought about was it not blinking. After much contemplation, I began to think about using a photosensor. My first inspiration was glasses that would shine a light when it was dark, for no reason. But then I began to think of when glasses/goggles would be used along with light. My first thought was of mine workers. Soon my mind (unfortunately) drifted towards morbid thoughts, like how some mine workers would be stuck in the dark if the mine caved in. Considering the recent news, I also thought about the earthquake in Taiwan that trapped several people in rubble.

Soon enough, I decided to make a photosensitive light that would morse code H-E-L-P when the surroundings are dark. I made it in hopes of allowing victims to be more easily found, as people cannot scream for help for a long time.

I set up the RedBoard ‘normally’:

I then looked online on how to morse code H-E-L-P:

H = dot, dot dot, dot , E = dot , L = dot, dash, dot, dot , P = dot, dash, dash, dot

With some help, I was able to code the following (sorry for the bad quality, will learn how to use the website for next time):

This is the video of it working:

When Aaron was talking about some example projects that could be made to fit this week’s assignment task, I was very puzzled. I kept trying to think of ideas that are original and creative at the same time. I wracked my brain and couldn’t think of anything. I resorted to talking to one of my close friends about not being able to think of any ideas and her reply to my frustration was to “do something that you know how to do best”. Therefore, this project contains some elements that I know how to do well – no, unlike the what the title suggests, I am not a thief. I, on the other hand, know how to annoy my friends.

I, therefore, wanted to make something that could potentially annoy others (what better way than to do that with noise, am I right?) and have a practical use. Thinking of what I could do with a buzzer and an LED, I thought of making something that would surround an object so that when (let’s say that you have a cat) your cat tries to steal your box of cereal, for example, the shadow of the cat, when close enough, will cause the buzzer to sound and the lights to turn on.

The midway process video is shown below, where I first coded so that the darker the surroundings, the brighter the LED would get. I couldn’t figure out how to make the initial no-shadow/darkness situation be that so the LED was turned off. It was only after that I realised an extra section of calibration was required – which I implemented into the code (link below).

I originally wanted to put the Arduino and breadboard into a box so that it looks more “discrete” in practical terms and so made this box. I didn’t end up using it though because I couldn’t manage to control the LED light levels (even with calibration) and make it stay off initially and only turn on when a shadow “approaches” the object. I realise now that I’m writing this that I could put the photoresistor on the outside of the box so that it sticks out like I originally wanted the LED to do. Nevertheless, I didn’t end up using the box. I guess one good thing about not using the box is that I got to see my code work “properly” in the sense that originally, it was quite hard to see the changes in the brightness of the LED. Putting it in a box would’ve made it even harder to notice the changes due to the initial brightness being low already. I was able to see that my code was working properly.

After the process shown in the video above, I connected the buzzer to the circuit and wrote code that basically said that if the LED was at the brightest, the buzzer would sound on. Meaning that when the cat/person was closest to the object (in this case, the board) the lights would turn on and the buzzer sound on. I thought that this could potentially be a way for the cat to be scared away.

The link to the code that I have used is shared here: https://gist.github.com/hyl392/89a6ec6ec6048540b7b143b29a2ef3ae

The video of the final product is here:

I didn’t realise how sensitive the photoresistor would be. I ended up having so much fun with my assignment that I’m sure I disturbed the whole lab with my annoying buzzer noise. But hey, like I mentioned before, annoying people is what I know how to do.

Quick sorry to everyone who was in the lab while I was playing around with the code and then further messing and fooling around with shadow!

Improvements:

• Use more LEDs so that there is more scare effect
• Blinking LEDs so that it looks more like an alarm?
• Change the buzzer into a speaker and play some really annoying alarm sounds that would annoy all humans and animals
• Make the whole thief preventer more discrete so that the thief would not expect an alarm to sound and lights to light up – i.e. incorporate the box into the project and make it a lot more practical (though the USB would still need to be plugged into my computer so I’m not sure how it’ll work).

People never really know if their fever is bad enough to get them out of bed and go see a doctor. This often causes them to miss the optimum diagnosis and recovery window. But don’t fear just yet! Introducing the all new revolutionary therMOMeter 2000! This intelligent device will take your temperature in a matter of seconds and remind you that you need to go see a doctor right away with an alarming red light — just like how a mom would!

The hue alternates between blue (you’re cold), green (you’re fine), and red (you have a fever).

Here is a simple demonstration of the TherMOMeter in action:

Before settling on the TherMOMeter, I experimented with many different sensors including the pressure sensor, the photoreceptor, and the sound sensor. I ultimately opted for the temperature sensor because it was very responsive and adorably compact. The sparkfun website offered a lot of insight in terms of how to properly install the sensor onto the circuit board. Installing the sensor backwards (incorrectly) actually caused it to heat up!

A screenshot of the code I used is attached below:

At the beginning, I was unsure of how to do something ‘unexpected’ with some lights (disclaimer: I still don’t think this is unexpected enough but oh well). As I was crossing the road the other day, I noticed that people kept pressing that little button that was supposed to make the waiting time at the pedestrian crossing faster. I wondered if that actually had any effect on the time difference of the blinking of the traffic light.

I decided to try to create a circuit where, using a pentameter, could control the speed of the blinking of the traffic light. I began by setting up my circuit on the board.

I had my pentameter as an input at A0, my red light attached to the digital output 13, the yellow light at digital output 11, and the green light at digital output 9.

I struggled a little bit with the coding so I went back to the codes we did last class and watched the videos on Analog Input and Analog Output to try and comprehend how it could be done. I don’t think my code ended up being the most simple, but I tried to make it clear enough that I could understand each step, even though I’m sure that there are several extra parts that could be eliminated.  My final code ended up looking like this:

In the end, this is how the circuit worked when plugged in with the code:

I think it would be really interesting to figure out much the ratio is between blinking lights at the traffic lights, and how to program the differences in the blinking of the lights.

The way Norman discussed deficiencies in human-machine interaction was fascinating. I believed that the lack of understanding of principles necessary for effective human-machine interaction was the fault of the person on the other end who was using the machine. I always believed that the lack of understanding resulted from the lack of education on technological use. Norman explained how deficiency in human-machine interaction occurs because the design is done by engineers, who are experts in technology but limited in their understanding of people. This seemed so blindly obvious but I could not grasp why I hadn’t thought of this earlier. Engineers tend to think they understand people because they are people themselves, however those who have studied human behaviour understand how amazingly complex it is. It was intriguing to read that difficulties in effective human-machine interaction was caused the technology and not the people. It was also interesting to read the paradox of technology towards the end, the same technology that simplifies life also complicates life by making the device harder to learn and use. It made me realise that good design is not solely limited to the understanding of technology, it goes beyond that, to the understanding of psychology.

Our eyes are unreliable. If you’re anything like me, you’re always frustrated at how our eyes don’t measure brightness linearly. No? Just Me? Sunlight is on average 20 times as bright as indoor lighting and we definitely don’t notice that much of a difference. Anyways, moving on, I wanted to make something that will measure the brightness and give an easy visual indicator to the brightness level currently in the room (and won’t lie to us like our eyes do). So I did this:

The values read from the Light Dependent Resistor are from 0-1024, so what I did is divide the reading by a 100, and store that number in an int variable. What this did is that it extracted the most significant (leftmost) digit of the reading ex: extracts the 7 out of 721. Then, in a for loop, I would set the pins from 0 to the extracted number to high, which resulted in what was shown in the video.

code:

int beginPin = 2;
int endPin = 11;
int sensorPin = A0;

void setup() {
  // put your setup code here, to run once:
  // for loop to set all the pins to output so I don't have to do it manually
    for (int i = beginPin; i <= endPin; i++) {
      pinMode(i, OUTPUT);
    }
    Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
   int sensorReading = analogRead(sensorPin);
   // extracts the leftmost digit of a 3 digit number
   int leds = sensorReading/100;
   Serial.print(sensorReading);
   Serial.print("||");
   Serial.println(leds);
   // for loop to turn off all the leds before setting the relevant ones to high
   for (int i = beginPin; i <= endPin; i++){
    digitalWrite(i,LOW);
   }
   for (int i = beginPin; i < (beginPin+leds); i++){
    digitalWrite(i, HIGH);
   }
}

Oh also as an added bonus, it can also display the brightness as an 8-bit binary number (0-255)

code for the binary display:

int beginPin = 2;
int endPin = 11;
int sensorPin = A0;

void setup() {
  // put your setup code here, to run once:
  for (int i = beginPin; i <= endPin; i++) {
    pinMode(i, OUTPUT);
  }
  Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
  int sensorReading = analogRead(sensorPin);
  byte x = map(sensorReading, 0, 1024, 0, 255);
  Serial.print(x);
  Serial.print(" : ");
  for (int i = 0; i < 8; i++) {
    digitalWrite(i + beginPin, bitRead(x, i));
    Serial.print(bitRead(x, i));
  }
  Serial.println();
}

keep in mind that on the serial monitor this will print the binary number in reverse.

In this article, Norman emphasizes that how aesthetics can improve user experience after some people criticize Norman for overlooking the values of aesthetics in design.

I never see the usability and aesthetics at odds. They are both contributing to the overall user experience. After all, it is up to the users to decide whether a design is good or bad.  A beautiful car that is broken may be useless, but an ugly car that is functioning may also be very frustrating to the driver. However, the focus should really depends on what kind of product we are talking about. A designer should concern too much about the colour of the drop-down oxygen face mask on airplanes as long as they flow oxygen properly when deployed. However, when it is possible, when do we try to make our product both functionally sound and aesthetically pleasing?

The glass door with no markings that indicate where to push, the sliding door that could be a push door or a pull door, the sink that is impossible to empty… all of those spectacular design failures are common objects in our daily lives. The awkward interactions and experience with this kind of objects are too familiar to me. I do not have to leave my dorm to find examples. Every student dorm on campus has a drawer with three drawer boxes. On my move-in day, two of my roommates and I spent almost an hour trying to figure out how to open one of the drawer boxes until we broke it by trying to force open it. It took me an entire semester until someone told me the secret:  “you have to have all drawers completely shut before you open any drawer”. I sometimes use it as a joke to mock how “stupid” I can be sometimes. However, I completely agree with the author’s view here: if only “smart” people can figure out how to work something but not the majority “stupid” people, then the design of that thing is at fault, not the people. It is the duty of machines and those who design them to understand people. It is not our duty to understand the arbitrary, meaningless dictates of machines. Designers need to focus on the experience of people who are completely clueless rather than people who had experience interacting with similar mechanisms before.