I have been tying to use the HT Accelerometer but the values that I am getting are very noisy. If anyone has any suggestions I would love to hear them.

How were these taken? Was the robot moving? Did you have motors running? More details, please.

As you can see from this video: http://www.youtube.com/watch?v=Hm9KTui-gA8 , environments are inherently noisy.

- Xander

my apologies the robot was driving on the FTC field (soft floor tiles similar to: http://www.amazon.com/Comfort-Padded-Floor-Fatigue-sq-ft/dp/B000P8W25I/ref=cm_cr_pr_pb_t ) the two (12V) drive motors where running but nothing else.

I knew that there would be some noise but never imagined this much. As per this years FTC challenge I am trying to find when the robot is balanced on the "bridge".

Assuming you read the accelerometer correctly, did you try a different accelerometer to see if you have a defective one?
We used the accelerometer to balance on the bridge and it worked beautifully. Aside from the fact that we do need to eliminate some small amount of noise using deadband, it works!

Your motors and wheels generate an amazing amount of vibration in your robot, don't underestimate it.

- Xander

Was this robot motionless while the measurements were made?
Were the motors running?
What was the interval between measurements?

Thank you all for your help we will have to ensure that the robot is not moving when we take the readings.

I don't know that our team experienced swings that wild, but we did find that running the accel signal through a low pass filter
http://en.wikipedia.org/wiki/Low-pass_filter
was helpful.

(I think the hot setup for balancing would be an accelerometer combined with a gyro mounted to measure pitch rate).

I'm pretty sure that without some totally awsome complex code, you will always have some noise. I know that most professional balancing robots will combine the data from an accelerometer and Gyroscope using a Kalman Filter which is capable of removing virtually all of the noise, but the Kalman filter uses very advanced mathematics and is probably not worth it for FTC. the simplest way to get a noiseless reading in FTC is to stop every time you want to get a reading. the accelerometer can give astoundingly accurate readings of what angle the accelerometer is tilting, by reading which way gravity is pulling it.

We (Team Duct Tape) use the Accelerometer to balance on the bridge. this works extremely well and is surprisingly simple. as long as you stop every time you want to take a reading, you can balance every single time, no matter what the state of the bridge is (as long as you can navigate to the bridge).

how the algorithm works:
the robot checks the accelerometer, then responds by either moving forward or backward.
after its finished moving forward (a distance specified by the encoders), then it will wait for about half a second before taking another reading
if the robot has to change direction then it will reverse direction and go half the original distance (all movements afterward will go no farther than that distance)
the robot keeps looping until it reads balance. after it reads balanced, it continues to take readings to make sure it stays balanced.

No filter, however good will cancel out all the noise. Kalman filters do not cancel out noise at all, they just make smart averages of several sensors. But when these sensors are noisy, the result will still be noisy.

However, I do not think we are seeing just noise here. I understand from the posts that the robot was moving while taking the readings. This make me think that vibrations in the robot are the main cause of the fluctuations in the readings.
If you take a good look at the first few datapoints of the graph one can see that these are very close to zero, having little fluctuation. I suspect that at this time the robot still was motionless. After that you can see the signal going up for some time. I think that this was the moment the robot started moving (accelerating). The signal then goes back to zero. Just like the first few readings, but this time with bigger fluctuations. I think this indicates the robot is moving at a constant speed. So, if I am right, the first few datapoints show the sensor noise, which is small, where as the main part of the graph show robot vibrations, that are huge.

The effect of vibrations can be removed to some extend from the signal with a low pass filter. But low pass filters come with a cost, they'll introduce some lag in the signal.

Aswin you are very much correct the robot was stationary and then accelerated to a constant speed. The reason that i originally posted this was to see where the noise was from I now understand that having the robot moving is what caused the noise and we have designed our balance code to have a pause as Team Duct Tape suggested and it works quite well.

Glad to hear someone else is using the accelerometer to balance , and sorry i got my facts wrong, i didn't mean Cancel out the noise (which as Aswin said, is not really noise). I just meant it gave you an accurate reading of your angle even when your moving.

Anyway, goodluck on the balancing algorithm, and remember that even when it seems like the bridge is balanced, many times its only balanced for 3 seconds or so. this is why the best thing to do is usually just to leave the algorithm running all the way to the end after it balances. the coolest part is when another robot tries to balance on the same bridge. if the other robot is using encoders to balance, and it successfully gets on the same bridge, then the robot using the accelerometer will balance both robots. Our robot did this at the State competition. I've never heard of it happening anywhere else. but i'd love to see it happen again .