Data from BuiltInAccelerometer
 

I currently don't have access to the roboRIO (well... access to the ability to send it flying across the room at 13 feet per second) untill later in the build season so I was wondering if anyone had any data regarding reads from the accelerometer, specifically converting the g's from the accelerometer at setpoints.

Thanks!

Note: I realize Z might differ slightly based on altitude of the testing facility, I'm not so concerned in that as I am x-y

Re: Data from BuiltInAccelerometer
 

Converting them to what? And what do you mean by "setpoints" in this context?

Re: Data from BuiltInAccelerometer
 

FPS (feet per second).

by "setpoints" i mean something like

"at defined 3 feet per second the accelerometer was reading 1g"
"at defined 5 feet per second the accelerometer was reading 1.5g"
"at defined 9 feet per second the accelerometer was reading 2g"
known feet per second / accelerometer g reading pairs.

Re: Data from BuiltInAccelerometer
 

Velocity is not proportional to accelerometer readings. Accelerometers measure acceleration. You would need to integrate accelerometer readings to get velocity.

Re: Data from BuiltInAccelerometer
 

I see RufflesRidge beat me to it.

Re: Data from BuiltInAccelerometer
 

Oh, that makes sense. Than, 1g should be proportional to 32.1740486 ft * s^-1 * s^-1. I feel dumb now.

Thanks!

E/ the neutral reading of the accelerometer seems to oscillate around 0.002 and 0.004. (not 0.2 and 0.4)

Within 10 seconds, this would give the incorrect reading of ten feet per second if integrated.

Has anyone even got the accelerometer to work properly?

Re: Data from BuiltInAccelerometer
 

The math is trivial with the assumption that the robot never turns.

As soon as the robot turns, or goes up/down over the scoring zone, the math gets complex really quickly.

Then, you have to map the xyz space of the roboRio to your xyz space (you don't want to assume that the accelerometer in the roboRio is exactly flat to the base of the roboRio, and that the roboRio is mounted in a plane parallel to the floor.

Re: Data from BuiltInAccelerometer
 

A little bit off topic, but. I was listening on the radio today about a basket ball with sensors (I assume an accelerometer hence the slight topic correlation) that tracks its movement and transmits to a smart phone app. So if you can do it through 3D space, you should be able to do it on a robot in 2d space with something that weighs less than a basketball.

Re: Data from BuiltInAccelerometer
 

I would be very careful with this because it is very hard to get velocity with acceleration from something like the built in accelerometer. Our team has messed with it alot and found there is no good way to figure it our because you have a LOT of noise comming from it. The only real use we found is just telling which direction the robot is going.

The earth has a huge force that is hard to get rid of. If you want to get something accurate enough to tell velocity you might want to go get the NavX board sold my andymark but even with that board the velocity is only accurate for only about 2-3 seconds before it starts to get off.

If the accelerometer was accurate enough to tell speed we would have used them in cars on such. But because of the earth it won't be useful as you think it would. What you learn in physics is only ideal situation. :)

Re: Data from BuiltInAccelerometer
 

The above is a bit ambiguous. How does an accelerometer tell which direction the robot is going?