6
$\begingroup$

I'm ashamed to ask this.

But a free-falling accelerometer in a gravitational field will read a nice round zero.

And if that accelerometer is given some thrust, it will read the acceleration produced by that thrust alone---gravity be damned.

Yet we care about the acceleration due to gravity, so we can correct the reading from our accelerometer by subtracting g to get the combined acceleration from thrust and gravity (and whatever else).

Maybe I already know this and I forget. But what should I call the acceleration reading i) when gravity is ignored and ii) when gravity is accounted for?

I'll go put my dunce hat and stand in the corner now.

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Don't feel bad for asking this. I feel like I constantly have to check my understanding of things of this nature (especially when we're talking about reference frames). $\endgroup$ – dez May 28 at 21:07
  • 2
    $\begingroup$ Whew, glad to know! I'm always going back to the littlest basics and I'm too many years out of college to feel good about it. Ha ha :D $\endgroup$ – user39728 May 28 at 21:31
  • 3
    $\begingroup$ Nothing to be ashamed of. This trips up a lot of people. Gravity is just weird. $\endgroup$ – AJN May 29 at 4:53
  • 1
    $\begingroup$ Don't feel bad: This is a question asked by applied physicists, aerospace engineers, and non-specialists all the time. The Wikipedia answer is well-worded (see answer following by @AJN). $\endgroup$ – Chris Ison May 30 at 17:03
7
$\begingroup$

The terminology are (from Wikipedia)

  1. Proper acceleration (force per unit mass(?); happens to have units of m/s^2)
  2. co-ordinate acceleration (second derivative of position vector co-ordinates; has units of m/s^2)

Proper acceleration is the physical acceleration (i.e., measurable acceleration as by an accelerometer) experienced by an object. It is thus acceleration relative to a free-fall ...

Proper acceleration contrasts with coordinate acceleration, which is dependent on choice of coordinate systems and thus upon choice of observers (see three-acceleration in special relativity).

So, proper acceleration is measured by the accelerometer. You add/subtract gravity terms to get

$$\frac{d^2 \vec{r}}{d t^2}$$

Improve this answer
$\endgroup$
5
  • $\begingroup$ This is perfect! Thank you for illuminating :D $\endgroup$ – user39728 May 29 at 6:01
  • $\begingroup$ Not a downvote, but I would never, ever use these terms in software, whether it's flight software or sim software. And I do know relativity theory. Your software has to be comprehensible to someone who knows nothing about relativity theory. $\endgroup$ – David Hammen May 29 at 16:15
  • 1
    $\begingroup$ I don't disagree. I use the words sensed acceleration and second derivative of the position vector whenever confusion can arise. However, i wanted to direct OPs attention to the terminology in the answer. $\endgroup$ – AJN May 29 at 17:16
  • $\begingroup$ I notice that you have included them in your answer. @DavidHammen $\endgroup$ – AJN May 29 at 17:17
  • $\begingroup$ I also want to note that inertial sensors measure sensed acceleration. However non inertial sensors like radar, GPS, vision based systems can measure r, dr/dt and d^2r/dt^2 directly without worrying about accounting for gravitational forces. $\endgroup$ – AJN May 29 at 17:21
6
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Thanks for sharing your thoughts! This is all very helpful, but I’m now suddenly interested in that nav sensor model. This is something I’ve completely ignored in my simulation—so far. I’ve been jammed with so much else. But sensors aren’t perfect and it seems important to capture that—especially because I think this is where the kalman filters enter the picture? Do you have any links to nav sensor models? Maybe something from a rocket like, well, you know, the space shuttle or the Saturn V? I feel like I really need to start thinking about this. $\endgroup$ – user39728 May 29 at 23:16
  • $\begingroup$ Also, now super curious about the vehicles that failed due to that truth data being fed directly to the flight software. Can you clarify what you mean by truth data? Is it just the actual vehicle attitude/position/velocity? And what part of the flight software are we talking about—navigation, guidance, attitude control, throttle control, sequencing logic? Any specific vehicles in the public domain that you can say “that failed because truth data going directly to flight software”? $\endgroup$ – user39728 May 29 at 23:20
  • $\begingroup$ @user39728_i_said_user_39728_i_ Regarding your first comment, a navigation sensor model is necessarily going to be highly device specific. For example, the model for a pulse integrating pendulous accelerometer mounted on a stable platform must necessarily be rather different from the model for an optical accelerometer strapped-down to the vehicle, which in turn will be different from the model of a strapdown MEMS accelerometer. The same goes for gyros as there are many different kinds of gyros that differ not only in terms of accuracy but also in lack thereof (randomness). $\endgroup$ – David Hammen May 30 at 12:30
  • $\begingroup$ Some common tools will be of help, such as a generating a Gaussian random variables (white noise) and exponentially coupled Gaussian random variables (not white noise). It will help a lot if you understand terms such as white noise, Allan variance, misalignment error, timing lag, and a slew of other concepts. Modeling sensors in general is not easy, and navigation sensor models are typically the most complex of all. A good GPS sensor model is typically thousands of lines of code if you count the code for the ionosphere model as part of the GPS sensor model. $\endgroup$ – David Hammen May 30 at 12:36
  • $\begingroup$ Regarding your second comment, my 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 may well be apocryphal. It's something told from day number one on the job to flight software developers, sim developers, and verification and validation team members. Feeding truth data directly to flight software (or pseudo flight software) is something one is never supposed to do. $\endgroup$ – David Hammen May 30 at 12:54
2
$\begingroup$

The acceleration reading

  1. when gravity is ignored = acceleration in the reference frame of the falling accelerometer

  2. when gravity is accounted for = acceleration in the frame of the Earth

Optionally, one can distinguish between a Fixed Earth (perspective of someone on the surface) and that of an inertial Earth (rotating) again by stating the reference frame.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy