But a free-falling accelerometer in a gravitational field will read a nice round zero.
That is the case for an ideal accelerometer. Real accelerometers have biases, scale factor errors, and all kinds of other errors.
The terms I use for flight software are
- Sensed acceleration (e.g.,
sensed_accel), the value read by an accelerometer.
This sensed acceleration includes accelerometer errors such as bias, scale factor and alignment errors. The sensed acceleration also includes terms due to the fact that the IMU is not at the vehicle's center of mass such as rotation and gravity gradient. It also includes terms due to the fact that the vehicle is not a rigid body. Flex, slosh, and moving center of mass within the vehicle come into play here. One last factor is randomness. All real accelerometers exhibit some degree of randomness. Flight software typically does not model any of these complicating factors.
- Non-gravitational acceleration (e.g.,
nongrav_accel) at a point of interest.
In the case of a vehicle with only one IMU, sensed acceleration and non-gravitational acceleration might be synonymous. Many vehicles have multiple IMUs under the principle of redundancy, and under the adage of "never go to sea with two chronometers; take one or three," oftentimes have three IMUs. Even three might not be enough due to the issue of Byzantine faults. These multiple IMU readings need to be transported to a common reference point. Even in the case of a vehicle with a single IMU, it is quite common to transport those readings to a different point of interest. That point of interest is typically the estimated vehicle center mass (there is no such thing as a center of mass sensor) or the vehicle structural origin.
- Acceleration (
accel, or sometimes
dv_dt). This is what one integrates to yield velocity.
This includes gravitational acceleration as well as non-gravitational acceleration, may include third body effects, and in the case of a vehicle about to land, may include fictitious accelerations such as the centrifugal and Coriolis accelerations in the case of landing frame that is fixed with respect to the planet/moon on which landing is about to occur. None of these additional effects, including gravitational acceleration, can be measured. They instead have to be estimated by the flight software. This estimation can be quite complex.
I use similar terms when I'm working on a simulation side of things as opposed to the flight software side of things. Here I start with vehicle acceleration (which includes gravitation, third body effects, etc.), subtract the fictitious accelerations such as gravitation, third body effects, centrifugal acceleration, etc. (I look at gravitation as a fictitious force, which it is in relativity theory.), I then transport that non-gravitational acceleration at the central point of interest to the IMU location to compute the non-gravitational acceleration at the IMU location. Finally I add accelerometer errors to yield sensed acceleration.
As an off-topic final point, never, ever feed truth data directly from your simulation to your flight software. The truth data should always go through some kind of sensor model. The sensor model might be "perfect nav", which does pass truth data to the flight software, but that is an indirect passage. That perfect nav sensor model can later be swapped out with a realistic nav sensor model. More than one vehicle has failed in flight due to an unintentional direct connection between truth data from the simulation to the flight software under test.