Weekend Work Forcast

This weekend I will hopefully have the orientation issue solved and the Xbee communication solved. I intend to use Processing or MAX/MSP for now as the software to receive the data. I will start lighting experiments as soon as I can get a hold of Avner to talk about diffusing light with glass. I ordered MAX so I should have that running tomorrow. I need to order the FTDI IC that can allow Arduino to read thumbdrives. I found out that Mouser Electronic sells them so I don't have to ordered them from FTDI (FTDI is in England).

Xbee Firmware updated

Firmware is updated. Took me a little longer than it should because I kept on hitting the update button that just updated the files of firmware. I then looked at the program and though oops that was a waste of time. A short delay also occurred as the diagram in Tom Igoe's book is incorrect and how I thought it should be set up was the correct way. Be that as it may seven out of eight Xbee modules survived, I managed only to kill one, which I probably killed last semester with a voltage regulation issue. Now that they are updated I can start testing them for receiving and sending data.

Starting from 3D basics

Several noteworthy events: I received two chips from FTDI and interface well with XBee radios. Two I know now I have to up grade my XBee's firmware and that is why I had such a hard time with them last semester. Three there are some nifty produces from FTDI that allow you to use USB flash memory on an Arduino. I could include nice prerecorded sounds versus making them with PWM and various hardwired filters.

After speaking to Liubo Borrisov I need to change the way I am using my accelerometers in 3D space. I have to chose a format first, matrix orientation, Euler angles, or quaternion diplacemnet. So I have good 47 pages to read up on and take notes. After that is decided comes the programing the math into Processing.

I looked into smoke from model trains. It is a electrical heat source with a piston. The heater changes the liquid into smoke and the pistol makes it puff. I am going to contact Lionel and see if I can get one to play around with. Sparkfun started carrying coin (pancake) vibration motors. I need to order one from them and see if they survive the test. I will write to Microsoft tomorrow to see if I can get some vibration motors from defective controllers. It is a shot in the dark but it will not hurt.

Getting there but not quite there yet

Currently I have the two accelerometers averaging out their data in processing to figure out tilt. There are two problems. First one is it cannot pass the 180 point. When it does, it reverts to its original position. Secondly it is very shaky and has issues across the x axis in 3D. I am seeking out some better math equations. I want this project not to require calibration which would fix some of my problems currently. I am going to speak to my professors over some of the math required to calculate the position.

Dual Accelerometers

I am now trying to use two accelerometers placed at a 90 degree difference to create a more stable orientation. This is a common practice used in robotics and vehicles. Two accelerometers are used in the Nintendo WiiMote as well. Pictures will be up later today. Today's project is to get Processing to understand the data. Currently processing is only receiving the data and doing nothing with it. I am working on the math and will implement it in OPENGL.

Here is the arduino code for the two accelerometers. I used an array to make the programing less messy. I am also averaging the data because the accelerometer kicks out a lot of data that can vary with minute vibrations.

int ledPin = 13; //Power Pin
int accelerometer[6]; //Array for analog values
int AVGaccelerometer[6]; //Array for Average Values
int avgLimit = 5; //Number values in the Average
int accVal = 0; //Accumulated number for aveerage
int inByte = -1;

void setup () {
  pinMode(OUTPUT, ledPin);
  Serial.begin(9600);  //Open Serial
  Serial.println("0,0,0,0,0,0");
}

void loop(){
  //first looop get read data
  for (int i = 0; i < 6; i++){ 
    //second loop to accumulate data
    for (int x = 0; x < avgLimit; x++){ 
      accelerometer[i] = analogRead(i);  
      //Reads analog values           
      accVal =  accelerometer[i] + accVal;
    }
    AVGaccelerometer[i] = accVal/avgLimit; 
    //Calculates Average
    accVal = 0; //Reset Acculumator
  }
  //Take a rest Serial Port
  delay(10);    
  //if data is coming in
  if (Serial.available() > 0){ 
  int inByte = Serial.read();
    //Send this out!!
    for (int i = 0; i < 6; i++){ 
      //Data Away!!!
      Serial.print(AVGaccelerometer[i],DEC); 
      Serial.print(",");
    }
    //Send ASCII 10 used by Processing 
    Serial.println(); 
  }
  //Is this thing on???
  digitalWrite(ledPin,HIGH);  
}

Orientation in 3D Program

import processing.serial.*;
import processing.opengl.*;

Serial port;

int getByte = -1; // Variable to hold keystoke values

int xRad,yRad = 0;
int xStart,yStart, zStart = 0;
int xDown, yDown, zDown = 0;
int XVal, YVal, ZVal = 0;

int XdataByteLSB = -1; // Variable to hold keystoke values
int XdataByteMSB = -1; // Variable to hold keystoke values
int YdataByteLSB = -1; // Variable to hold keystoke values
int YdataByteMSB = -1; // Variable to hold keystoke values
int ZdataByteLSB = -1; // Variable to hold keystoke values
int ZdataByteMSB = -1; // Variable to hold keystoke values

int XdataByte = -1; // Variable to hold keystoke values
int YdataByte = -1; // Variable to hold keystoke values
int ZdataByte = -1; // Variable to hold keystoke values

int headerByte = 224; //

int loopHold = 0;

PFont fontA; // Font for printing

void setup(){
size(800,800, OPENGL);
background(0);
fontA = loadFont("CourierNewPSMT-24.vlw");
textFont(fontA, 24);
println(Serial.list());
port = new Serial(this, Serial.list()[0], 9600);
//lights();
// smooth();
}

int reconstruct(int MSB,int LSB) {
int val=0;
val = MSB << 7;
val = val + LSB;
return val;
}

void serialChecker(){
while (port.available() > 0) {
getByte = port.read();
if (getByte == headerByte) {

XdataByteLSB = port.read(); //get LSB
XdataByteMSB = port.read(); //get MSB
YdataByteLSB = port.read(); //get LSB
YdataByteMSB = port.read(); //get MSB
ZdataByteLSB = port.read(); //get LSB
ZdataByteMSB = port.read(); //get MSB
}
}
}

void keyPressed(){
if (keyCode == DOWN){
xDown = XVal;
yDown = YVal;
zDown = ZVal;
}
if (keyCode == UP){
xStart = XVal;
yStart = YVal;
zStart = ZVal;
}
}

void orienatate(){
float X = map(XVal, xStart, xDown, 0, 180);
float Y = map(YVal, yStart, yDown, 0, 180);
float Z = map(ZVal, zStart, zDown, 0, 180);
pushMatrix();
translate(width/2,height/2,0);
X = radians(X);
Y = radians(Y);
Z = radians(Z);
rotateZ(X);
rotateY(Y);
rotateX(Z);
box(100,10,100);
popMatrix();
//background(0);
}

void draw(){
if (xStart < 0 || yStart < 0 || zStart < 0) {
serialChecker();
xStart = reconstruct(XdataByteMSB, XdataByteLSB);
yStart = reconstruct(YdataByteMSB, YdataByteLSB);
zStart = reconstruct(ZdataByteMSB, ZdataByteLSB);
}
serialChecker();
XdataByte = reconstruct(XdataByteMSB, XdataByteLSB);
YdataByte = reconstruct(YdataByteMSB, YdataByteLSB);
ZdataByte = reconstruct(ZdataByteMSB, ZdataByteLSB);
if (XdataByte >= 0 && XdataByte <= 1024){
XVal = XdataByte;
}
if (YdataByte >= 0 && YdataByte <= 1024){
YVal = YdataByte;
}
if (ZdataByte >= 0 && ZdataByte <= 1024){
ZVal = ZdataByte;
}
if (loopHold > 25){
background(0);
text("X Value: ",100,100);
text(XVal,250,100);
text(xStart, 350, 100);
text((xStart - XVal), 450, 100);
text("Y Value: ",100,150);
text(YVal,250,150);
text(yStart, 350, 150);
text((yStart - YVal), 450, 150);
text("Z Value: ",100,200);
text(ZVal,250,200);
text(zStart, 350, 200);
text((zStart - ZVal), 450, 200);
orienatate();
loopHold = 0;
}
loopHold++;
}

Orientation in 3D

I created the orientation program in 3D. It was fairly unstable but slightly more accurate when functioning. Upon researching robotics and vehicle orientation on various websites, the only way to be 100% correct is to use two accelerometers. This is what the WiiMote uses as well. As much as I found like this, accelerometers with breakout boards are not cheap. $5 chip on a $25 board. The tilt switch might be the way to go but the adding latency to the program will also work as well. Just for experimentation I will try it with a second accelerometer. This would require me to use a PLC and not just the XBee radio. I am going to soon experiment using the XBee radios to use their PWM outputs. I also have to work on creating a nice low pass filter for sound.

Orientation

I have created an application that draws the a rotating line according to the orientation of my accelerometer. It works very well on at least the X axis however it is easy to fool by shaking it violently. This can be corrected by a waiting period, if I am upside down for a certain length of time then I am definitely upside. Self built in latency is not a great thing to have. Better the accuracy than the latency. I will try to program the Y axis next to provide more of a stable relationship.

Accelerometer Experiment

Today I set out to find whether or not I could use an accelerometer as a tilt switch. The less pieces I have in my alchemy vessels the less likely hood of breakdown. Though tilt switches are hard to break, I would prefer to keep it as simple as possible. Due to the rather large amount of data and oddities associated with accelerometers I sent out to find whether they could guess orientation well. The answer is an astounding partially. The accelerometer that I am using ADXL 322 from Sparkfun could detect when it had almost entirely flipped upside down. Other orientation was not as consistent as I would have liked. However luckily for me I just need right side up and upside down orientation. The X data reads about 340 to 350 when sitting right side up. When flipped the data reads X as 640 to 650. While upside down there is about ten point drop in value of Y and Z. I restricted the data output on the processing end with a simple loop(I am using processing and arduino). The next step is to write a program the will detect the orientation rather than raw data. Once that is up I'll try to fool it.

 



 

Not Motion Capture

Kathleen, Dylan, Kevin and I created this project for Real Time/Unreal Space. This is (un)motion capture data done at Worely Works fed through a MAX patch and using LUA for openGL 3D. We made it into an interactive installtion more picture and video to follow.

Upcomming Projects

I need to test this project one thing at a time. Friday I will use the accelerometer to test movement and possibly orientation. Though orientation might require a small tilt switch. I might try to make it wireless as well. I need to order MAX/MSP and try it in that as well. Next week I will try to get the object off of Arduino Mini and run solely on the XBee radio.

Amazon's Speedy Delivery

I ordered two books on Amazon yesterday. I used there business delivery which stated it would arrive on Wednesday of the next week. To my great surprise the books arrived today. Pretty amazing knowing how long they usually take. So the two books are Tom Igoe's Making Things Talk and Bill Moggridge's Designing Interactions. Some good but heavy reading.