calibrate function interpretes gravity as error

[mycosd]

Hi again,

In calibrate the accelerometer values read are automatically set as error (axe,aye,aze). However if you have the MPU flat on a table then it should read az=1. So now aze will be set to 1 even if there is absolutely no error in the MPU.
If you are only interested in relative accelerometer readings, this might be exactly what you would want. But for roll/pitch/yaw calculation which is also based on those measurements you get a lot of noise/drift, and the accelerometer angles become completely unusable.

To reproduce:

1. put MPU flat on the table
2. run calibrate
3. read getAngleX/getAngleY/getAngleZ

Now for comparison:

1. put MPU flat on the table
2. run calibrate
3. set sensor.aze-=1;
4. read getAngleX/getAngleY/getAngleZ

The easiest way I can think of handling this is: The calibrate function itself would need an argument that says, eg. ORIENTATION_X_IS_DOWN, ORIENTATION_Y_IS_DOWN, ORIENTATION_Z_IS_DOWN (this should be default) and then you would subtract 1 from the error which matches with the given orientation.
However, this would limit the calibrate function, to be only allowed to be called when the MPU is perfectly aligned on an axis.

Maik

[RobTillaart]

Thanks for this explanation, appreciated

[RobTillaart]

(sorry for late reaction, too busy with other things).

You're right the Z should read 1 in case of a flat sensor.

I like the idea of the parameter to indicate the orientation.
It should ideally support any angle, so the API should look like:

calibrate(x_angle = 0, y_angle = 0);  

From these two angles the Z angle and the gravity vector are calculatable.
This gravity vector should be "subtracted" from the error, like the Z = 1 you said but now in 3 dimensions.

Think that is a step too much for now, first step is to get it right for a flat lying sensor.
(I will have a look at your PR now)

[RobTillaart]

Looked at the PR and it made 100% sense, so I merged it into the develop branch.
Thanks again!

Are you OK to be mentioned as I want to give credits where they should be?

[mycosd]

Are you OK to be mentioned as I want to give credits where they should be?
Yeah, why not.

I'll try changing the calibrate function as you suggested.

[RobTillaart]

A first version with AZE -= 1 and reset of the gyro integration is preferred. That would give a minimal correct release as reference.

[RobTillaart]

@mycosd
due to circumstances I have little time to dive into it right away, however it is still on (top of) my list.

[RobTillaart]

@mycosd
Did you have time to run some tests with the new calibrate function?
results?

[mycosd]

@mycosd Did you have time to run some tests with the new calibrate function? results?

I've been using it in my project, in just X=0, Y=0 orientation. It does the job. Only tested few other orientations when implementing it.

It gets rid of the major drift, however there is still a smaller drift which appears to come from the internal gyro integration (_gyx, _gyy, _gyz).

[RobTillaart]

Thanks for the update,

[RobTillaart]

it gets rid of the major drift, however there is still a smaller drift which appears to come from the internal gyro integration

The smaller drift is probably related to #47

Will merge the new calibrate into develop, and get it into master asap.

[RobTillaart]

• Merged into develop
• created a PR for the develop branch.

[RobTillaart]

@mycosd
Engineered the calibrate() function a bit

• only sum successful reads, ==> samples counter.
• return false if there are no good reads (zero samples)

[RobTillaart]

@mycosd

Merged the improved calibrate() into master, will release 0.6.1 later today.

In the mean time, I got about 15 new issues (other repos as well) so I need to attend some of them too.
And time is scarce at the moment as I need time for other (non Arduino) tasks too.

So it will take some time to investigate the drift of the sensor (gyroscope integration) which is possibly related to #47.