Posts Tagged ‘pcom’

space

Tuesday, November 25th, 2008

In reaction to seeing my research on the cycling proximity project Jane sent me some really interesting information about Edward Hall and his work on Proxemics. I’m still reading up on the concept, but in brief it pertains to the study of space that individuals maintain in various social interactions and specifically how several cultures maintain different norms.

Here is an update to the proximity visualization application incorporating the 4 Proxemic distance classifications of Intimate, Personal, Social and Public. I’m hoping to show that while riding a bicycle in traffic riders experience frequent intrusions by vehicles into the Personal space. The haptic feedback device that is being devised for the CycleSense project will transpose the events in Social and Personal space to the Intimate space to provide an immediate awareness of these intrusions that generally go unseen as they occur behind the rider.

The next HUGE challenge is to refine the rangefinder sensor package, which I’ve never been able to get completely reliable.

data logging…mobile

Tuesday, November 11th, 2008

(this is an initial report for a longer post)

in conducting field research for the CycleSense bicycle proximity sensor i’m looking to gather data about actual proximity events while riding and to correlate these events with video documentation and personal annotation from the test subject…probably just me.

to that end, i’ve worked on rigging up a data logging solution for the sensor package. there was some information on using bluetooth enabled mobile phones as a storage device, communicating to a bluetooth module such the blueSMiRF attached to a microcontroller. in this case, an ultrasonic rangefinder is read by an Arduino which sends the range values through the blueSMiRF to a nokia phone. (more…)

Proximity and Attitude!

Thursday, October 9th, 2008

Adam, Karla and I are working together on our physical computing midterm. We’re looking to generate sound from the wearer’s environment and create some type of “musical” device that they can play. Some of the stimuli that we’ve figured could be measured are proximity of external objects to the wearer, their movement / motion (speed, direction, orientation, heading), ambient light, temperature, etc. Additionally we’re thinking of explicit interactions for the wearer including gesture, moving hands / fingers, walking, etc.

I’m primarily interested in sensing the environment. (more…)

skull control (via serial)

Wednesday, October 1st, 2008

Started up working with basic motor control, ended up hacking into an existing Halloween candy bowl talking skull.

(more…)

Reverse engineering…

Monday, September 22nd, 2008

So, Tom asked us to try to figure out how the circuit in the 24 switch pixel works. It’s an array of 24 physical switches arranged in three banks of eight switches which enable the user to control an RGB LED in a manner similar to 24-bit digital color.

He told us that the circuit was entirely analog without any microcontroller. We had worked with parallel switches so that implied a hint to me as to how the circuit was able to vary the current.

This exercise took me a long way, only to end up very close to the beginning.

So, I knew that the switches were designed to act like bits of binary data: (more…)

Observation of popular technology…nib.

Wednesday, September 17th, 2008

The first bit of our notes from our observation of folks using tech in Brooklyn. I’ll fill in the rest of the notes and a cleaned up version of our discussion.

(more…)

Sweaty palms…

Wednesday, September 17th, 2008

Next project…attempt to have more fun. Sort-of achieved. I spent more time conceptualizing, however this proved to be at the exense of my construction time. I’ll have to find a balance….

So, the task was to create a type of “Love-o-meter”…inspired by the sort of device you’d find at a boardwalk or shopping mall…

(more…)

Lab: Breadboards redeux

Friday, September 12th, 2008

Finally got some breadboards and set them up with power regulators and all.

Then got to make some simple circuits. Yay electricity! (more…)

Physical Computing: Digital In/Out

Saturday, September 6th, 2008

I’ve worked with the Arduino before, but still enjoy the wonderful moment when an LED blinks to life. I have a lot to learn about building circuits, proper wiring and clean / efficient code structure. A lot of what I do amounts to hacks to get a desired functionality. Of course, this builds complexity which breeds bugs and insecurity. Nevertheless, this is a learning process and I’m getting better with each attempt and iteration.

So, off to creating the switch. I routinely get confused with the proper wiring schematic for a pull-down switch. I keep messing it up; it’s incredibly frustrating that I can remember so much but trip up on such a basic circuit. I looked at the schematic, then wired it incorrectly; then looked at someone else’s and wired it incorrectly again. Finally I got it right, but the code didn’t upload successfully (despite the message to the contrary in the Arduino console) which led me to believe that I still didn’t wire it correctly and started over. Eventually, the firmware uploaded and the wiring was right so it worked.


Basic Switch with a pull-down resistor.


LED illuminated when switch is depressed.

Tom mentioned creating a combination lock…so I took up that challenge. Unfortunately, in hindsight after working through this first version of the project I realize that I ignored his first direction (paraphrased): “Start with the physical reactions rather than the technical details.” So, now I have a four button combination lock that looks like other, commercial devices; what’s unique or interesting about that?  How does that expand the human experience?

Regardless, I was able outline a problem and devise the hardware and software to achieve the functionality desired. Namely:
-Multiple buttons
-Arbitrary pattern (hard coded to four presses currently)
-Visual feedback for incorrect code attempt, but only after an entire code has been entered
-Visual feedback for successful unlock
-Relocking with any button press while in an unlocked state
-User entry of a new arbitrary code, but only if in a previously unlocked state
-Visual feedback for the New Code Set state.
-Timeout for partial code entry to return to the initial locked state.
-Packaged in a clean housing. (although the Arduino+prototype shield just BARELY fits in the housing. It’s a bit sloppy)

I don’t have a proper breadboard yet, so I did this work on the cramped prototype shield on my Arduino. This doesn’t have the common power and ground rails that larger breadboards have so it made wiring more difficult, and a bit messy. Eventually I got four surface mount switches on there and an LED to indicate the lock status.


Combination lock prototype.

After the initial rounds of code testing I felt ready to make a more presentable unit. First change was to swap the switches for something friendlier to touch.


New switches. The leads ended up too long and I had to trim them to fit inside the enclosure.

There was a perfect plastic enclosure on the junk shelf in the pcom lab, which resembled security alarm panels I encountered before. Some quick mockups with marker and a bit of Dremel work later I had the switches all ready to go. I also added an new, recessed switch on the back of the housing for entering a new code.


Arduino wired to the switches and unlock LED.

I added a second LED to indicate that the unit is ready to accept a new code. I need to rethink the experience here. The red LED flashes when an incorrect code is entered, and goes solid lit when the correct code is entered. If the unit is already unlocked (red LED is lit) and the reset code button is pressed, the green LED will also turn on (both are on). The next four button presses will become the new code. Pressing the reset button while already in a reset or locked state has no effect. I wonder if users will be confused that the red LED going solid indicates unlock, rather than green. Maybe red solid would indicate locked, green solid would be unlocked and both on would be a reset state. I could still flash the red LED to indicate an incorrect attempt. Hmm…

Here is the “finished” enclosure.

Combination lock v1.0

Arduino code below. I really need to clean it up. I compartmentalized many functions to avoid overlapping code, but my logic is a bit sloppy. I had many issues initially with multiple button presses and switch debouncing. I subsequently added serial output to aid in debugging.

UPDATE: I changed the code to illuminate the red LED when the device is locked, illuminate the green LED when it’s unlocked, and both when in a reset code state. The below code has been updated for this functionality.

#include <SoftwareSerial.h>

// Combination lock
// 3.9.2008 robert carlsen

// have a series of buttons
// press the buttons in the correct sequence - light the LED

// incorrect sequence will flash the LED once and reset, waiting for input

// enable the user to create their own sequence and store it
//*****//

// set up constants for the pinouts
int button0 = 2;
int button1 = 3;
int button2 = 4;
int button3 = 5;

int buttonSet = 6;

int ledUnlock = 11;
int ledLock = 12;

// need to only record once per press, not while it's held down
int firstPress = 1;

// remember the state of the lock
// 0 = locked, 1 = unlocked, 2 = set mode
int lockState = 0;

//timeout
long timeout = 5000;
long lasttime = 0;

//debounce
long debounce = 200;
long lastpress = 0;

// array will store the button sequence
// and set the initial code
// is there a way to store the code across reboots?
int code[4] = {
  button0,button1,button2,button3};

// store the users input
int entry[4];

// use a counter to track the progress of the combination entry
int counter = 0;

void setup(){
  // configure the buttons
  pinMode(button0, INPUT);
  pinMode(button1, INPUT);
  pinMode(button2, INPUT);
  pinMode(button3, INPUT);
  pinMode(buttonSet, INPUT);

  // configure the LEDs
  pinMode(ledUnlock, OUTPUT);
  pinMode(ledLock, OUTPUT);

  // for debugging
  Serial.begin(9600);

  //initially lock
  lock();
}

void loop() {
  int pressCount = 0;
  int pressedButton;

  int state0 = digitalRead(button0);
  int state1 = digitalRead(button1);
  int state2 = digitalRead(button2);
  int state3 = digitalRead(button3);

  if(state0 == HIGH && firstPress) {
    pressedButton = button0;
    pressCount++;
    lasttime = millis();

    Serial.print("button 0 pressed n");
  }
  if(state1 == HIGH && firstPress) {
    pressedButton = button1;
    pressCount++;
    lasttime = millis();
    Serial.print("button 1 pressed n");
  }
  if(state2 == HIGH && firstPress) {
    pressedButton = button2;
    pressCount++;
    lasttime = millis();
    Serial.print("button 2 pressed n");
  }
  if(state3 == HIGH && firstPress) {
    pressedButton = button3;
    pressCount++;
    lasttime = millis();
    Serial.print("button 3 pressed n");
  }

  if(digitalRead(buttonSet) == HIGH && lockState == 1){
    setNewCode();
  }

  // only allow one press at a time
  if(pressCount > 1){
    lock();
  } 

  else if(pressCount == 1 && firstPress == 1 && millis() - lastpress > debounce) {
    Serial.print("lockState: ");
    Serial.println(lockState);
    switch(lockState){
    case 0: // locked
      addPress(pressedButton);

      //if four presses have happened then we've rolled over by now
      if(counter >= 4) {
        boolean state = testUnlock();
        if(state){
          unlock();
        }
        else {
          lock();
        }
      }
      break;
    case 1: // unlocked
      lock();
      break;
    case 2: // set new code
      addPress(pressedButton);
      //if four presses have happened then we've rolled over by now
      if(counter >= 4) {
        lock();
      }
      break;
    }

    firstPress = 0;
    lastpress = millis();
  }

  // reset the firstPress variable one all the buttons have been released
  if(state0 == LOW && state1 == LOW && state2 == LOW && state3 == LOW){
    firstPress = 1;
  }

  // timeout if the code has only been partially entered
  if(millis() - lasttime > timeout && lockState == 0 && counter > 0){
    Serial.print("timeout: ");
    Serial.print(millis()-lasttime);
    Serial.println(" ms");
    lasttime = millis();

    lock();
  }

  //  delay(100);
}

void addPress(int currentPress) {
  Serial.print("counter: ");
  Serial.println(counter,DEC);
  if(lockState == 0) {
    entry[counter] = currentPress;
  }
  else {
    code[counter] = currentPress;
  }
  counter++; 

}

boolean testUnlock() {
  // compare the entry and code arrays
  for(int i=0;i<4;i++){
    if(code[i] != entry[i]){
      // only one mismatched entry will fail
      return 0;
    }
  }
  // if all have passed then the combination must be correct
  return 1;
}

void lock() {
  // turn off the unlock light (and flash the lock light
  digitalWrite(ledUnlock,LOW);
  blinkLed(ledLock);
  digitalWrite(ledLock, HIGH);

  lockState = 0;

  // clear the users input
  entry[4];

  // reset the counter
  counter = 0;

  Serial.print("locked n");
}

void unlock() {
  // turn on the unlock light, turn off the lock light
  digitalWrite(ledUnlock,HIGH);
  digitalWrite(ledLock, LOW);

  lockState = 1;

  // clear the user input
  entry[4];

  //reset the counter
  counter = 0;

  Serial.print("unlocked n");
}

void setNewCode() {
  Serial.println("Setting new code mode");

  // illuminate both lights
  digitalWrite(ledLock, HIGH);
  digitalWrite(ledUnlock, HIGH);
  lockState = 2;
}

void blinkLed(int led) {
  digitalWrite(led,LOW);
  delay(100);
  digitalWrite(led,HIGH);
  delay(200);
  digitalWrite(led,LOW);
}

Lab: Breadboards

Wednesday, September 3rd, 2008

First physical computing lab: working with breadboards. I have a prototyping shield on my arduino and am going to set that up for the first assignment. However, I should get a full size breadboard anyway for future projects.

Nevertheless, I’ll update this shortly with the actual breadboard work.