Lab 3 – Potentiometers

For the lab, I used two soldered potentiometers – used one for controlling brightness of LEDs and other for controlling the blink frequency.

Materials:

  • Jumper cables
  • Potentiometers (2)
  • Arduino
  • 3 LED’s
  • 3 Resistors
  • Breadboard

Code:

/*
* Serial RGB LED
* —————
* Serial commands control the brightness of R,G,B LEDs
*
* Command structure is “<colorCode(1)><colorCode(n)>”, where “colorCode” is
* one of “r”,”g”,or “b”.
* E.g. “rr” sets the red LED to 20% brightness.
* “gggg” sets the green LED to 40% brightness
* “bbb” sets the blue LED to 30% brightness
*
* Created 13 Sep 2016
*
*/

char serInString[100]; // array that will hold the different bytes of the string. 100=100characters;
// -> you must state how long the array will be else it won’t work properly
char colorCode;
int colorVal;

int redPin = 9; // Red LED, connected to digital pin 9
int greenPin = 10; // Green LED, connected to digital pin 10
int bluePin = 11; // Blue LED, connected to digital pin 11
int sensorPin_blink = A0; // Input pin for the potentiometer
int sensorPin_bright = A1;
int sensorValue_blink = 0;
int sensorValue_bright = 0;

void setup() {
pinMode(redPin, OUTPUT); // sets the pins as output
pinMode(greenPin, OUTPUT);
pinMode(bluePin, OUTPUT);
Serial.begin(9600);
analogWrite(redPin, 25);
analogWrite(greenPin, 25);
analogWrite(bluePin, 25);
//Serial.println(“enter color command (e.g. ‘r43’) :”);
}

void loop () {
//Serial.println(“in the loop”);
sensorValue_blink = analogRead(sensorPin_blink);
sensorValue_bright = analogRead(sensorPin_bright);
analogWrite(bluePin, sensorValue_bright/4);
analogWrite(redPin, sensorValue_bright/4);
analogWrite(greenPin, sensorValue_bright/4);
delay(sensorValue_blink);
analogWrite(bluePin, 0);
analogWrite(redPin, 0);
analogWrite(greenPin, 0);
delay(sensorValue_blink);

}

Video – https://drive.google.com/a/berkeley.edu/file/d/0ByHw8c_nutT2QVhqN0tOQ0piYms/view?usp=sharing

Lab 3 – Potentiometers

For the lab, I used two soldered potentiometers – used one for controlling brightness of LEDs and other for controlling the blink frequency.

Materials:

  • Jumper cables
  • Potentiometers (2)
  • Arduino
  • 3 LED’s
  • 3 Resistors
  • Breadboard

Code:

/*
* Serial RGB LED
* —————
* Serial commands control the brightness of R,G,B LEDs
*
* Command structure is “<colorCode(1)><colorCode(n)>”, where “colorCode” is
* one of “r”,”g”,or “b”.
* E.g. “rr” sets the red LED to 20% brightness.
* “gggg” sets the green LED to 40% brightness
* “bbb” sets the blue LED to 30% brightness
*
* Created 13 Sep 2016
*
*/

char serInString[100]; // array that will hold the different bytes of the string. 100=100characters;
// -> you must state how long the array will be else it won’t work properly
char colorCode;
int colorVal;

int redPin = 9; // Red LED, connected to digital pin 9
int greenPin = 10; // Green LED, connected to digital pin 10
int bluePin = 11; // Blue LED, connected to digital pin 11
int sensorPin_blink = A0; // Input pin for the potentiometer
int sensorPin_bright = A1;
int sensorValue_blink = 0;
int sensorValue_bright = 0;

void setup() {
pinMode(redPin, OUTPUT); // sets the pins as output
pinMode(greenPin, OUTPUT);
pinMode(bluePin, OUTPUT);
Serial.begin(9600);
analogWrite(redPin, 25);
analogWrite(greenPin, 25);
analogWrite(bluePin, 25);
//Serial.println(“enter color command (e.g. ‘r43’) :”);
}

void loop () {
//Serial.println(“in the loop”);
sensorValue_blink = analogRead(sensorPin_blink);
sensorValue_bright = analogRead(sensorPin_bright);
analogWrite(bluePin, sensorValue_bright/4);
analogWrite(redPin, sensorValue_bright/4);
analogWrite(greenPin, sensorValue_bright/4);
delay(sensorValue_blink);
analogWrite(bluePin, 0);
analogWrite(redPin, 0);
analogWrite(greenPin, 0);
delay(sensorValue_blink);

}

Pic – https://drive.google.com/a/berkeley.edu/file/d/0ByHw8c_nutT2ZURjSVdjeVFXV00/view?usp=sharing

Video – https://drive.google.com/a/berkeley.edu/file/d/0ByHw8c_nutT2QVhqN0tOQ0piYms/view?usp=sharing

 

 

Virtual Reality

I found Fishkin’s conceptualization and analysis of TUIs along the two dimensions of embodiment and metaphor to be useful frameworks to think about various TUI. However, I also felt that there were some fuzzy/grey areas wherein it wasn’t clear if a TUI is one or the other or overlaps/spreads across categories. I found the taxonomy to be interesting tool for analysis and organizing but not as useful for innovation.

The example that came to my mind was that of virtual reality. It’s hard to perfectly fit the interaction in the virtual world along the dimension of embodiment wherein the output to the user’s action is happening in the virtual world. Also, along the Metaphor dimension, I felt like VR technology doesn’t fit perfectly in any category (except for none). Similarly, as innovation makes way for new technology, these boundaries of fuzziness could increase.

So, while Fishkin’s taxonomy is a very useful tool for analysing and conceptualizing, I would consider keeping it in my toolset for that purpose and use it within the larger context of user needs and user interactions to help define the solution space of the particular problem that I am working on. 

 

Virtual Reality

I found Fishkin’s conceptualization and analysis of TUIs along the two dimensions of embodiment and metaphor to be useful frameworks to think about various TUI. However, I also felt that there were some fuzzy/grey areas wherein it wasn’t clear if a TUI is one or the other or overlaps/spreads across categories. I found the taxonomy to be interesting tool for analysis and organizing but not as useful for innovation.

The example that came to my mind was that of virtual reality. It’s hard to perfectly fit the interaction in the virtual world along the dimension of embodiment wherein the output to the user’s action is happening in the virtual world. Also, along the Metaphor dimension, I felt like VR technology doesn’t fit perfectly in any category (except for none). Similarly, as innovation makes way for new technology, these boundaries of fuzziness could increase.

So, while Fishkin’s taxonomy is a very useful tool for analysing and conceptualizing, I would consider keeping it in my toolset for that purpose and keep my mind open to user needs and user interactions to help define the solution space of the particular problem that I am working on. 

 

Go Bears !

Ever since I came to Berkeley and became a part of this beautiful campus and amazing community, I have been fascinated by the Campanile. With this lab, I have tried to recreate the lights part of the Light and Music Show at the Campanile.

It very exciting to think about how much diverse and cutting edge work is happening on these 1232 acres of land and yet at the end of every hour these bells unify us (our awareness)  across the diversity, thus strengthening the sense of community. Go Bears!

Components:

  • Arduino Uno
  • Breadboard
  • 3 LEDs (rgb)
  • 3 220Ω Resistors
  • jumper wires
  • USB cable
  • laptop

Code:

/*
* Serial RGB LED
* —————
* Serial commands control the brightness of R,G,B LEDs
*
* Command structure is “<colorCode(1)><colorCode(n)>”, where “colorCode” is
* one of “r”,”g”,or “b”.
* E.g. “rr” sets the red LED to 20% brightness.
* “gggg” sets the green LED to 40% brightness
* “bbb” sets the blue LED to 30% brightness
*
* Created 13 Sep 2016
*
*/

char serInString[100]; // array that will hold the different bytes of the string. 100=100characters;
// -> you must state how long the array will be else it won’t work properly
char colorCode;
int colorVal;

int redPin = 9; // Red LED, connected to digital pin 9
int greenPin = 10; // Green LED, connected to digital pin 10
int bluePin = 11; // Blue LED, connected to digital pin 11
int lenStr = 0;

void setup() {
pinMode(redPin, OUTPUT); // sets the pins as output
pinMode(greenPin, OUTPUT);
pinMode(bluePin, OUTPUT);
Serial.begin(9600);
analogWrite(redPin, 127); // set them all to mid brightness
analogWrite(greenPin, 127); // set them all to mid brightness
analogWrite(bluePin, 127); // set them all to mid brightness
Serial.println(“enter color command (e.g. ‘r43’) :”);
}

void loop () {
//Serial.println(“in the loop”);
// clear the string
memset(serInString, 0, 100);

//read the serial port and create a string out of what you read
readSerialString(serInString);
//Serial.println(serInString);
lenStr = strlen(serInString);
//Serial.println(lenStr);

colorCode = serInString[0];
if( colorCode == ‘r’ || colorCode == ‘g’ || colorCode == ‘b’ ) {
colorVal = int(lenStr * 10 * 2.55);
//Serial.println(colorVal);
Serial.print(“setting color “);
Serial.print(colorCode);
Serial.print(” to “);
Serial.print(colorVal);
Serial.println();
if(colorCode == ‘r’)
analogWrite(redPin, colorVal);
else if(colorCode == ‘g’)
analogWrite(greenPin, colorVal);
else if(colorCode == ‘b’)
analogWrite(bluePin, colorVal);
}

delay(100); // wait a bit, for serial data
}

//read a string from the serial and store it in an array
//you must supply the array variable
void readSerialString (char *strArray) {
int i = 0;
if(!Serial.available()) {
return;
}
while (Serial.available()) {
strArray[i] = Serial.read();
i++;
}
}

Musical Instrument and Drawing Apps

McCullough’s argument that “the computer is inherently a tool for the mind and not for the hands” resonates deeply with me and I have been reminded of it while encountering several UIs. Musical instrument apps and drawing apps are a few examples that come to mind immediately.

 

Upon trying to play music on a guitar app vs. the real guitar and keyboard app vs. real keyboard, I have experienced first hand that hands are differentiated and very closely connected to the mind. The mind and hand perceive guitar strings very differently from the screen interaction with the guitar app. Similarly, the mind and hand have a very different experience when a keyboard key is pressed on a real keyboard vs. on the app. As McCullough says, “ The knowledge is not only physical, but also experiential.”

 

A gutarist will tell you how losing a fingernail will make a difference, why they obsess so much over adjusting the strings till it is just right and they probably won’t be able to explain very well why a given pick is their favourite for outdoor performance and why another pick is their favourite for an indoor performance. It exemplifies McCullogh’s argument that “ The way of hands is personal, contextual, indescribable.” While the string adjustment is scientifically explainable, the fact that a particular pick feels just right to their hand is personal, contextual and very hard to explain or like McCullogh says ‘indescribable’.

 

A very similar argument is applicable to apps used for drawing. While they come very close in emulating strokes from different angles and pressure levels, the experience is very different from drawing on canvas. While the digital canvas can emulate the look of various canvas textures, the hand cannot feel the differences as it rests against the touch screen. Also, the drawing instrument (pen/pencil/brush etc) cannot experience the friction of different surfaces and the effect such differences are digitally created which is experientially quite different from how things work in the physical realm.

 

Blink and No Blink

Description

For this lab, I used 2 LEDs and wrote up my sketch such that one would blink and one would always be on.

Components

  • 1 Arduino
  • 2 LEDs
  • 1 Resistor (220Ω)
  • 1 Breadboard

Code

/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.

Most Arduinos have an on-board LED you can control. On the Uno and
Leonardo, it is attached to digital pin 13. If you’re unsure what
pin the on-board LED is connected to on your Arduino model, check
the documentation at http://www.arduino.cc

This example code is in the public domain.

modified 8 May 2014
by Scott Fitzgerald
*/
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 12 and 13 as an output.
pinMode(13, OUTPUT);
pinMode(12, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
digitalWrite(12, HIGH); // turn the LED on pin 12 on
digitalWrite(13, HIGH); // turn the LED on pin 13 on (HIGH is the voltage level)
delay(100); // wait for a second
digitalWrite(13, LOW); // turn the LED on pin 13 off by making the voltage LOW
delay(100); // wait for a second
}

Mazda CX5

A couple of years back, I upgraded from an old 2001 Mitsubishi Eclipse to a new 2014 Mazda CX5. The CX5 came with an inbuilt GPS on the dashboard. While this might not seem as a big deal today but having struggled with a slew of solutions to mount a portable GPS on the dashboard of the Eclipse, this was a great feature and a good example of the concept of ‘object-orientedeness’ as defined in the context of the Activity Theory. It took into account my (the subject’s) objective/goal of getting to a destination and aided that process by providing easily accessible navigation options.

Furthermore, it has a blind spot detection system which is comprised of an LED in the side mirrors that lights up if there is another vehicle on the blind spot and beeps if you are indicating to turn in that direction and there is potential collision hazard. While now I rely on this feature so much that I almost cannot drive another vehicle without this feature, this was not always the case. Coming from an Eclipse which did not have blind spot detection this was distracting, annoying and sometimes dangerous (due to the distraction). The CX5’s interface accommodates for the concept of internalization-externalization as defined in context of the Activity Theory by providing an option to turn it off – I would turn it on for sometime in the beginning (and then turn it off) till I got used to it and finally internalized it. Now I do not even need to turn my head to look at the led. My peripheral vision can account for the led and I am synced to the beep enough to rely on the whole blind spot detection system without having to expend any extra effort. The ability to turn it on and off helped me ease into it and internalize it.

Last but not the least, the CX5 takes into account my social context as defined in context of the Activity Theory. It provides a Bluetooth sync up for my phone which allows me to see the caller’s number for incoming calls and attend the call hands free. Unlike receiving a call while driving my Eclipse, wherein I had to take my eyes off the road to see who is calling and take my hands off the wheel to attend the call (in case I decided to), this was a much better experience of attending a call while driving.