Problem deriving displacement from accelerations

Question

I have a problem deriving displacement from an accelerometer; I want a time series of displacement so I used numerical integration twice;

I based my code on the trapezium rule and so did something like this to get velocity and again to get displacement;

while (i

However, I just tested my method and the displacement values are not sensible suggesting very small strides. Obviously there is a problem with my approach and I know that errors can be accumulated this way, any ideas of a way around this?

Answer 1

Using accelerometers as a basis for determining the position of an Earth-based object is a non-trivial exercise. Using a simple numerical quadrature technique such as trapezium almost certainly is not going to cut it. Here are some of the challenges:

• Accelerometers report acceleration in terms of the accelerometer case frame. It is invalid to compare, for example, the reported x-axis acceleration at time t₁ to that at time t₂ if the accelerometer has rotated between times t₁ and t₂. To integrate acceleration (twice!) you need to transform those sensed accelerations to some common frame.

• Accelerometers measure acceleration relative to an instantaneously co-located, co-moving, free-falling frame. In short, accelerometers don't sense gravity; they sense acceleration due to everything but gravity. You somehow need to account for this unsensed gravitational acceleration.

• Accelerometers have both systematic and random errors. You might be able to ignore the systematic errors, but the random errors are a killer. Suppose you do the best possible job of dealing with the time-varying orientation of the accelerometer case frame and do the best possible job of estimating the unsensed gravitational acceleration. Now suppose you put an accelerometer on a table and just let it sit. You know the initial velocity is zero, and you know the accelerometer isn't rotating. Suppose you integrate the gravity-corrected accelerometer output to yield velocity and the integrate again to yield position. If you do this right, the accelerometer output will be white noise with a mean of zero. When you integrate that to yield velocity, you'll get a random walk. The velocity will have an expected mean of zero but the variance will grow with time. When you integrate that again you'll get an integrated random walk. If you do this for any extended period of time, there's a less technical name for the result: "pure garbage".

To address the orientation of the case frame you need to either make sure the accelerometer case frame never rotates (BTW, that's a bit tricky since you're on a rotating Earth), or you somehow need to measure the time-varying rotation of the case frame. A gyro to measure changes in orientation is a common approach, but now you're once again faced with the random walk problem. Rate gyros take a random walk. Some use magnetometers. In space we use star trackers to address the rotational random walk problem.

There are lots of tricks for getting around the un-sensed gravitational acceleration problem. For space vehicles that dock with the International Space Station, it's mandatory that the docking vehicle either have a rather complex model of the Earth's gravity field or that the operators of that vehicle can explain to NASA and its Russian counterpart why they don't need it. A much simpler approach for things on the ground is to have the object stay at rest for a bit of time during startup to enable the software to determine the g vector.

The last problem is the trickiest. The standard approach is to use a Kalman filter, and how to do that is beyond the scope of this question and answer site.

Answer 2

I think you have made some mistake in taking the initial condition. $$v(t)=u(0)+\int_{0}^{t}a(t)dt$$ and $$s(t)=s(0)+\int_{0}^{t}v(t)dt$$. I think you have not used $u(0)$ and $s(0)$ properly.