You can low-pass filter an accelerometer signal. The gravity vector is at DC. Using a 2-axis accelerometer like the Analog Devices ADXL202 should be sufficient for a plane.
Here's an excellent article on all the math.
what happens if the user suddendly moves the plate forward?
You are confusing the concept of translation (change in position) with attitude (orientation). If the plate moves suddenly forward (pure translation) then you, ideally, want to see no change in the output (the attitude didn't change).
If the user suddenly tilts the plate forwards then after an infinite time period the DC value will also correctly and exclusively reflect this change.
An accelerometer measures acceleration. Acceleration is caused by force. Gravity is a force. Gravity is based on mass relationships, separation distance, and the angle between the vectors. Since neither the plate's mass or the Earth's mass is changing, the separation distance is (for all intents and purposes unchanging), for a specific angle (tilt) gravity is a constant force. Things that are constant have 0 frequency (e.g. "DC").
Any given tilt angle will correspond to one (and only one) force vector on the plate through 180 deg.
The problem in a practical system is that you can't wait an infinite amount of time to notice that the attitude has changed. So you must, like everything in engineering, compromise between the requirements. That is why I suggested the approach of a low-pass filter. Where you corner the filter will determine the trade-off between selectivity and accuracy (in the short term).
In practical systems you can corner somewhere around 10Hz and usually do ok (most cell phones take this approach).
link you provide assumes a three axis accelerometer
The third axis is only absolutely required if you need to detect yaw (via gyro) or disambiguate attitude through both hemispheres (via accelerometer), which the original question seems to explicitly discount as undesired motion. If that assumption on my part is in error, the OP can use a 3-axis accelerometer or 2-axis + 1 axis gyro as desired. That is why I said "should be sufficient."
I'd go with a gyro...
If you are trying to minimize cost/power, then using a gyroscope by itself is a poor choice with respect to the accelerometer as proposed. In the tilt sensing application you described, the gyro develops a tilt error that continues to increase without bound as it measures only rotational accelerations, which you must integrate to find the position (tilt).
When you tilt the gyro you'll see a change in the output voltage, but it quickly returns to it's resting level if the new attitude (tilt) is held. This leads to two undesirable problems:
- It becomes extremely sensitive to jostling (shaking and other transient disturbances)
- Error accumulates very quickly and must therefore be "reset" to some known value every so often by correlating it with some other data source (such as the accelerometer as proposed).
Here is data from an experiment conducted by David Anderson on his self-balancing robot:
Note how the error (difference between the blue line and red line) quickly runs away from the ground-truth.
In contrast, the accelerometer measures tilt directly so error does not accumulate. In the gyro, each estimate of tilt is a function of all prior measurements (error accumulates). In the accelerometer, each estimate of tilt is based on only the current reading (to the first order).
The PWR_MGMT_1 register should always be set the last after all the register configurations like that:
void MPU9150_Init_awake_SensorRegister(unsigned int MasterI2C_BaseAddress)
{
WriteByte_to_SlaveRegister(MasterI2C_BaseAddress,RA_GYRO_CONFIG,0x08);
WriteByte_to_SlaveRegister(MasterI2C_BaseAddress,RA_ACCEL_CONFIG,0x10);
WriteByte_to_SlaveRegister(MasterI2C_BaseAddress,RA_USER_CTRL,0x00);
WriteByte_to_SlaveRegister(MasterI2C_BaseAddress,RA_PWR_MGMT_1,0x09);
}
I used 0x09 instead of 0x01 to disable the temperature sensor cuz I don't need it.
By the way, I just tried that and it works so far; I still need to experiment with it however.
Best Answer
Turns out that calibration requires the sensor to be in the default "z-up" position, and that even if you adjust the trig functions later, the values will still be off if you use a different orientation. I tried removing the MPU6050 from my apparatus, placing it flat, and re-running the calibration. That improved the values, but the ranges still weren't aligning correctly with my custom orientation, so I added this function to flip the X and Z axis based on the code provided in this comment:
And then, with that and the proper calibration values, it now returns the correct 90 to -90 degree range when I change pitch by 180 degrees.