Accelerometer Norm

[oliver114 ENGINEER]

Hello ..

I used the sqrt function to get the norm of accelerometer:

Acc_Norm = sqrt(accx*accx + accy*accy + accz*accz)

I noticed the acc norm change between 9 and 10.5 m/s^2

(accx, accy and accz equals mpu_data (mpu6000.c file)

What is the reason in your opinion?

best wishes

[Peter Hollands]

Hi Oliver

The "norm" is the magnitude of the measured acceleration vector that has been measured in 3 dimensions. When the board is sitting still, you would expect the "norm" to be close to the value for the Gravity vector 9.81m/s. (This value does change slightly in different parts of the world). But if your board is moving or shaking then the acceleration vector will change.

https://builtin.com/data-science/vector-norms

If you are printing out the norm values as the board is being rotated around the axis, then you may find that you have introduced some elements of acceleration as the board is rolled.

It might be worth printing out the norm just for the board sitting on the 6 axis in which gravity can occur on a single dimensional axis. i.e. On the X axis and then flip the board the other way up so it's effectively a -X axis. And do that fo the Y and Z axis as well.  You could print out the X,Y,Z values as well as the norm values, and in this way check that the calibration and scale of the accelerometer is within acceptable limits.

It is possible to manually calibrate the accelerometer and gyro offsets etc for a given board, but it's been a long time (years) since I've done that. I think Bill wrote a document about that.

Best wishe, Pete

--
--
---
You received this message because you are subscribed to the Google Groups "uavdevboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/af4370ea-f170-468c-95ba-365188a8c5f1n%40googlegroups.com.

[Alex Zarenin]

I collect a few thousand measurements while slowly rotating the board in all three dimensions. Then in Excel I calculate the correction similar to "hard and soft iron" correction for magnetometer (https://www.nxp.com/docs/en/application-note/AN4246.pdf). If you are interested, I can share the spreadsheet with calculations.

[Peter Hollands]

Hi Oliver,

I enclose a document by Bill Premerlani from 2015 which outlines how to calculate and set the offsets for a given board.

Best wishes, Pete

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/38d21757-543b-42fb-b4c8-714fb53ffbb7n%40googlegroups.com.

[oliver114 ENGINEER]

Hi Pete

Thank you for reply,

I printed out the norm values as you say "the board is sitting still", the norm is different between all states. (for X,Y,Z)

[oliver114 ENGINEER]

Hi Alex

Yes, I will be grateful if you send me the file.

[Alex Zarenin]

Attached is my spreadsheet. Actions should be clear if you look at the formulas in the spreadsheet, but if you have more questions, don't hesitate to reach out.

Regards,

--Alex

[jlde...@gmail.com]

Hello Alex,

We are not working on UDB right now but we are being faced with similar needs to get good calibration data to improve AHRS accuracy.

I am not that good in Excel, how to you compute the values of the V vector and W matrix?

Jean-Luc

 

FYI:
To improve accuracy, we have been forced to control the accel/gyro MPU temperature to reduce bias and gains changes on both accels and gyros. We therefore perform calibrations when temperature is stable.

To simplify the calculations, we limited the corrections to an offset and a gain we apply to each axis.  The offsets being simply half the difference between the min and max around each axis and the gain being half the sum. Limiting to and around the axis helps focusing on fewer quality data points.

We also remove data points when we detect a small variation in gyros or accels.
I guess this is close to using V for the offsets and the diagonal of W for the gains. Because the non-diagonal terms of the W matrix are very small, the results should be close.

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/78fc2248-15e8-4f29-8376-6711c760b18bn%40googlegroups.com.

[william premerlani]

Team,

For about a year and a half, Ben Levitt and I have been working on applying a variation of the UDB mini to a luge application, which operates over a wide temperature range. We have implemented several methods to improve accuracy, including temperature compensation.

As part of the calibration process, I program each UDB with compensation table building software and put it into a freezer at  - 15 degrees F, (-26 C) and let it "cold soak" overnight. The next morning I take it out, turn it on and let it come up to room temperature. It builds temperature compensation tables for both accelerometers and gyros as it warms up. As part of the process, I use an infrared "brooder" lamp to bring it up to 100 degrees F ( 38 C ).

I then use accelerometer measurements in 6 orientations as input to a calculation that fits an ellipsoid to the data, producing offset and calibration information.

Note that the temperature compensation must be applied during this process, because the accelerometer offsets vary with temperature.

The overall result is 0.1 degree static accuracy and 1 degree dynamic accuracy over the temperature range.

Attached is a plot from a static verification test. There are two traces, one is the raw estimate of pitch angle from accelerometer data, and shows the accelerometer noise. The other is the pitch angle estimate derived from the direction cosine matrix, which is being updated in a two stage process. The first stage is a 32 bit coning compensation computation performed 8000 times per second. The second stage is a 32 bit matrix update at 200 times per second, using a high order Taylor expansion for sine and cosine.

There is a  continuous two-stage matrix alignment process, a residual gyro offset estimator, all supervised by an "anti-jostling" algorithm.

The UDB is in a purpose-built 3d printed case that during this test has been placed on a surface that is level to within 0.1 degrees. The UDB was placed on the surface and turned on and recorded pitch data. Note there is a brief initialization transient of about 0.1 degrees, and then small deviations within +- .05 degrees, caused by accelerometer noise.

During luge runs, the UDB is producing orientation information accurate to within 1 degree over a time period of about 5 minutes without the use of either GPS or magnetometer.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/00ac01da9e0d%24fd40b250%24f7c216f0%24%40gmail.com.

[jlde...@gmail.com]

Hello Bill,

Very interesting.

Questions :

- « It builds temperature compensation tables for both accelerometers and gyros as it warms up. As part of the process, I use an infrared "brooder" lamp to bring it up to 100 degrees F ( 38 C ).”

Do you rotate the board during this warmup or do you assume that the variations on one axis are applicable to the other 2 axis?
FYI: we are using internal chip temperature sensor to monitor accel/gyros temperature but we have found that it takes several minutes for accels/gyros bias to stabilize after having reached a given temperature. Probably not a problem if temperature varies very slowly.

-“ The first stage is a 32 bit coning compensation computation performed 8000 times per second”
Did you implement this because of the luge specific vibration modes?

Do you have an estimation of the performance gain achieved because of this compensation before the matrix update?

 

-“ There is a  continuous two-stage matrix alignment process, a residual gyro offset estimator, all supervised by an "anti-jostling" algorithm.”

Could you elaborate on how you estimate residual gyro offset?

FYI: we have found that, without external source,  because gyro z axis is only observable when pitch and roll are different from zero, which is when the accels are not as good as a reference, the bias estimated can be worst than the natural z gyro drift.

 

-“ accurate to within 1 degree over a time period of about 5 minutes”

What reference did you use to estimate accuracy? We have just installed a GNSS RTK to get a “good” reference on one of the test gliders.

Thanks for your help,

Jean-Luc

 

Ps: I guess we are all trying to achieve the same accuracy as 50K$ laser IMU 😊

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/CANxo1ZK_BtkKCWRPKMwDjdmZTpSNfoYU__GJ0AtygHHmZTEXqA%40mail.gmail.com.

[william premerlani]

Hi Jean-Luc,

Here are answers to a couple of your questions.

The temperature compensation of the gyros is relatively easy.

The temperature compensation of the accelerometers is more challenging because of gravity, but I worked out a very accurate way to do it in two phases.

The accelerometer offset curves are different for each axis, but they are a function mostly of temperature, so step 1 is to determine the shape of the function for each axis, with an uncertainty of a constant number for each axis because of gravity. So here is how step 1 is done:

Step 1: During measurement of the accelerometer temperature compensation table, the board must be motionless and in a fixed orientation. The orientation is note relevant, any orientation will work, as long as it does not change. On power up, take the first reported set of 3 values as a baseline, and subtract them from all subsequent measurements. From that, construct a function shape table.

The function shape table captures the shape of the curves, with an unknown constant offset and gain for each axis. I have verified through separate tests that the shape of this curve is repeatable, is a function only of temperature and is independent of orientation.

Step 2: Gather lots of data taken in 6 different orientations to define an ellipsoid. Take the averages for each orientation and use them to compute offsets and gains for the three axes. I have found that for the sensors we are using, the offsets are different for each axis, but two of the axes have about the same gain that is a little bit low and the third one is a little bit high.

Then, the final approach to doing accelerometer compensation is to apply the sum of the shape table from step 1 and the offset computed in step 2 separately for each axis. For the sensor that I am using, the net result has less than 0.1 degree (0.002 times gravity) error. I measure this with the aid of a highly accurate spirit level. I found a level spot on my desk, level to within 0.01 degree, and placed the board in its case there for the data in the plot that I showed.

Regarding gyro bias removal, I completely agree with your comments, but that is not the method I am using. I tried the method that you described and it does not work for the reasons you mentioned. So I use a different, separate method instead: I apply a second order filter directly to the outputs of the three axes of the gyros whenever the UDB is not moving. The filter produces correct output for a step and ramp time variation. I have a sensitive "antil-jostle" algorithm, with censoring, that reduces the residual gyro drift from 20 degrees per minute down to 1/2 a degree per minute. The typical amount of time for a luge run is 1 minute, so the expected error is about 1/2 of a degree. The filtering is done whenever the UDB is not being jostled. When there is jostling, the filtering is turned off, and the offsets computed by the filter are used in the matrix update computations instead of the values that are doing the matrix alignment. During a luge run, jostling is continuous because the ice is so rough. See this video for example. I note that the method that I am using is tailored to the luge application, and is of little value for aircraft.

Regarding the coning computation, it does improve the accuracy of the computations for luge applications. That is because the ice on a luge track is shaved, which produces a "terracing effect", which in turn produces a strong gyro signal at around 300 Hz. We discovered this by looking at data taken at 8000 samples per second and noticed the signal. Based on the speed of the sled and the way that shaving of the ice is done, a frequency of about 300 Hz in the pitch axis gyro is to be expected.

Best regards,

Bill

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/012201da9e21%248c5aa0f0%24a50fe2d0%24%40gmail.com.

[Alex Zarenin]

Bill's method is much more precise, but requires freezer, heat lamp, and precise measurement in 6 orientations. I just collect a long stream of data while (slowly!) rotating the board in multiple directions. Formulas to calculate adjustment vectors are in the spreadsheet. I start with V vector at all 0s and W matrix is a diagonal unity matrix (diagonal elements are 1s, the rest - 0s). Elements below diagonal are made equal to location of the corresponding elements above the diagonal (check formulas in Excel). To obtain proper values for V and W, I use Excel Solver to minimize the variance (formula for variance is in the spreadsheet). Elements highlighted in Red are Solver's variables.

Hope this helps.

[jlde...@gmail.com]

Hello,

“I use Excel Solver to minimize the variance”:

Thanks, that was not explicit to me.

Your method is accurate to minimize the effects of accels offsets and gains but, at given temperature.
With our low cost MEMS sensors there is a significant change in offsets and gains in function of temperature.

If you want to achieve decent accuracy, you either have to model the offset and gains variations with temperature (Bill’s solution) or you maintain the sensor at fixed temperature, which is what we have used (and of course calibrate at that temperature)

When rotating the board to get data in the 6^th quadrants, we are monitoring accels and gyros variations to discard data points which could be outliers due to the unwanted accelerations from operator.

JL

To view this discussion on the web, visit https://groups.google.com/d/msgid/uavdevboard/2cb08ba9-c0b2-4e6a-a4e0-d2c0ccd53dean%40googlegroups.com.

[Alex Zarenin]

Here is detailed tutorial on using Excel Solver: https://www.solver.com/solver-tutorial-using-solver. Yes, calculating temperature compensation is a separate step.