Thursday, 15 March 2012

Adding sound via transistors and relays

Continuing on from the mp3 player hack, two wires have been soldered onto the circuit board and tested. The mp3 player plays when these wires are crossed.



The next step was to test out transistor functionality. This was done by first building a spin motor as per the example in the oomlaut.com arduino tutorial here.


The circuit was built successfully so the next step was to incorporate the mp3 player. Below is an image of it wired up.



This circuit played the mp3 player, but it wasn't turning on and off: was just staying on. I noticed that there was a short circuit where the diode was and this was why it wasnt turning off. This meant that the current can run through the diode without going through the transistor. I wondered if switching the wires would solve the problem. However, it didnt and instead the mp3 player doesn't turn on at all.

I am going to try a relay circuit instead which is an electronically controlled mechanical switch. I am going to be using this example from oomlaut.com.

I wired up the relay circuit and attached a motor in place of the LED's. There is a physical 'clicking' sound when it switches on and off. Before i attempted to insert the mp3 player into the circuit i pulled the xBee out due to its voltage sensitivity.

Below is an image of a test relay circuit with a motor.

The circuit works and successfully turns the mp3 player on an off but there is a lot of interference. This is because the mp3 players power circuit is not electronically independant from thearduino power circuit. The example in the book connects the motor (substituted for an mp3 player) to the common ground with the relay and the rest of the circuit. There is no example which is electronically independant.



Below is a video of the mp3 player powered by the relay.




The circuit here http://www.glacialwanderer.com/hobbyrobotics/?p=9 shows how relays can be used to control a lamp with its own power source. The motor must be given its own seperate power source and run independantly. After a few attempts i cant get this working without the relay stopping working however. It should work, but it just doesnt! This will be worked with.

Unfortunately the 3.3V flowing through the mp3 player has interfered with the chip and now it overheats massively when turned on even by the built-in switch. The mp3 player makes an uncomfortable squeaking sound when turned on via the circuit which probably has something to do with the power conflict. The light turns on and static can be heard so this is an unusual problem. The blue light from the board is also blown. This is strange because the mp3 player was working when it was plugged out of the circuit, and it didnt suddenly stop working. http://electronics.stackexchange.com/questions/13873/why-exactly-do-chips-start-malfunctioning-once-they-overheat suggests that this might be overcome by allowing it to cool down, but this hasnt worked so far. I believe that the voltage leaked into the device has interfered with the battery itself. it might be solved by charging so this will be tried. A new mp3 player has been ordered and will not be incorporated into the circuit until it is worked out how to safely isolate it electronically.

Seeing what the relay did to the cheap mp3 players chip, it was probably just as well that i removed the xBee board which has a very sensitive chip on it. Whilst waiting for the new identical mp3 player to arrive, i will continue to find a way for either a relay or a transistor to switch on and off an electronically isolated circuit.

I did a quick test of the microsd card to check that it too wasnt fried, and luckily it wasn't. I did this by plugging it into my computer and seeing if it still functioned correctly.

This could be solved by possibly having a common power source as the arduino board.

Note: i just noticed that one of the wires on the speakers has broken off. This could be the source of all of the problems, and the reason why it just suddenly stopped working. I wont cancel the second mp3 player as it is always useful to have a backup, but this could quite easily be fixed.

The code for the relay is simply the turning on and off of one of the digital pins.
in setup
  pinMode(mp3, OUTPUT);

in loop

 digitalWrite(mp3, HIGH);
  delay(2500);
    digitalWrite(mp3, LOW);
  delay(1000);

The code was tweaked to allow it to play for longer and shorter periods of time.

Tuesday, 13 March 2012

Week 22 Log

Week beginning 05/03/2012

This week has been focused mainly on technology development and prototyping. The xBee radios were reconfigured for two way communication as previously there was only one-way communication. The error was researched and discovered to be a configuration problem with the destination address on one of the radios; it was addressed to itself and was sending serial information to itself rather than its partner radio.
Once this was fixed the first teddy bear prototype was built. A teddy bear was purchased and carefully opened up at the back to allow wiring to be placed inside. This first prototype was only implemented into one prototype instead of two due to the lack of supplies: new soldering tips and jump wires were required to extend the components to fit in the right places. However, the prototype was successful and illustrated two way communication of presence. The next step will be to communicate memories i.e. stories.
To do this i.e. incorporate sound, an mp3 player has been hacked. This was the preferred option to using a purpose built arduino sound board which would take up precious pins and was also far more expensive. The mp3 hack is at the functional stage: it works but needs to be incorporated into the arduino environment using a transistor.

‘Survey Research’ by Robert Sapsford, and ‘Qualitative Interview Interviewing’ by Tom Wengraf are being read alongside this development in preparation for user testing. User testing techniques from the User Interface Design course will be incorporated.

A website could be developed for the prototype as well as an accompanying storybook to do walkthroughs with the prototype with users.

Goals for next week: finish the prototype, start user testing, contact design companies and create a short advert for the prototype.

MP3 Player Hack

The MP3 player and SD mini card arrived a few days ago. I loaded a couple of tracks onto the card and tested it inside the player. It played very loudly and clearly. Choosing a player with integrated speakers was a conscious decision made because i felt that it would create the idea of being 'spoken to' more vivdly. This, of course, will be tested with users.


(official pic)

Once I knew that everything was working correctly I could then start the hack. The first thing to do was open the player up, which was done with a mini screwdriver.


The board was screwed down so it had to be unscrewed and lifted up.



Having a look at the insides i then focused on the on/off switch. There were two settings: on, and on with the light on. The music played immediately with both. The switch was more advanced than i originally thought, but looking at the soldering i knew that one pair of the 10 pins when connected would ovverride the switch. This was a case of trial and error. I used a short jumper cable to methodically move across the pins. I eventually found the 'on' switch and music started playing. I used the indicator light to identify which was correct and i could hear static before i started playing.

The video below shows the mp3 player working with the crossed wires.


What next?

The wires will be soldered down and connected to the arduino via a transistor. This transistor will allow me to open and close the connection via the arduino, and will eventually be able to be done remotely through the teddy bear prototype. This means that a remote user will be able to play sound to another user. 

Why incorporate sound this way?

The expense and versatility. I can connect this system up to the computer using only a couple of pins and it will power itself. The only other option is the Adafruit sound board which uses a lot of pins, and requires a specific type of card formatting. There was also a good chance that it would interfere with the xBee system in many different ways, Using this mp3 player hack means that the price point is down to £10 as opposed to £30-£35 with the adafruit sound board. It also comes with very loud speakers. It plays a micro sd card which makes everything more compact. It requires very little from the arduino; only a on/off control via a single pin.

I will have to look into transistors as i have never used them before and possibly even test them on a motor.

Possible advancements...

Incorporating an mp3 player which can also record sound. This could allow someone to purchase the bear, record it without having to use another devie, and give it to the person as a gift. I also would want to make an accompanying storybook. Anther possibility is using an mp3 player with a screen... 

Sunday, 11 March 2012

Teddy bear prototype

I am developing the teddy bear prototype with a light sensor to detect presence. The next stage after this will be to incorporate sound. For this i have purchased an MP3 player to hack (with removable SD card and integrated speakers), transistors and a 9V battery pack to make the second arduino portable. This tutorial has provided some inspiration on MP3 hacking but it should be achievable with transistors and a few pins on the arduino. A new soldering iron will be used and new jumper wires have been ordered to allow the extension of the components. Also needed are some 560ohm resistors which can be bought from Maplins.

Functional Requirements:

  1. Sense Presence
  2. Communicate with other xbee device
  3. Indicate response in other xbee device
I have purchased two inexpensive teddy bears and have carefully unpicked the threads from the back of both teddy bears. Some stuffing has been removed to allow space for the arduinos to be placed inside. I developed a quick architecture on paper to illustrate how the system would work and provide visual reference.

Below: teddy bears.



 

The next step is setting up new code on one of the arduino boards to accept input from the light dependant resistor which had previously been commented out. I am going to set up a two-way system and have drawn an architecture for it. I am going to test push button (active sensing) versus LDR (passive sensing) on both devices. In one device there will be an on/off switch to indicate whether the person is present.

Note: when developing this system I noticed the problem of crossed wires in the momentary switch. All exposed components should be insulated to prevent this.

The first thing i did was add LEDs to the project and write code to test them. Once this code was running correctly i then put the LDR (light sensor) in the right place.

Note: A code has to be applied to this project. Green LEDs will indicate that that a person is present at the remote location (green="go" or "everythings ok" so naturally this makes most sense). The red light will be hidden at the bottom of the bear for the users to double check that the system is actually up and running. I have decided to make the LEDs blink to help them draw more attention to it.

I tested the LDR on a single board, and once it was working correctly I then incorporated it into the xBee system.

First problem: As soon as the LDR was incorporated into the system, the serial communication became buggy and slow. As soon as the LDR was removed from the system it worked correctly. This is going to be replaced with a push button for the prototype just to get the system working properly and then new methods will be tested.

I need to put an extra button on the second board to act as a presence indicator to replace the LDR. This was tested on a single board with LED indicator code. Then this code was replaced with serial output code.

Note: Always ensure that there is a delay behind any input switch to avoid overwhelming the serial port.

Second problem: the serial monitors have started displaying random numbers and characters when they weren't before. The usual fixes (baud rate, sending valid characters) aren't working so i am going to presume that it is mostly likely due to the fact that the xBees have now been on for nearly 5 hours and may be slightly overheating.

To compensate for this the code has been changed slightly which has meant that the second teddy bear will not have a lighting indicator. For the purposes of this prototype this will suffice as it is a code not a hardware problem.

Below: xBee wiring.


The push buttons are currently momentary (holding them closed indicates presence).

I placed one of the boards inside one of the teddy bears. Once the new soldering iron arrives both will be placed inside. For now i will have to do some more reading on serial communication to understand some of the problems in the system.

Below are some images and videos of this prototype. The pushbutton was placed in the bears hand. On the rear of the bear a red light indicates that the bear is sending data. The green light may placed in the other hand.

What ive noticed with this prototype are some interesting possibilities for different types of presence indicators. It may not be likely that the users would see the light, and perhaps vibration or sound should be used instead. Also, the pushbutton has to be held down at the moment. This could be incorporated into a 'hug' detector, but in terms of interaction is it flawed: the user probably wouldnt want to hold onto the teddy bear in such a specific way for the entire time.

Thinking of a context of use, this could be useful for parents in different time zones who may not be able to make bedtime phone calls as they're at work. What this would allow is a form of interaction that doesnt prevent users from doing their work. Early conversations with users indicate that this may not just be used at bedtime, and parents may not necessarily have to be particularly far away. It could be used by younger children coming home from nursery in the early afternoon or for multiple scenarios. The system is highly flexible, and user testing is the only way forward from here. The teddy bear prototype will be developed further this week into a fully functioning prototype that is not connected to a PC and then introduced to users as a fully functioning 'thing'. This should spark conversation.

This is the prototype so far:

Front: Teddy is a little lopsided, but its hand is well padded. A larger pushbutton could be useful. I padded around the pushbutton before inserting into the arm cavity to keep it secure. It worked quite well but is a little 'fiddly'. Plates could be placed above and below is to increase the area of the push surface.


This is the padded push button.


The front of the teddy bear system. Note the green light going on when the arm is pushed. It is a rapidly flickering light, but the camera shows it a little slower than it is.


The rear of the teddy bear system. Note the red LED flickering.



This is the code so far:

Arduino 1


#define VERSION "1.00a0"
int BELL= 11;
int REMOTEINDICATOR= 7;
int BUTTON = 2;

void setup() {
  pinMode(BUTTON, INPUT);
    pinMode(BELL, OUTPUT);
 pinMode(REMOTEINDICATOR, OUTPUT);
  Serial.begin(9600);
}

void loop() {
 //      digitalWrite(BELL, HIGH);
char s2 = Serial.read();  
  // send a capital D over the serial port if the button is pressed
  if (digitalRead(BUTTON) == LOW) {
    Serial.print('D');
    delay(10); // prevents overwhelming the serial port i increased the delay
}
   //        digitalWrite(BELL, HIGH);

  if (Serial.available() > 0) {
 //   Serial.print(s2);
    if (Serial.read() == 'K'){
      //ring the bell briefly
            Serial.print('k');
     digitalWrite(REMOTEINDICATOR, HIGH);
     delay(10);
     digitalWrite(REMOTEINDICATOR, LOW);

    }

    if (Serial.read() == 'H'){
      //ring the bell briefly
     digitalWrite(BELL, HIGH);
     delay(10);
     digitalWrite(BELL, LOW);
  //   delay(10);
 //     Serial.print('k'); response code - develop later
    }
  }
}

Arduino 2


int buttonState = 0;         // variable for reading the pushbutton status
#define VERSION "1.01"
int REMOTEINDICATOR = 8;
int BELL = 5;
char val;
int lightsetting = 400;
int BUTTON = 6;
//int photocellPin = 0;
//int photocellReading;

void setup() {
  pinMode(BELL, OUTPUT);
    pinMode(BUTTON, INPUT);
    pinMode(REMOTEINDICATOR, OUTPUT);
  Serial.begin(9600);

}

void loop() { 
    buttonState = digitalRead(BUTTON);
    
    if (buttonState == LOW) {   
    Serial.print('H');
      delay(10);  
    // turn LED on:    
//    digitalWrite(BELL, HIGH);  
  } 
  else {
    // turn LED off:
//    digitalWrite(BELL, LOW); 
   //   Serial.print('M');
  //    delay(10);
  }
//  photocellReading = analogRead(photocellPin);
  char s2 = Serial.read();
 /* 
  if(photocellReading<lightsetting) {
  //  Serial.println(photocellReading);
   Serial.print('P');
   delay(100);
 //  digitalWrite(BELL, HIGH);
  }
  
  if(photocellReading>=lightsetting) {
//   digitalWrite(BELL, LOW);
  }
  
  */
  //      digitalWrite(REMOTEINDICATOR, HIGH); 
 // Serial.println(
  // look for a capital D over the serial port and ring the bell if found
  if (Serial.available() > 0) {

val=Serial.read();
    
    if (val == 'D'){
      //ring the bell briefly
      
      Serial.print('K');
      digitalWrite(REMOTEINDICATOR, HIGH);
      delay(10);
      digitalWrite(REMOTEINDICATOR, LOW);
    //  Serial.print("hi");
      // uncomment the next line if you don't have an oscillating buzzer
      //tone(BELL, 440, 100); 
    }

  }
}


Friday, 9 March 2012

Emerging technologies: Google+ Hangouts

Following on from the Social TV technology that is being researched, Google+ have recently launched a service called 'Google+Hangouts' which is a form of video conferencing where friends are aware of who else is online, and can start group video chats and share youtube videos.



http://www.google.com/tools/dlpage/res/talkvideo/hangouts/

What is interesting about this technology is the creation of a virtual 'presence', and a replacement for normal interaction. There are presence indicators and each member is aware of who else is available to connect with. There is an element which aligns itself with my project: presence. However, the group social aspect of it sets it apart as does the screen based interaction.

There is the idea of a virtual 'space' which in the video is promoted as a valid alternative to arranging real-world meetups.

Two way xbee communication

Until now, the xbee radios have just been configured to work one way. As i want both teddy bears to be presence indicators i have to get them to work both ways. This requires feedback from both sides.

There is an example in the 'Building Wireless Sensor Networks' book which is titled the 'Arduino Feedback Doorbell'.

The router xBee circuit has to be modified and an extra LED added as a feedback indicator. I tried to revert to the original circuitry (without an LED), but the buzzer makes a short 'clicking' sound which isn't very noticeable so the LED will be used instead.

The two boards were then configured correctly and the example code from the book run on both. This didnt work at all. The serial.write command overwrites the serial.read command (arduino cant do both: just one or the other). The serial monitor is reading the command OR writing a command, not both so i am looking online for a solution. I found this link: http://www.robotshop.com/forum/showthread.php?614-Xbee-Series-2-Point-to-Point-Duplex-Configuration

This suggested that the xBees are not configured correctly.  The coordinator was previous addressed to itself which resulted in the serial commands been sent to itself in one of the xBees. The serial numbers and destination addresses have to correspond alternately on each xBee.This setup required the use of my adapter so i will pull the xbees out of the circuits and place them one by one on the adapter.

407635AE SL -  SERIAL NUMBER LOW
407A2427 DL - DESTINATION ADDRESS LOW

has to match on the other device:


407A2427 SL -  SERIAL NUMBER LOW


407635AE DL - DESTINATION ADDRESS LOW

This was reconfigured using X-CTU and an adapter. Now the code works perfectly. As soon as the router xBee recieves a signal from the button and lights up (red LED), it responds and sends a message which provides the presser of the button that its has been recognised (green light). This is almost instantaneous.

Below is a video of the new system working. Now that this is working correctly it can be built up around any architecture.




The next step is to incorporate this system into a working prototype to present to users and develop further.

Tuesday, 6 March 2012

Week 21 Log

Week beginning 27/02/2012

This week firstly involved research into similar technologies as well as related designs. The concept of ‘Social TV’ was explored and similarities between aspects of its concept and ‘Transient Memory’ were identified i.e. the idea of creating an experience with a virtual social element. A virtual social element here is one that where the people involved are not physically close to each-other i.e. within speaking distance. There were some similarities between Social TV and the ‘share chair’ concept mocked up in the cartoon strip from the previous week. There was an element of being about to share what is a very social experience. However within the context of this project, the shared experience is intimate and only involves a small number of people. A large amount of money is being invested in developing this technology and MIT and BT are two institutions which are involved with it.

There was continued work on the contextual report which had the effect of clarifying some thoughts, especially that of the idea of presence. Presence here is simply that the users are aware of each-others locations and are able to interact with each-other in a meaningful and valuable way. There was also some further academic research into cognitive psychology, specifically into objects and memory. The purpose of this is to support my current findings of how objects and memory are connected. There is lots of research into object recognition memory, and one finding was that if an object is taken out of context, people try to find it by trying to remember where their associations with it i.e. where they have experienced it. This supports my suggestions that an object is a ‘link’ to a memory or memories. Facial recognition works the same way.
There was also some ideation work conducted this week. A counter-factual scenario was explored which was ‘what if we had to have a mobile phone for every person we wanted to contact’. Some conclusions were gathered from this which were beneficial to the project: would we be more selective about who we wanted to ‘carry around’ with us, and that the form of each phone would play a larger part. The idea of ‘selection is important to this project as the device doesn’t have networking capabilities i.e. it can’t connect to new people and enable communication between all members. Also form is important as the object would ‘represent’ the person more strongly than if it could connect to anyone. Should the device be customisable? A stop motion advert was created using plastic models which has the potential of being able to be shown to users. The set can also be incorporated into user testing and the user provided with clay to explore their own alterations or ideas. This is a research technique that will be tested.

A ‘teddy share’ prototype was made and functional requirements developed for it. It was made from paper and a higher-fidelity prototype will be made. Problems were identifies and improved on through usage of this system for example the issues of ‘what happens after interaction is done’.

The goals for the following week: further prototyping and testing of the thesis with them. The thesis itself will be examined and adjusted if necessary. There will also be the development of a user base as well as functional and non-functional requirements for them. Two books on research methodologies are being read and findings applied to the project. These books are ‘Survey Research’ by Robert Sapsford, and ‘Qualitative Interview Interviewing’ by Tom Wengraf.