From time to time I meet engineers who are interested in converting acceleration, velocity & displacement. Often, they have measured acceleration, but are interested in displacement or vice versa. Equally, velocity is often used to find acceleration.

This article will attempt to outline the nature of the conversion between these units and will suggest the preferred method for doing so. We will deliberately avoid some of the more complex mathematics. For the mathematically minded there are already other excellent articles on this blog that describe the mathematics involved. This article will also suggest the best method for such a conversion.

Before discussing these conversions we should consider what these measurements are.

- Displacement is the measurement of a distance travelled. If an object has moved 10 meters then it has been displaced by 10 meters or 10 m.
- Velocity, often incorrectly called speed, is the measurement of a certain displacement in a certain time in a specific direction. For example an object that moves 10 meters in a second is travelling at the velocity of 10 meters per second or 10 m/s.
- Velocity can be both negative and positive as it is a vector. The magnitude of a velocity is the speed, this can only be positive.
- Acceleration is the rate of change of velocity, it is also a vector as it implies a direction. If we had a stationary object, it would have no acceleration. The rate of change of its velocity is zero. And, it follows, that an object travelling with a constant velocity of 10 m/s is not accelerating, it is not getting any faster or any slower. Therefore the rate of change of its velocity is zero. However, if an object is changing velocity then it is accelerating. Acceleration can be both negative, which is deceleration and positive, which is acceleration.
- If an object starts from a stationary position and accelerates up to a velocity of 10 m/s in 1 second then the acceleration is 10 meters per second per second or 10 m/s/s.
- If the object started from a stationary position and accelerates up to a velocity of 10 m/s in 50 seconds then the acceleration is 0.2 meters per second per second or 0.2 m/s/s.
- Units of acceleration are often shown as , or .

As can be seen from these definitions of displacement, velocity and acceleration, they are all very closely related. In fact, in mathematical terms they are directly related and simple conversions exist. The mathematical relationship involves calculus, specifically integration and differentiation.

The mathematical integral of the velocity curve against time, is the displacement. That means if you plot the velocity curve f(x) against time and measure the area under the curve you have the total displacement. This relationship is shown in Figure 1.

The mathematical differential of the velocity curve f(x) against time, is the acceleration. That means if you plot the velocity curve against time and measure the slope of the curve a at a given point in time T you would have the acceleration at that time. This relationship is shown in Figure 2.

In simple terms these curves can be described as functions, a function being a representation of a signal. For example, in Figure 3 below, a simple signal exists.

The (x,y) co-ordinates for this curve are as follows in Table 1.

X | Y |

0 | 1 |

1 | 2 |

2 | 3 |

3 | 4 |

4 | 5 |

*Table 1*

The pattern is clearly repeating and simple in its nature. To express the contents of Table 1 as a function would be *(x, f(x))* rather than (x, y) or more commonly denoted as *y = f(x)*. In this case when *x = 1* so then *y = x + 1* and so on. Therefore the function is actually ,

So

This explains the concept of a curve or signal being expressed as a function rather than sets of co-ordinates. Returning to our velocity curve, if the velocity curve against time was represented as a function, it would be

Where is the function at a given time the x-axis value, that produces the y-axis value .

But as a displacement curve it would be represented as the function,

Where is the displacement and is the change in displacement with time.

Hence as an acceleration curve it would be represented as the function,

Where is the acceleration and is the change in velocity in time.

Returning from core mathematics and using DATS to visualise these conversions, we have a simple worksheet as shown in Figure 4.

This worksheet takes a vibration signal and performs integration using three different methods and then integrates again on the resulting signals. Thus from one acceleration signal, it is possible to convert to velocity and then to displacement.

#### Method 1

Integration only.

#### Method 2

Application of a high pass filter and then perform the integration.

#### Method 3

Apply the DATS Omega Arithmetic integration algorithm.

Figure 5 shows the acceleration signal measured by an accelerometer.

Figure 6 shows the velocity signal from the “integration only” method.

Figure 7 shows the velocity signal from a high pass filter and integration method.

Figure 8 shows the velocity signal from the Omega Arithmetic integration method.

Figure 9 shows the displacement signal, created by performing the integration on a velocity signal as in Figure 6.

These graphs show the different results from our three methods of the conversion between acceleration, velocity and displacement, pay special attention to the magnitude of the y-axis units, these reflect the conversion in question and give some guide to the accuracy of the signals.

It can be seen that, in Figure 6 and Figure 9, the integration only method has produced results which are clearly incorrect. The displacement curve shows a movement of several metres when we know we were measuring displacements of only mm’s. The shape of the curves tells us that there is a factor or constant that is affecting the shape of the curve. The data appears to go in the same direction and is constantly increasing in magnitude. This is because of the low frequency or DC content of the signal. This causes an effect which throws out the conversion process and the integration cannot account for this DC content. This error builds up as the signal is integrated and gives this growing or decreasing error effect. As can be seen from Figure 6 the actual valid part of the signal can just be seen but is very small, it appears to be super imposed on the growing error. It is clear from this that Method 1 is not the correct procedure.

As Figure 7 and Figure 8 show very similar signals, one might expect there to be no difference, but on closer inspection of the y-axis values it is possible to see the filter and integrate method has left a slight DC offset present in the signal. That is, the origin is not about zero when we know that it should be. This same pattern is repeated in Figure 9 and Figure 10. Figures 12 & 13 show the velocity and displacement from Method 2 and Method 3 superimposed.

This leaves the Omega Arithmetic method for discussion, after experimentation it has been proven to be the only valid method. The reason for this is that, with Omega Arithmetic, the integration is completed in the frequency domain and not in the time domain. The signal is converted to the frequency domain with an FFT, integrated or differentiated then using an inverse FFT converted back to the time domain.

In summary, if converting from Acceleration to Velocity to Displacement, the required conversion is integration, to go the other way differentiation is used.

Simply applying calculus to a time domain signal is not an acceptable method to perform this conversion.

Filtering in the time domain to remove any DC content, for example filtering out 5 Hz or below, then integrating does produce reasonable looking results, but they are not correct.

The correct conversion method is Omega Arithmetic.

## Further Reading

If you are interesting in discovering more about this topic the following articles are also available

#### James Wren

#### Latest posts by James Wren (see all)

- How Do I Upsample and Downsample My Data? - January 27, 2017
- What Are Vibration, Torsional Vibration & Shaft Twist? - November 8, 2016
- The Effect of the Nyquist Theory on Rotational Order Analysis - October 7, 2016

When you do an FFT… you get mag, real, and imaginary… what is a practical application for using real and imaginary in interpreting phenomena or solving a noise or vibration problem?

Hello Matt,

Thank you for asking a question on our blog.

You have asked a really interesting question, thank you.

In order to explain fully we have written a small article, please see this new article to explain further.

If you have any further questions or would like to discuss this further, please feel free to post back on the blog.

I feel a little bit confused, when reading “acceleration [m]” or

“acceleration [m/s]” at the figures described with velocity and displacement. (i.e. fig. 8 or fig. 10) 🙂

Lutz

Hello Lutz

Thanks for letting us know. Well spotted. It looks like the screenshots were messed when editing the article for the web. They have now been corrected. It might take a short while for the new images to show up due to the page and image cache.

Thanks again.

Where is the link to article referred by you in reply to Matt? Can you not provide a download version and link (PDF) for these explanatory notes/ articles?

Pingback: Which Should I Use? Real & imaginary? Or magnitude & phase? | Prosig Noise & Vibration Measurement Blog

Hello Jha

The new article that James mentioned is now available on the blog here… http://blog.prosig.com/2011/05/04/which-should-i-use-real-imaginary-or-magnitude-phase/

I’m reading this because you’ve just sent out a newsletter with links to the article.

I think there may be some underlying assumptions in your analysis that you haven’t really explained. For example, when you say that the results in figures 6 and 9 are “clearly incorrect” I’m not sure I’d entirely agree. The results do not appear to be correct if the acceleration is, say, a measurement from the vibrating surface of an object that has no net movement – in other words your original acceleration signal erroneously contains DC and/or low frequency components. So the issue here is not so much that you have the wrong integration algorithm, but that you are using the algorithm on inherently inaccurate signals. This can happen when using piezoelectric accelerometers with inadequate bias removal and particularly for acceleration data of shock phenomena. Apparently modern MEMS sensors can be pretty good down to DC so may eliminate some of the problems that you have at source although most of us have a cupboard full of piezoelectric and/or ICP devices which are inherently AC coupled so tend to use a high-pass filter to remove low frequencies and DC and have generally found this to be perfectly successful.

A second point is that we are often interested in the frequency domain characteristics of signals, even if they start life in the time domain. In my experience it is unwise to attempt to integrate and then transform to obtain a frequency domain representation of velocity or displacement. It’s much better to go straight to the frequency domain and then peform the integration through a division by jw (or powers of this depending on whether it is single of double integration and if the spectrum has linear or power quantitites). Maybe that is at the heart of the so-called Omega Arithmetic method (I’m guessing based on the name) and you then do the transform back into the time domain, but unless the engineer actually needs the time domain data then it may be best to stay in the frequency domain once the conversion to a spectrum has taken place.

Hello Stuart,

Thank you for posting on our blog, it is always good to have some detailed discussions and explanation, it forms the core of our ability to learn and grow.

I’d like to respond to your points step by step.

I understand your point of view that perhaps to state something is clearly one way or the other might in some cases be incorrect. As you have suggested, in the project studied in the article there was indeed no net displacement, I believe the article states the signal shows a displacement of meters and the displacement was nowhere near that level. Therefore based on that knowledge a signal that shows meters of displacement must be suspect.

The sensor used was an IEPE device with an AC filter on the front end at 1Hz High Pass. But even in that situation no filter is perfect and it will only attenuate the frequency content of the signal, it will not remove it completely.

I would strongly agree however that the choice of sensor type, MEMS for example, would make a difference in the results and perhaps a different algorithm would not to have had to be applied. We like yourselves tend to have IEPE type sensors due to their ease of use.

We have three different cases in the article, straight calculus, high pass filter then calculus and finally the Omega Arithmetic method.

The straight calculus method still contains low frequency content, hence the error.

The high pass filter then calculus method still contains some low frequency content, it would not have all been removed, hence the improvement in the error, but nonetheless the error is still present.

The Omega Arithmetic method will however completely ignore these low frequencies. That is they will form no component of the output at all. We therefore have a result we can truly be happy with.

Your second point about the frequency domain is quite correct. We indeed complete the analysis in the frequency domain and inverse FFT back into the time domain. It is perfectly possible and valid to stay in the frequency domain if you so desire, this is a feature of our software, not all features of which can be shown here. I suppose it depends on personal choice and preference, for myself I prefer to work where possible in the time domain.

Thank you once again for your engaging comments.

Dear James,

I have attempted to calculate the centre of mass displacement during human locomation over different speeds. I have used the doubly integration method of acceleration from vertical ground reaction forces and this has been unsuccessful. I am looking at multiple strides and find that I get a lot of drift in the data. I have come across the omega arithmetic method. Would this be an appropriate method to use to get the information I require? Also can you use Excel software for this method? Would you recommend other data processing software that is more appropriate for the job?

will

Hi Will, Just curious to know weather you were successful in estimating the human displacement using omega arithmetic. I guess the frequency range would be between 0.3 to 10 Hz. James Wren suggested the omega arithmetic have poor performance for low frequency frequency range (< 10 Hz). Will you please share your work experience.

Hello Will,

Thanks for posting a question on our blog.

Your application sounds like the classical situation in which Omega Arithmetic would help. There might be other issues to consider however, what sensors are you using, does their frequency range go down to DC? This could have a large effect, it’s important to understand the frequency range of your sensors when performing mathematics like this.

Can you use Excel to do this? I very much doubt it. I would have to recommend the only signal processing software package that is up to the job, the Prosig DATS toolbox.

Please do feel free to ask more questions if you so desire.

Hi ,

The blog is great.

When we use a digital ideal filter would not the above problem be addressed. The digital ideal filter converts time domain to frequency domain and cut’s off unwanted frequencies and reconverts using IFFT to time domain. In that scenario would not Omega arithmetic be the same.

Would this steps be fine

(1) use ideal filter remove DC from acceleration

(2) Integrate in time domain get velocity

(3) use ideal filter remove DC from velocity

(4) Integrate in time domain to get displacement

Note : The only over head I see the time spend.

Am wrong in this approach. As ideal filter do convert time to freq and converts back.

Thanking you in advance

Hello Narayan,

Thank you for asking a question on our blog, we are all pleased to read that you enjoying reading our blog.

The steps and procedure you have outlined are perfect and would work wonderfully, if a perfect filter existed.

When implementing a filter in the real world compromises have to be made and therefore a perfect filter implementation is not possible. However even with practical limitations it is possible to still use the steps you propose to produce good results.

However in our testing of real world signals we have found the Omega Arithmetic method, which filters in the frequency domain rather than the time domain, to be more reliable and give a higher quality of results.

So to answer your question, no you are not wrong in your approach, but practical filter limitations might make this method less accurate.

Please feel free to ask if you have any further questions.

Hi,

If you have a filtered acceleration signal of frequencies 50 to 350 Hz. Then you are integrating this signal into velocity, can the velocity signal have frequencies below of above 50 and 350 Hz respectively?

Regards,

Ahmed

Hello Ahmed,

Thank you for asking a question on our blog.

As a simple rule if a signal has no frequency content in a particular range, nothing you can do will change that.

So to answer your question, if the filtering you have completed removed those frequencies they will not be present in the result of the integration.

I can not comment on the quality of your filters, so if they are not functioning as desired there may still be some content in those ranges present.

Hi James,

The article and discussion are very helpful. My question concerns the “filtering” done in the frequency domain. If an FFT is done on acceleration data and then converted to velocity and displacement by integration in the frequency domain, does the filtering prior to IFFT consist of removing just the DC bin, or are there also nearby bins that need to be removed due to the windowing effects?

Thank you

Hi Sam,

Thanks for asking a question on our blog.

Your right to ask this question of ‘filtering’ in this case.

It is very important to handle this part of the algorithm carefully as it makes a significant difference to the results and the quality thereof.

In short your removing the DC bin, as you call it.

There is no effect of windowing as there is technically no filtering and therefore no windowing.

Keeping in mind this step is performed on complex data in the frequency domain.

However what is important is when this is done and how many times this is done through the conversion from, for example Acceleration to Displacement.

Am I right to assume that we should’t use windows (like Hanning or others) before performing Omega Arithmetic transformations?

Hello Ivan,

Thanks for asking a question on our blog.

When you perform Omega Arithmetic using Prosig DATS there is no windowing, there is no need for it.

You would not perform any sort of analysis/transform before or after Omega Arithmetic that would require windowing.

The input to Prosig DATS Omega Arithmetic is a time series signal, the output is a time series signal, everything internally is taken care of for you.

Hi James,

Thank you for the interesting post, I am currently working on a project where I have to retrieve the displacement from the acceleration time histories, frequency range of interest in my project is 2-100 Hz. I have implemented the Omega arithmetic method in matlab and the retrieved displacement data still showed some errors. I am doubting on my skills on signal processing and matlab as I am new to this field. I am confusing with the fft and the frequency lines which I used to divide the ffft. The following is part of my script line which I confused with:

az- acceleration time histories

N=numel(az); %length of FFT

f = (0:N-1)*fs/N; %Frequency line for fft

% Calculte the fft of acceleration

AZ=fft(az,N); %Acceleration in frequency domain

V=zeros(size(AZ));

D=zeros(size(AZ));

for i=1:N

if f(i)~=0 %when frequency near 0, the peak is highes. Therefore, filter the value at this frequency

VZ(i)=AZ(i)/(2*pi*f(i)*sqrt(-1) );%Velocity frequency domain

DZ(i)=AZ(i)/(2*pi*f(i))^2; %Displacement frequency domain

else

VZ(i)=0;

DZ(i)=0;

end

end

% reverse fft

vz=ifft(VZ);%

dz=ifft(DZ);

I would truly appreciate if you could help me to see where I am wrong. I am really sorry to ask you very fundamental questions.

Thank You,

Hannah.

Hello Hannah,

Thank you for posting on our blog, it is good to know that students from Portsmouth University are still taking an active interest in Prosig and our products.

The objective of your project seems plausible, 2 to 100Hz converting acceleration time series to displacement. You already seem aware of Omega Arithmetic and the concepts your working through appear solid.

Unfortunately I have never used Matlab and can not therefore offer any assistance on your scripting and I would suggest making contact with one of your lecturers to discuss further.

Perhaps if I may be so bold, consider using Prosig DATS rather than Matlab!

DATS gives it’s users results, Matlab requires users to you implement your own solution or analysis. Think of DATS as a toolbox you can use a tool simply by selecting it, and think of Matlab as raw metal you need to shape and fashion into you own tools.

Dear Hannah,

I was wondering if you have found the solution with MATLAB?

Nasim

Pingback: Using accelerometer data to calculate distance

Hi;

Heaps of thanks for sharing the information.

I have seen two different versions for converting acceleration to velocity and displacement and vice versa.

1- Some websites mentioned (Velocity = Acceleration/-i*w) where omega is the frequency in (radians/sec) = 2*pi*f with f in Hz. and (Disp=Acc/-w^2).

i is sqrt(-1)

2-While in some forum it is written (Velocity = Acceleration/i*w) and (Disp=Acc/w^2).

So which one is correct? I noticed that if the fourier transform of time displacement is taken, then the first sentence is correct. However, when the inverse of fourier transform for continuous time displacement is taken, then the second sentence is correct.

Also how about spectral densities of Omega arithmetic. In the last pages of article (http://signalprocessing.prosig.com/OmegaArithmetic.pdf), I cannot understand why negative is there!

I appreciate if some experienced mates help me out.

hello

I am working on project which determines the displacement and velocity of an elevator using an accelerometer , but the problem is , i dunno what to do after i record the acceleration signal i know i have to integrate but what program do i use and how to do it

i hope u help me 🙁

Hello Kate,

Thank you for posting a question on our blog. It sounds like an interesting project.

I would suggest considering the frequency range of the accelerometers you’re using very carefully, the low frequency range may be an issue for you in this project. I would have thought that accelerometers that have a DC response would be required. This will make the conversion to velocity or displacement more complex.

With regards to which program to use, we would of course recommend our Prosig DATS.toolbox software, which is specifically designed for this kind of project.

Thank you so much for your help

James, I measured using a laser doppler vibrometer and I would like to convert the set of velocity measurements to acceleration. Can you type a sample matlab code using x as a set of velocity measurements to convert to acceleration with the most accurate method.

Hello,

Thanks for posting on our blog.

It would be nice if you could provide your name in future posts please.

I’m afraid we are unable to provide assistance for Matlab, we can provide examples of how to perform these operations in Prosig DATS however.

If you would like to discuss how you maybe able to use Prosig DATS to accomplish your project, please feel free to drop us a line at support@prosig.com

Many thanks.

Aceleration Unit Converter,Quick and easy tool for converting acceleration units. You can convert units like: km/s², m/s², mm/s², milla per second squared, ft/s², in/s² and others

https://play.google.com/store/apps/details?id=com.anazco.juan.acelerationunitconverter&hl=en

Hello Juan,

That looks like a nice app you have created, well done and thank you for sharing.