accelerometer specs

[bush]

I read over the data sheet, and I don't completely understand everything. I just want to double check a few things...

1) The resolution for RC analog inputs is 10-bits, so my code would would read in values ranging from 0 to 1023.

2) Since we are supplying 5V, zero acceleration corresponds to 2.5V, which is represented by 512 in my code.

3) Acceleration is directly proportional to voltage, so an acceleration of +2g would read as 1023 in my code, and an acceleration of -2g would read as 0. +1g would read in 768, and -1g would read in 256, and so on...

If I were wrong about anything, my guess would be #3. I didn't completely understand what the mV/g meant in the data sheet

I might also be wrong about the code values. Similar to PWM, where we only use 0-254 with neutral at 127, this could be 0-1022 with neutral at 511.

Anybody who can clarify this will be helping me out a lot. Thanks

[KenWittlief]

you are right on the money!

the only thing you will have to check is the actual zero point, it may be a little off from 512, but thats the normal value.

[DonRotolo]

I didn't completely understand what the mV/g meant in the data sheet

You have it correct. Remember that calibration is not perfect, so you may be off by a few counts. A good source of gravity is the earth: When the sensor is pointing "down" it will measure 1 g (1 gravity).

mV/g refers to the number of millivolts (1/1000 of a volt) for each "g" sensed("g" stands for gravity, the normal force experienced by the pull of the earth at sea level, an acceleration of around 9.8 meters per second per second (m/s2), or abour 32 feet per second per second.)

So, if a sensor gives out 125 mV/g, at 1 gravity you can expect to see 125 millivolts.

Hope that helps, & good luck

Don

[bush]

Hmm.. if 0g is read at 2500 mV... if mV/g was 125, wouldn't 1g be read at 2625mV?

And that leads my to my next question. For my accelerometer, the sensitivity is is 312mV/g and the 0g bias is 2.5V (specs for supply voltage of 5V). The accelerometer has a range of +/- 2g, so the output voltage should have a range of 2500 +/- 624mV (1876mV - 3124mV).

Isn't the conversion... CODE_VALUE = mV * (1024 / 5000mV)
So my code values should have a range of 512 +/- 127 (385 for -2g and 639 for +2g)?

I know I completely did a 360 from my original understanding (which was apparantley correct?), but I wan't to make sure I completely understand how this is working first. Would somebody explain where my fault is in the logic in this post.

[Mike Shaul]

For my accelerometer, the sensitivity is is 312mV/g and the 0g bias is 2.5V (specs for supply voltage of 5V). The accelerometer has a range of +/- 2g, so the output voltage should have a range of 2500 +/- 624mV (1876mV - 3124mV).
Yes, this looks correct. Just as a tiny detail take a look at your sensor specification. Depending on the spec some sensors for a "+/- 2g" range may specify 2g as the nominal and some as the minimum. 90% of the time this isn't going to be a big deal unless you NEED to use the full range (and with your sensitivity this shouldn't be a problem).
the only thing you will have to check is the actual zero point, it may be a little off from 512, but thats the normal value.
This is absolutely correct, and for clarity: When you power up you should take a number of analog readings and filter (average) their values to set the mid point (Bias) each time you power up (assuming you always start on level ground, which you should).

I highly recommend using signed math for this type of reading, here is a suggestion:

#define SENSITIVITY 64
// sensitivity = 312mV/g * 1024counts/5000mV = 63.89 (counts/g)

(signed)bias_corrected_voltage = (unsigned)analog_sensor_reading - (unsigned)bias_value;
(signed)acceleration = (signed)bias_corrected_voltage * (unsigned)SENSITIVITY;

This should give you acceleration. Positive and negative values based on direction, which is useful. (Anyone, please feel free to double check me!)

Also notice that without getting fancy your sensitivity is is rounded so your accuracy is limited (but not too much).

I hope this is all clear. Good luck!

[KenWittlief]

Mikes equations look correct. Sometimes you dont need to factor out the scaling of the sensor - your robot equations dont need to be in g's, if you know that 1023 is +2g and 0 is -2 g

I was working on a program once trying to calculate the RMS voltage of a chopped sinewave, which requires doing a square root calculation (try writing THAT in assembly code). After about a day of struggling with this I realized I didnt need the actual RMS (SQRT) number, I could leave the number squared and use that. (I was detecting when an RMS voltage was = 82V. The square of 82 is 6724, so instead of calculating the square root and then comparing the answer to 82, I left the number squared, and looked for 6724).

Scaling the numbers in your SW to actual units (g's, volts, degrees...) is only necessary if a human needs to look at those numbers.

[Alan Anderson]

Scaling the numbers in your SW to actual units (g's, volts, degrees...) is only necessary if a human needs to look at those numbers.
And even if someone does need to look at the numbers, the scaling can be done as part of the input and/or display of the values. The robot can still do all the real work using a convenient internal representation for everything else.

For example, last year we used nifty "follower" wheels to track our robot's position and heading during autonomous mode. The direction values were a minimally-processed version of the raw encoder counts, which got dubbed "RALPHS" for Robot alpha (angle). There was a straightforward conversion between RALPHS and degrees (or radians), but it was only used when specifying turns in the autonomous scripting.

There was a corresponding "RITA" unit for distance, intended to rhyme (sort of) with "meter", but measures of linear travel usually ended up just being called encoder counts.

[Mike Shaul]

Scaling the numbers in your SW to actual units (g's, volts, degrees...) is only necessary if a human needs to look at those numbers.
You are correct, it is not necessary. However... working in a standard unit is good practice for larger systems. Always conforming to a physical unit is nice, and actually... m/s^2 would be a better unit than g's. :)

If I were choosing not to work in physical units, I'd just leave everything in volts (- bias) to minimize the calculations (as you did with encoder counts).