I made a small little widget that rotates a bar +/- 90 degrees (180 total). For the other 180, you have to do some sort of listener based off of past data.

http://zbanks.mine.nu/chumby/roll2.swf

A word of warning, its all black, so you need to close the control panel before running.

Sure!

_accelerometer = ["ASnative"](5,60);
this.onEnterFrame = function(){
    currentY = _accelerometer(3)*0.0024489559928062587-5;
    if(currentY <= 1 && currentY >=-1)
    {
        roll = Math.asin(currentY);
        roll *= -60;
    }else{
        roll = 180;
    }
    handle1._rotation = roll;
}

Put that in frame 1, and make a symbol, and call the instance "handle1". Make sure to offset the pivot point!
I don't have the original flash anymore, that was salvaged from another project :-)

Yeah, it would be nice to see it.
I'd like to see if anyone can figure out how to recognize gestures. Again, WiiLi has some decent stuff to look at, under "Wiimote", as they are trying to do the same thing

Also, it is interesting to notice, but someone argues THIS is the formula for roll:
roll = atan2(acc_X, acc_Z);
(That is in some other language, not AS)

I was using:

roll = asin(acc_Y);

(AS: roll = Math.asin(acc_Y); )

Here's the important code from the Pendulum widget, whcih might be helpful to folks playing with it:

P3D = function(x,y,z) {
    this.x = x;
    this.y = y;
    this.z = z;
    return this;
}

P3D._factor = 0.0024489559928062587;
P3D._accel = ASNative(5,60);
P3D._accelerometerComponent = function(index) {
    var val = P3D._accel(index);
    if (val==undefined || val==0) return 0; // handle regular Flash and Foo chumbys
    return val*P3D._factor-5; }
//
// x = right, y = up, z = out
//
P3D.fromAccelerometer = function() {
    return new P3D(P3D._accelerometerComponent(6),P3D._accelerometerComponent(7),-P3D._accelerometerComponent(5));
}

P3D.prototype.plus = function(p) {
    return new P3D(this.x+p.x,this.y+p.y,this.z+p.z);
}

P3D.prototype.scale = function(m) {
    if (typeof(m)=="number") {
        return new P3D(this.x*m,this.y*m,this.z*m);
    } else {
        return new P3D(this.x*m.x,this.y*m.y,this.z*m.z);
    }
}

P3D.prototype.distance = function() {
    return Math.sqrt(this.distance2());
}

P3D.prototype.distance2 = function() {
    return this.x*this.x+this.y*this.y+this.z*this.z;
}

The physics of the pendulum (actually a simple spring/mass system) is done with:

u = new P3D(0,-100,0); // initial position of mass
v = new P3D(0,0,0); // initial velocity of mass
k = 0.5; // spring constant
R = 100; // rest length of spring
b = 0.02; // friction
m = 1.0; // mass

function compute() {
    var fg = P3D.fromAccelerometer().scale(10);// compute force from accelerometer
    var L = u.distance(); // get current length of spring
    var fs = u.scale((R-L)*k/L); // compute the force from the spring
    var fd = v.scale(-b); // compute the damping force
    var a = fg.plus(fs).plus(fd).scale(1/m); // compute the acceleration from the forces
    v = v.plus(a); // update the velocity vector with the acceleration vector
    u = u.plus(v); // update the position vector with the velocity vector
}

The value of 'u' is then run through a simple perspective calculation to set the position of the movieClip representing the mass.

Our accelerometer doesn't know anything about rotation, per se - what we get is instantaneous forces in each of the three othogonal axes.

Yeah, bunnie and I talked about this a bit - the closer the accelerometer is to the center of rotation, the less you can tell if the chumby is being rotated around the vertical axis.  Moving the chip away from the center might help, except that you would not be able to easily differentiate between a force generated by rotation or by linear motion producing the same force vector.

Integration of the forces might help, but it would have to be extremely accurate.

Lets talk about integrating the forces...
Position (X,Y,Z) is related to
Velocity (X,Y,Z) by applying some basic calculus (it sounds harder than it really is...)

V(t) = dx/dt

where V(t) is the Velocity, expressed in (X,Y,Z) at time t
x is the position, expressed in (X,Y,X) at time t
dx/dt is simply how position changes over time

Mathematically, we can derive the final, simple equation if 'integrating' position by the following:

[Integral]{T1,T2} V(t) dt = x(T2) - x(T1)

Where we are just saying that the integral of position is equal to velocity... Better stated, without the math...
Velocity (X,Y,Z) = TimeStamp2(X,Y,Z) - TimeStamp1(X,Y,Z)
So - If we are sampling the accelerometer at a specific time interval, say 1/10th of a second... and someone drops Chumby...
The velocity at point of impact would be:
TimeStamp_Falling_(X,Y,Z) - TimeStamp_BigChangeInValues(X,Y,Z)
Expressed in cartesian coordinates.
Simply stated - Velocity is equal to the amount of change in the (X,Y,Z) values over a known period of time.

Acceleration is the exact same thing... only taking the change in velocity over a known period of time to get Acceleration.

I'll put together an example with math if someone wants to give a useful physical Chumby example.

B

Pedometer Example

Lets say we want to make a widget that measures how far you've walked/ran...
We'll assume that Chumby has a long lasting battery and that you are not walking in a semi-circle around the wall outlet.

The accelerometer used in Chumby is a ADXL322 (from the schematics)
http://www.analog.com/UploadedFiles/Dat … DXL322.pdf
Is the datasheet for it.

Before we do anything with the accelerometer outputs, we need to calibrate these outputs so we know what each value means.
To do that, we need to examine the physical implementation...

The output of the accelerometer goes into an A/D converter:
http://ww1.microchip.com/downloads/en/D … 21298D.pdf
12-bits of resolution & 3.3V reference voltage
therefore; 3.3V/4096 = 0.0008056640625 Volts per bit

SO - For an Accelerometer reading of 2400, the real voltage measured is (2400 x 0.0008056640625)=1.9336V
   - For an accelerometer reading of 2000, the real voltage measured is (2000 x 0.0008056640625)=1.6116V
   - For an accelerometer reading of 1600, the real voltage measured is (1600 x 0.0008056640625)=1.2891V

We know from the datasheet that the accelerometer is ratiometric, so 0g output is typically Vs/2 = 3.3V/2 = 1.65V for a supply voltage of 3.3V.
This does not appear to jibe with the data we took above, so a correction factor needs to be introduced (fudge factor).
This fudge factor is probably from the resistor in the A/D ref voltage circuit that is supposed to reduce noise, but also reduces the reference voltage at the chip.
So - If we know that we read 2000 for midscale and that this should correspond to 1.65V, then
Corrected Volts per bit = 0g voltage/2000 = 1.65/2000 = 0.000825

We correct the other values to be:
   - For an Accelerometer reading of 2400, the real voltage measured is (2400 x 0.000825)=1.98V
   - For an accelerometer reading of 2000, the real voltage measured is (2000 x 0.000825)=1.65V
   - For an accelerometer reading of 1600, the real voltage measured is (1600 x 0.000825)=1.32V
   
Which is more in keeping with the expectations we can derive for output based on the datasheets.
To validate this, we look at the datasheet and see that Sensitivity is ~420mV/g at 3V=Vs.
We subtract 1.98V (our 1g value) from 1.65V (our 0g value) and get .330mV/g which is a little low, but useable.
There is still some error in here... but I will need to find it with a voltmeter on my Chumby later. 
   
The values of 1600, 2000 and 2400 were read directly from the X axis output of the Chumby, while rotating the Chumby to it's
Max value (screen up - 2400) = 1g
Min value (screen down - 1600) = -1g
and the median of the two, Chumby screen facing the wall 2000 = 0g

We do the same for the Y-axis by reading Chumby's Y output while leaning 90 degrees left, 90 degrees right and straight up.

To actually calibrate Chumby, we will need to take some X,Y and Z values while Chumby is oriented in different ways...
This allows us to derive what we don't know from what we do know.
We know that there is 1g of force acting to pull everything down to earth.
So, if we take readings of the accelerometer at each axis's min/max values, we can do some math that gives these values some significance.
For the X Axis
((Max X value) - (Min X Value))/2g = sensitivity
(2400-1600)/2 = 400/g
(The 2 is because we are at +1g@2400 and -1g@1600, encompassing a full 2g)

So what we just figured out is that the X axis reads ~2000 at 0g and that 400 in either direction makes 1g, or -1g

SO - To read acceleration directly from the X or Y axis (assuming we have the same calibration values for Y)
X-axis acceleration (g)= (RAW_X - 2000)/400

Where:
RAW_X is the actual Accelerometer X reading
2000 is the median, 0g value read during calibration
400 is the ((Max X value)-(Min X Value))/2g = sensitivity equation result
and is measured in g.

*** Now that we have 'normalized' the outputs to 'g', we could do the following to get pitch & roll:
PITCH = ASIN(X-axis acceleration found above)
ROLL  = ASIN(Y-axis acceleration)

Now is where it gets fun.
Now that we have instantaneous acceleration values, we can derive Velocity and position.
Lets inventory constants we know:
We know at what period we are sampling the accelerometer (12 frames/sec = 0.08333 Seconds per sample)
We know that an acceleration of 1g = 32.2 feet per second per second, which is about 22mph per second
   (which means that after 1 second, we'd be going 22mph and after 2 seconds, we'd be going 44mph, etc...)
Since we know how fast we are sampling, and how fast acceleration at 1g is, we also know that distance travelled @1g/sample = 2.683 feet

Lets say that we have an instantaneous reading in only the X direction of 0.45g, for 1.5 seconds
How far have we travelled?

Well - A reading of 0.45g, after we've done the math above, looks like 0.45.
Every sample is 1/12th of a second, so every time we read 0.45, we've travelled:
  (0.45 * 32.2) * 1/12 = 1.2075 feet
    where
      0.45 is the calculated X-axis acceleration
      32.2 is the amount of distance covered at 1g of acceleration
      1/12 is our number of samples per second
     
If we look at this the way a computer would... the above answer should be accumulated into a final distance register for 18 samples (1.5 seconds), which would give is a total distance of
18 * 1.2075 feet = 21.735 feet.

This running total would be used to calculate distance travelled.

Combining X & Y values is just using the X and Y results achieved above as components of a vector...
pythagorean theorem.
If we travelled 1.3 feet in the x direction and 4 feet in the y direction... the actual distance travelled is:
d=sqrt(X^2 + Y^2)=sqrt(1.3^2 + 4^2)=sqrt(1.69+16)=4.2059 feet
   
QED

Code snippet for pedometer

ACCEL_CONST = 32.2; // feet per second ^2
FRAMES_PER_SECOND = 12;

// Plug in CAL values for now... set routine later with global variables
CAL_X_MAX = 2400;
CAL_X_MIN = 1600;
CAL_X_ZERO= (CAL_X_MAX + CAL_X_MIN)/2;
CAL_X_SENSITIVITY = (CAL_X_MAX - CAL_X_MIN)/2;

CAL_Y_MAX = 2400;
CAL_Y_MIN = 1600;
CAL_Y_ZERO= (CAL_Y_MAX + CAL_Y_MIN)/2;
CAL_X_SENSITIVITY = (CAL_Y_MAX - CAL_Y_MIN)/2;

PREVIOUS_X_ACCEL = 0;
PREVIOUS_Y_ACCEL = 0;

this.onEnterFrame = function(){
  sampx = accel(4); // from memory... this might not be right.
  sampy = accel(5); // from memory... this might not be right.

  X_ACCEL = (sampx - CAL_X_ZERO) / CAL_X_SENSITIVITY;
  Y_ACCEL = (sampy - CAL_Y_ZERO) / CAL_Y_SENSITIVITY;
 
  //Calculate Current Speed for the sample interval
  // i.e... How fast were we going at the time the sample was taken
  // To figure out how far we've travelled, we need to take into
  // account how fast we were going before as well as acceleration
  X_IN_SPEED = (PREVIOUS_X_ACCEL * ACCEL_CONST); // in Feet per second^2
  X_OUT_XPEED = (X_ACCEL * ACCEL_CONST); // in Feet per second^2
  X_AVG_SPEED = (X_IN_SPEED + X_OUT_XPEED) / 2; // in Feet per second^2

  Y_IN_SPEED = (PREVIOUS_Y_ACCEL * ACCEL_CONST); // in Feet per second^2
  Y_OUT_XPEED = (Y_ACCEL * ACCEL_CONST); // in Feet per second^2
  Y_AVG_SPEED = (Y_IN_SPEED + Y_OUT_XPEED) / 2; // in Feet per second^2

  X_TRAVELLED = X_AVG_SPEED / FRAMES_PER_SECOND;
  Y_TRAVELLED = Y_AVG_SPEED / FRAMES_PER_SECOND;
 
  DISTANCE_TRAVELLED = Math.sqrt(Math.pow(X_TRAVELLED, 2)+Math.pow(Y_TRAVELLED, 2));
 
  TOTAL_DISTANCE_TRAVELLED += DISTANCE_TRAVELLED;
 
  PREVIOUS_X_ACCEL = X_ACCEL;
  PREVIOUS_Y_ACCEL = Y_ACCEL;
   
 
}

OK...
Now we know that the accelerometer mounted in Chumby is not the 2-axis ADXL322 as mentioned in the schematics (there is no BOM), but it is instead the 3-axis ADXL330.

This affects the math in the following manner (and accounts for the error we were getting before)
When we calibrate our raw readings and attach them to a physical G value, we need to keep in mind that the accelerometer indicates at most +1g or -1g... The ADXL322 had a max range of 2g... but the accelerometer installed in Chumby has a much larger range of +-3.6g...

So For the X axis, a +1g reading of 2400 is normal and a -1g reading of 1600 is normal.
2000 is for zero g (90 degrees to the axis)...
We scale these numbers to read between -1 and +1 for multiplication with a constant: ACCELERATION_DUE_TO_G = 9.80665 meters/second^2
So - For a reading of 2g, we would read 2800 or 1200 on the accelerometer output and it would be scaled to +2 or -2.
SCALED_RAW_NUM = (RAW_NUM - 2000)/400 ;

This snippet of code has a routine that runs 60 times a second, automatically... 1.6KHz is the MAX bandwidth of the part, and it was designed for a bandwidth of 100Hz... If you change it, only go down to 10mS... but anything that will change more than 3.6g's in 10mS would probably destroy Chumby, anyways...

Bruce

ps - much of this code was re-used from the iAccelerate project and reported to Chumby FLASH... as well as the accelerometer example provided by Chumby folks

ACCELERATION_DUE_TO_G = 9.80665;
AIR_DENSITY_AT_AVG_TEMP = 1.225; // kg per m^3
FEET_PER_METER = 3.2808399;
FEET_PER_MILE = 5280.0;
POUNDS_PER_GALLON_OF_GAS = 6.25;
POUNDS_PER_KG = 2.20462262;
WATTS_PER_HORSEPOWER = 745.69987158227025;
SECONDS_IN_HOUR = 3600.0;

FrontalArea = 3.7; // m^2 - Frontal Area of you
DragCoefficient = 0.02; - Change this
Weight = (185*POUNDS_PER_KG); // in KG

//Init the 4 movie clips, 1 per line
createEmptyMovieClip("red_mc", 10);
red_mc.lineStyle(1, 0xff0000);
red_mc.moveTo(320,120);
createEmptyMovieClip("green_mc", 20);
green_mc.lineStyle(1, 0x00ff00);
green_mc.moveTo(320,120);
createEmptyMovieClip("blue_mc", 30);
blue_mc.lineStyle(1, 0x0000ff);
blue_mc.moveTo(320,120);
createEmptyMovieClip("yellow_mc", 40);
yellow_mc.lineStyle(1, 0xffff00);
yellow_mc.moveTo(320,120);

//Set currx, the current place where the mc's should be
currx = 320;

//init the accelerometer
_accelerometer = ["ASnative"](5,60);

//Create the data that would normally be accelerometer data

// Timing
//  If Velocity = Accel2 - Accel1 AND
//  If Accel    = Raw2   - Raw1
//  Lets sample at 200Hz and see how it works
delay = 5; // 200Hz
then = 0; //
oldX = 0;
isnewrun = 1;
numofiterations = 0;
totaltime = 0;
currentX = 1600;
sign = -1;
sine = 180;

function GetXData () {
  currentX = _accelerometer(2);

  //currentX = Math.sin(sine*(Math.PI/180));
  //trace ("Sine = "+sine);
  //trace ("CurrentX(SIN) = "+currentX);
  //currentX = (currentX * 400) + 2000;
  //currentX = Math.round(currentX);
  //trace ("CurrentX = "+currentX);
  //sine = sine + sign;
  //if (sine == -90) {
        //sign = sign * -1
  //}
  //if (sine ==  90) {
        //sign = sign * -1
  //}
 
  // ADXL330 runs +-3.6G...
  CurrentX = ((CurrentX - 2000)/400); 
  //trace ("CurrentX = "+currentX);
  TracecurrentX = (((currentX * 400) + 2000)/4)-375;
  //trace ("TracecurrentX = "+TracecurrentX);
  //trace (currentX);

  // If first time through loop - init variable
  if (isnewrun == 1) {
      lastSpeed = 0;
      lastAcceleration = 0;
      lastDistance = 0;
      FirstAcceleration = currentX;
      isnewrun = 0;
  }

  ChangeInAccel = currentX - FirstAcceleration;
 
  gs = ChangeInAccel * ACCELERATION_DUE_TO_G;
  //trace ("Gs = "+gs);
  TracecurrentXAccel = (gs*14) + 115;
  numofiterations +=1;
  //trace ("numofiterations = "+numofiterations);
  totaltime += 0.016;
  //trace ("totaltime = "+totaltime);

  // v=v0 + a*t
  // v(n) = v(n-1)+(a(n) + a(n-1))*(tbs)/2
  currentSpeed = lastSpeed + (((gs + lastAcceleration) * 0.016) / 2); //change in speed/change in time
  //trace ("currentSpeed = "+currentSpeed);
  TracecurrentXVelocity = (currentSpeed*4) + 114;
  SpeedInMPH = (currentSpeed * FEET_PER_METER) / FEET_PER_MILE * SECONDS_IN_HOUR;
  //trace ("SpeedInMPH = "+SpeedInMPH);
 
  // d=v0*t + .5*a*t^2
  // d=.5(v2+v1)*t                                                                           
  // d(n) = d(n-1)+(v(n)+v(n-1))*(tbs)/2
  distanceTraveled = lastDistance + (((currentSpeed + lastSpeed) * 0.016) / 2);
  //trace ("distanceTraveled = "+distanceTraveled);
  distanceTravelledFeet = (distanceTraveled * FEET_PER_METER) / FEET_PER_MILE;
  //trace ("distanceTravelledFeet = "+distanceTravelledFeet);
  averageSpeed = distanceTraveled / totaltime;
  //trace ("averageSpeed = "+averageSpeed);
  AverageSpeedMPH = (averageSpeed * FEET_PER_METER) / FEET_PER_MILE * SECONDS_IN_HOUR
  //trace ("AverageSpeedMPH = "+AverageSpeedMPH);
 
  TracecurrentXDistance = (distanceTraveled) +150;

  // F=ma (Newtons)
  force = Weight * gs;
  //power = force*Distance/Time (Watts)
  power1 = force * currentSpeed;
  //http://en.wikipedia.org/wiki/Drag_(physics)
  power2 = (AIR_DENSITY_AT_AVG_TEMP *
            Math.pow(currentSpeed, 3.0) *
            FrontalArea *
            DragCoefficient) / 2;
  currentPower = (power1 + power2) / WATTS_PER_HORSEPOWER;
  //trace ("currentPower = "+currentPower);
 

  lastSpeed = currentSpeed;
  lastAcceleration = gs;
  lastDistance = distanceTraveled;
}

setInterval( GetXData, 16 ); //(60Hz)

//Update every frame
this.onEnterFrame = function(){
   //Move the mc's over one
    red_mc._x -= 1;
    green_mc._x -= 1;
    blue_mc._x -= 1;
    yellow_mc._x -= 1;
   
    currx++;
    //Add next point
    red_mc.lineTo(currx, TracecurrentX);
    green_mc.lineTo(currx, TracecurrentXAccel);
    //green_mc.lineTo(currx, 0);
    blue_mc.lineTo(currx, TracecurrentXVelocity);
    //blue_mc.lineTo(currx, 0);
    yellow_mc.lineTo(currx, TracecurrentXDistance);
    //yellow_mc.lineTo(currx, 0);
}