accelerometer integration

[guillaume-b]

Hi all,
I'm always working on the localisation of my robot (http://sourceforge.net/apps/phpbb/mindb ... f=3&t=1795).
But after the odometer using, I'm trying to use the accelerometer (from Hi Technic).

For the moment I simply memories the accelerometer output and the I try to plot the position on Matlab.
For my tests, I only move the accelerometer on x-axis. I see some noise on the other axis when my accelerometer is moving (along x).
I use the trapezoidal method to Integrate my datas, example of Matlab code :

Code: Select all

for i=2:length(Ax3(:,1))-1
      % Trapezoidal Integration 
    Vx(i,1) = Vx(i-1,1) + ( 15.5/2000 )*9.81*( Ax(i-1,1) + Ax(i,1) )/(200);  % delta_t = 15.5 and I convert the acceleration from g to m/s²
end

Vx is my velocity and Ax is my acceleration on my x axis
When I plot the second integration, I see a "derivation" of my position, that means that I have my position + an error (varying with time - In attached file).
I suppose this error is due to my integration, at each step i add an error so this error is increasing.
For this test, my sampling rate is about 70hz (1 data each 15ms), I try to Integrate after a median filter or without filter (integration already filter my noise). (as you know HT accelerometer have a 200hz frequency)

What is you suggestion ? Is there an Integration problem or something else ? If yes, Is trapezoidal method is the best real time numerical integration method ?
I try my experiments with two different accelerometer and i get the same results.

Thanks for your help

[aswin0]

Hi,

You forgot to attach your graph, so I included one of my own. So I included one from my experiments.

This graph shows robot speed (m/s) over time as it was calculated from the accelerometer output. In reality it was standing still all the time. The accelerometer was very well calibrated in software. The first question is, does your output look like mine?

Anyway, localisation based on an accelerometer is very, very unreliable. I'll try to explain why, there are many different factors. So this is going to be a lengthy reply. For a start we assume that the accelerometer is perfect and noise free. It measures acceleration, to convert it to speed you need to integrate as you do in your formula. This takes time a constant, but the time interval is not constant, it varies slightly. So assuming it is a constant is the first source of error. If the error is such that the average interval is exactly like your assumption it will average out. But is it is considerably larger, because your loop is too tight for example, then it will add up to large errors due to integration.
But this is even worse. Integration gives speed, to get location you need to integrate another time. This magnifies the error (and most other sources of error) even further. It gets big very soon.

The accelerometer might not be totally flat at stand still, or your robot might tilt slightly when accelerating. The nose on the other axes you describe suggest such a thing. This means you not only measure acceleration, but tilt also. You might need to compensate for this to. Also this error rockets sky high because of double integration. Tilt correction can by done, but only with aid of a gyro sensor.

Still with me? And I still assumed the sensor itself was perfect. But it is not. It might be noisy. If this is a zero mean random noise then you wouldn't have to bother with it. Therefore mean or median filters are useless here. But the error might be biased, in other words, there might be an offset error. Offset errors, you guessed it, also get magnified by double integration. You can correct for offset errors by calibration of the sensor. I very much advise you to this this in software and not in hardware, the reason is another lengthy topic. I'll skip that. Here is a explanation on how to calibrate an accelerometer.

Numerical errors in the integration might be of influence but if you use floating values if 16 bit then these can be neglected. As the accelerometers I know of report 10 or 12 bit values at most. I think this round-off to 4 millig is not to avoid.

So to conclude, time, offset and sensor resolution are the main sources of error. These are multiplied and multiplied again by double integration.

[HaWe]

aswin,
I'm completely with you - I personally abandonded all attempts to use the Hitechnic accelerometer.

Nevertheless, I'd recommend to use

s= 0.5 * Δa * Δt² // edited: big misteak corrected ;)

instead of a double integration.

Anyway, I'd wish a well-documented MPU-6050 was finally availbale .

[guillaume-b]

OK. Thanks guys.
Sorry for the missing link :

The formula that I wrote is not exactly this one that I use. I don't use a constant time but i calculate the duration between two measures. (Actually I tried the both method to compare the effects).
I also do a calibration of my accelerometer before all measures. Moreover, my test was realised "outside" of the robot, I set the sensor on the edge of the desk, so I think the sensor was on a good orientation during the measures and only the x-axis was solicited. To test the bias, I check my datas along the time with a constant position and I did'nt observe time's effect on my measure.

I understand all the causes of errors. Hence my questions are : for you is it possible to get a correct measure using accelerometer ? Is there any method to compensate the integration error ?
how can I localise my robot with a good precise after about 10m of navigation ? The odometer have a derivation error this error is not negligible after about 3-4m of navigation and my accelerometer have an huge error after about 2sec of navigation. My first idea was to fuse my datas but it seems not reliable ?
My compas sensor return some errors when it is used on the building but I seems good outside the building !

If you have any others advises or suggestions, you are welcome !

[aswin0]

Hi,

About the graphs. I assume The horizontal axis to be the time axis. But what is on the vertical axis, speed or position? Also, x and z seem identical to me, have you verified that these are both correct? The sensor was motionless during these measurements?

When I did a similar test I noticed that sitting behind my (steel frame) desk made a huge difference. When not behind the desk the speed went up, when behind my desk the speed went down! The difference was caused by my arms resting on my desk. this made a very small difference in tilt angle that was well below the resolution and noise level of the sensor and could not be observed in a single measurement. But it showed in the integrated signal!

Just to make sure. There is nothing wrong with the Mindsensors accelerometer. In fact it is very good for most users as it has little noise. there is nothing wrong with your particular sensor too. This behavior is to be expected.

There is just one solution to compensate for integration errors and this is to fuse in a second signal that is not integrated. I have done this for tilt and rotation with IMU sensors, see my blog for details. For position a drift free reference signal most often is a beacon. This could be a GPS or light beacons (think of light houses used by sailors) for example. Markings on the floor can also help.

Odometry is fun, it is also a very fundamental problem. There is no single solution, there is no easy solution.

Docs formula is numerically better, but dt^2 still is a double integration, so it won't help in this respect.

[guillaume-b]

You are right, z-axis was not z but x !
Here is the correction and some label are added !

So this graphs represents the position on x,y and z axis after the double integration. For this test I only move my sensor straigth on x on about 50cm. So the output is globally correct because we get a position varying from 0 to 0.5m but after some secondes the position decrease due to an integration of error whereas my sensor was stop.
The measures was made without motion and the sensor was blocked and translated between the desk and my fingers.
In the following graph, you have only the x-axis : acceleration, velocity and position, so we can see the integration, the bite noise on the acceleration and then the error on the position (after some secondes).

I try only one test with the accelerometer on the robot and the result is very bad, I only see the integration error, not the displacement.
I didn't try Doc formula for the moment, this will be waiting for next week !
Just for info, here is one of my result with odometry (sorry, this is in french !):


I compare the distance between the start and the stop, according to the graph, my odometer calculate 1m40 whereas in the reality, robot run 1m20. But my measure was not very accurate, this was just to have an idea.

I promise I will read your blog !

[HaWe]

yes, of course my formula calculates a double integration of acceleration over time, but not iteratively twice one after the other, which minimizes the calculation error.

[aswin0]

Hi,

Looking at the graphs there is a small error in the offset correction that build up due to integration. I do not think that better calibration will get rid of the offset error as it might well be smaller that the sensor resolution. There is however another neat trick you might want to try. It goes like this.

First, you take an assumption to the accelerometer output. The easiest assumption is that it should be zero. Over the long term this is true as you start and end with the same velocity, zero acceleration that is.
Second, you compare the output of the sensor to your assumption. The difference between the two is the error of the sensor. This error is noisy but that does not matter.
Third, you multiply the error with a constant factor. This factor is between 1 and 0 and close to 0. This factor is called the I-factor.
Fourth, you add the result of this multiplication to the offset.
Fifth, next iteration you use the updated offset and start over with step one.

You now have created an Integral feedback loop. This loop will try to make the output to be zero over the long term. This is what you want, as this means that over the long term acceleration is zero. This also means that over the long term speed is constant (zero because you started with speed equal to zero). In the end it means that over the long term position does not change. On the short term however, the feedback loop cannot correct for changes in acceleration as the I-factor is small. Acceleration in moving robots like ours are very brief, so these are not corrected out by the feedback loop, as is the change in speed, as is the change in position.
A filter like this is a very effective way to calibrate sensors on the run and keep them calibrated. You'll find a filter like this in most balancing robots to contantly calibrate the gyro sensor. Of course there is a trade-off between calibration speed, larger I-factor, and short term stability, smaller I-factor. You should experiment to get a good value.

You can make a different assumption in the first step. For example you could calculate the acceleration from the motor encoders and use this value instead of a zero value. If you were to do this you would have sensor fusion!

Code: Select all

I made some textual changes after first submit.

[guillaume-b]

Hi,
Effictively I have a bit error on the offset, but this is just a switch from 0 to -0.05 m/s² (so between 0 and -1 on the accelerometer output.) Is it enough to use your algorithme ?

I'm trying to implement it.
So here is what I code on Matlab :

Code: Select all

offset = 0;
acc_sup = 0;
err = 0;
I = 0.3;
for i = 118 : length(data(:,2))               % The 118th value correspond to a theorical null acceleration, this is after the move of the sensor.
    err = data(i,2) - acc_sup - offset;
    offset = offset + I*err;
end
offset                                    % The result is -0.0347 m/s² with an I-factor of 0.3 (or -0.7080 is i use the output values)

I also try to implement it on a moving robot and for the moment the result is worst than before !
Do I use this algorithme only to correct offset on the acceleration output or do i use it on the velocity ?
I guess I have to make this calcul for each axis ?
I'm still working on it.

[HaWe]

guillaume,
to my degree of understanding you are trying to compensate a sensor with non-Gaussian error distribution out of it's own readings. That is somehow like if you want to pull yourself out of a swamp by pulling yourself up by your own hair.
For a static system this might work in some extend but i doubt it will work for a fragile flowing system.
My piece of advice would be to compensate the error noise by statistic or - better - stochastic filters based on different sensor readings (e.g. a gyro), most efficiently by relating it also to external references (e.g. the earth magnetic field - by a compass).

I already tried that by a gyro and a compass with odometry on slippery ground, with, well, moderate to satisfactory results.

But this underlying problem is probably the reason why all well working inertial motion sensors combine a gyro and an accelerometer (plus maybe a compass) with a stochastic filter, e.g., a Monte Carlo Filter (or at least a Kalman, with some degree of severe limitations, too).

(just my personal guess)