2
$\begingroup$

Hi I am a major in Computer science and this question should be really easy for all the physics geniuses here:

I have a set of data points from an accelerometer on a moving object that basically follows the form.

X acceleration including gravity

Y acceleration including gravity

Z acceleration including gravity

Rotation about x axis

Rotation about y axis

Rotation about z axis

I want to plot the object in 3-D space, and, after some searching, I was told to double integrate to get displacement.

Is that the best way? It doesn't have to be computationally efficient as long as it's easy to understand.

$\endgroup$
  • 1
    $\begingroup$ First you have to calibrate your accelerometers and the rotation sensors, otherwise offsets, gain errors and, much worse, the crosstalk between channels will lead to significant errors. Then you have to use the rotation data to figure out the rotation matrix between the real accelerometer axes and the coordinate system axes that you want the result in. Then you have to invert that matrix and apply it to the accelerometer data. Then you have to subtract the gravitational acceleration and NOW you can integrate twice. Easy, right? :-) $\endgroup$ – CuriousOne Dec 21 '14 at 10:44
  • $\begingroup$ Does the object rotate as it moves? i.e. Does "x" always point in the same direction, or does "x" rotate with the orientation of the object? $\endgroup$ – Sam Bader Dec 21 '14 at 10:57
  • $\begingroup$ @SamBader: Of course it does. That's the fun part. The only way to make sure that it doesn't is by putting it on a precision guiding rail. Then, of course, you don't need the accelerometer. A yard stick will do the job cheaper and better. :-) $\endgroup$ – CuriousOne Dec 21 '14 at 11:00
  • $\begingroup$ Yea it rotates as it moves. Well, the accelerometer is from a mobile phone, so I'm not sure how to access the hardware to calibrate it. Also with regards to does x rotate with orientation to the object , well.. I'm not sure myself. It's a Samsung galaxy s5 if it helps. $\endgroup$ – user198413 Dec 21 '14 at 11:06
  • $\begingroup$ To make things more fun, your accelerometer readings do not include acceleration due to gravity. Accelerometers measure everything acting on the except gravity. Properly speaking, they measure proper acceleration. To make things even more fun,what you are proposing to do is called "dead reckoning". Errors accumulate. Your orientation and velocity contains integrated white noise. Your position contains doubly integrated white noise. You need fixes to compensate for that noise. $\endgroup$ – David Hammen Dec 21 '14 at 13:09
1
$\begingroup$

In principle you could get the displacement from accelerometer measurements, if you also had an estimate of the orientation of the phone at all times.

You would need to use the phone orientation to convert each instantaneous acceleration measurement into the same coordinate frame, and then subtract off a constant component representing gravity, then double-integrate.

To be explicit, let's take some frame where gravity pulls along the $-\hat{z}$ direction, $\hat{x}$ is east, $\hat{y}$ is north.

The phone can be pointing any which way, so it also defines it's own time-dependent coordinate frame, eg. $\hat{x}'(t)$ points to the right of screen, $\hat{y}'(t)$ points to the top of screen, and $\hat{z}'(t)$ points out of the screen. This is the frame in which you get your accelerometer data $\vec{a}'_m(t)$.

Let's say there's a perfect gyroscope in the phone so you know how to describe the orientation of the phone in space. ie you can write $\hat{x}'(t), \hat{y}'(t), \hat{z}'(t)$ in terms of $\hat{x}, \hat{y}, \hat{z}$ and $t$. Then you can compute a rotation matrix $R(t)$ that converts between frames.

$\vec{a}_m(t)=R(t)\vec{a}'_m(t)$

And then subtract off gravity:

$\vec{a}=\vec{a}_m-g\hat{z}$

Then, assuming the phone starts at rest at the origin:

$\vec{r}=\int dt\int dt \vec{a}$.

Voila!

But, this method is very error-prone. For instance, if your orientation estimate is off by even a tiny bit, then the subtraction of gravity won't work well, and the algorithm will think your phone is accelerating even when still. A one-degree error could easily lead to being off by kilometers on the order of minutes, particularly since any acceleration mistake get's double-integrated!

See here for a good discussion!

$\endgroup$
  • $\begingroup$ Wow, that's detailed.. Thanks alot.. I shall try to use a kalman filter to denoise the data. $\endgroup$ – user198413 Dec 21 '14 at 12:46
  • $\begingroup$ Sure thing! I'm not familiar with the Kalman filter, but just read through the Wiki page, it sounds clever, and I'm curious about where you'd apply it. The wiki example included an application merging GPS data with a velocity-based dead-reckoning. Is that similar to what you're planning? $\endgroup$ – Sam Bader Dec 21 '14 at 14:36
  • $\begingroup$ It's somewhat similar except I have no gps data so I will use the phones starting position and orientation as the constant data. I will probably apply it before I begin to do any maths on it $\endgroup$ – user198413 Dec 21 '14 at 14:58
  • $\begingroup$ Hmm, that's a definite bias, no? Eg if the user starts the phone at point A, moves it to point B, and leaves it at point B indefinitely, then the output of your algorithm will steadily creep back toward A, right? Or perhaps that's fine in your application...? $\endgroup$ – Sam Bader Dec 21 '14 at 15:49
  • $\begingroup$ aww damm.. in this case, i need to find a new algorithm to denoise then. gonna take awhile. $\endgroup$ – user198413 Dec 21 '14 at 16:09

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.