Does gyroscope requires calibration? (MPU 6050)

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it does, what is the method that i need to follow? This is the datasheet https://media.ncd.io/sites/2/20170721134617/PS-MPU-6000A-00v3.4.pdf

This topic has a solution.
Last Edited: Sun. May 5, 2019 - 11:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doesn't the device have a datasheet? Surely it would explain there wouldn't it?

 

EDIT: Having said that I just typed "MPU 6050 calibration" into Google and it seems to hit a load of stuff, for example:

 

http://wired.chillibasket.com/2015/01/calibrating-mpu6050/

 

Calibrating the Sensor

Just like any sensor, the MPU-6050 needs to be calibrated before it is used for the first time. What we want to do is remove the zero-error; this is where the sensor is totally level, but it thinks that it is angled slightly. Therefore we need to adjust the offsets in order to counteract this error. Fortunately I found a program that can calibrate the MPU-6050 for us! In order to use the program, all you have to do is to upload the sketch and then place the accel-gyro module in a flat and level position. The program will make an average of a few hundred readings and display the offsets required to remove zero error.

Last Edited: Tue. Apr 30, 2019 - 10:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any manual way to do it? Like any formulas for it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I made a subtle suggestion. Perhaps it was too subtle?

 

My point is that you aren't the first person to wire up an MPU 6050 to a micro. Loads of people have done this already and there's a rater nasty trend in the modern age that everyone has to document every last detail of every last thing they have done on the internet. So the internet (accessed via this site called "Google") is awash with stories and articles of others who have done and succeeded in doing what you are attempting. So a few hours/days spent in Google are going to prove very worthwhile.

 

After reading all that then it's possible someone here may be able to answer outstanding questions but as this question is more about MPU6050 than it is about AVR I think your Google research is also going to reveal the sites where the real MPU6050 experts live (I'm assuming they will be on drone/robot development sites in fact).

 

EDIT: for example have you read:  http://www.geekmomprojects.com/gyroscopes-and-accelerometers-on-a-chip/ ?

Last Edited: Tue. Apr 30, 2019 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The MPU 6050 has accelerometer and gyro.

There is lots of information about calibrating an accelerometer in your previous thread

https://www.avrfreaks.net/forum/...

 

The gyro will probably have zero offset as well ie. when it's not rotating it probably won't read exactly zero.

You can compensate for these offsets like with the accelerometer.

Just take some readings with it not moving, that gives you your x,y and z gyro offsets (the orientation doesn't matter).

Anything more than this I think is not so simple for gyro, but  just compensating for the offsets will probably be easily good enough for your application.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understand that a gyro measures SPIN. In any orientation, a non-spinning gyro shows zero on all axes, even if it is moving linearly (steady OR accelerating) [that is, direction is constant, no turning].

 

Without motion, an accelerometer measures ORIENTATION. With motion, it measures orientation plus rate of change of velocity.

 

My Big Question at this point is: What does the gyro give you that you need? It is certainly more complex: you have 3 acceleration axes that take all of the calibration previously described. Plus, you now have 3 axes of spin and each axis has its own offset and calibration factor. So, you have gone from 6 calibration constants to 12. Do you really need it?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Apr 30, 2019 - 07:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ckkkkk wrote:
Any manual way to do it? Like any formulas for it?

clawson wrote:
I made a subtle suggestion. Perhaps it was too subtle?

 

Indeed.

 

The answer is YES, but after reading the datasheet and the associated document regarding the registers there is not much on board to configure from my quick scan of both documents.  So the other answer is you need to calibrate your application to the sensor.

 

As Cliff said, theres a LOT of Google hits out there on this device as its used in many Arduino applications and the like.

 

CLick here:

https://www.invensense.com/produ...

 

Scroll down and you will find the datasheet, and the register maps and description documentation.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a hunch that the choice of accelerometer and calibration are the least of the problems. As a couple of us suggested in the previous thread, why are you worried about calibration on an application that most likely doesn’t require the precision?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

The gyro will probably have zero offset as well ie. when it's not rotating it probably won't read exactly zero.

You can compensate for these offsets like with the accelerometer.

Just take some readings with it not moving, that gives you your x,y and z gyro offsets (the orientation doesn't matter).

Anything more than this I think is not so simple for gyro, but  just compensating for the offsets will probably be easily good enough for your application.

 

Hi MrKendo,

So, what you are suggesting here is just take the average data for the 3 axis while its not moving, then i can get the offsets for the 3 axis. I just do it once without needing the "turn it over" like the accelerometer?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

My Big Question at this point is: What does the gyro give you that you need? It is certainly more complex: you have 3 acceleration axes that take all of the calibration previously described. Plus, you now have 3 axes of spin and each axis has its own offset and calibration factor. So, you have gone from 6 calibration constants to 12. Do you really need it?

 

Jim

Hi Jim,

Most probably the orientation. Although the datasheet says they reduced the need for user to do calibration but i really do think that i need to make the readings close to zero else the readings will drift over time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

The answer is YES, but after reading the datasheet and the associated document regarding the registers there is not much on board to configure from my quick scan of both documents.  So the other answer is you need to calibrate your application to the sensor.

 

As Cliff said, theres a LOT of Google hits out there on this device as its used in many Arduino applications and the like.

 

CLick here:

https://www.invensense.com/produ...

 

Scroll down and you will find the datasheet, and the register maps and description documentation.

 

JIm

Hi jgmdesign,

Yes, there are lots of Google hits out there but most of them are already in source code and do not have any explanation on how to find the offset for it. Therefore, i am seeking for the manual way to do so just like the accelerometer which i can understand.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I have a hunch that the choice of accelerometer and calibration are the least of the problems. As a couple of us suggested in the previous thread, why are you worried about calibration on an application that most likely doesn’t require the precision?

Hi Kartman,

I am worried because if the offsets are not found, then the readings will drift over time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Zero offset and drift are quite unrelated. 

 

In particular, you can calibrate out the zero offset, but that WILL NOT eliminate temperature sensitivity and long term drift. Depending on the device, of course, drift should be minimal and the spec sheet should specify bounds.  More than likely, it will imply, without saying, that the sensitivity will be within some tolerance range of some standard value. Then, by implication, this tolerance should include long term variations. 

 

For this application, I am somewhat concerned that you are spending far too much time and energy on something you don't need to do. For example, during a fall, it it probably sufficient to detect that all 3 axes are under 1/3 or 1/4 g. The only way you can have anything close to this is to be in free fall. E.G. the user is falling. Odds are, subsequent to this, finding that the normal gravity axis indicates less than 1/2 g or so might be sufficient. Pretty simple criteria and they are gross enough that you don't need to worry about either zero offset or full scale calibration. I may be over-simplifying it a bit, but I'll bet its not by much!

 

Also, as I mentioned above, a gyro reads out spin RATE (that is, so many degrees per second) for each axis. That says NOTHING about orientation. There will probably be rotation during a fall, but there will also be rotation during normal movement. I personally doubt that a gyro will give you useful information for this application.

 

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. May 1, 2019 - 06:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if it drifts over time, then what difference does knowing the offsets make? If you do some Googling, you might find some manufacturer’s papers on how they’re made and what causes the offsets etc. once you understand this, it should become clear.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Zero offset and drift are quite unrelated. 

 

In particular, you can calibrate out the zero offset, but that WILL NOT eliminate temperature sensitivity and long term drift. Depending on the device, of course, drift should be minimal and the spec sheet should specify bounds.  More than likely, it will imply, without saying, that the sensitivity will be within some tolerance range of some standard value. Then, by implication, this tolerance should include long term variations. 

 

For this application, I am somewhat concerned that you are spending far too much time and energy on something you don't need to do. For example, during a fall, it it probably sufficient to detect that all 3 axes are under 1/3 or 1/4 g. The only way you can have anything close to this is to be in free fall. E.G. the user is falling. Odds are, subsequent to this, finding that the normal gravity axis indicates less than 1/2 g or so might be sufficient. Pretty simple criteria and they are gross enough that you don't need to worry about either zero offset or full scale calibration. I may be over-simplifying it a bit, but I'll bet its not by much!

 

Also, as I mentioned above, a gyro reads out spin RATE (that is, so many degrees per second) for each axis. That says NOTHING about orientation. There will probably be rotation during a fall, but there will also be rotation during normal movement. I personally doubt that a gyro will give you useful information for this application.

 

Jim

 

 

Hi Jim,

From what you are suggesting is that, i should bear with the offsets? As you mentioned once fall, the readings from the 3 axis will be big enough for me to observe because it will be different than usual activities ? Also, if fall occurred, certain values will be crossed and we can suspect that a fall has occurred but with the gyro, we can be certain that a fall really did occurred.

 

Edit : Typo

Last Edited: Wed. May 1, 2019 - 05:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
if it drifts over time, then what difference does knowing the offsets make? If you do some Googling, you might find some manufacturer’s papers on how they’re made and what causes the offsets etc. once you understand this, it should become clear.

Hi Kartman, 

Erm, making the reading close to 0 with the offsets so that i can reduce the amount of drifting over time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might want to explain that to me. The offset doesn’t magically counter drift over time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
You might want to explain that to me. The offset doesn’t magically counter drift over time.

Hi Kartman, 

What i meant was, the drift will be in smaller number instead of big number.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, not true.

 

The drift (e.g.  CHANGE in value) will be the same, whether corrected or not. It will just be a change in a small value rather than the same change in a somewhat larger value.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but will the gyro, we can be certain that a fall really did occurred.

???

 

Some accelerometers have built-in free-fall detection, with an interrupt generation.

If that is your goal, then it might be easier to simply select an accelerometer that provides you the signal (data) you need.

 

Free fall detection is often determined, IIRC, by checking the vector sum of the 3 axis's G forces.

 

A gyro isn't necessary to detect free fall, and in fact one can easily imagine an object falling without a rotational component to the fall.

 

Cheap accelerometers have a lot of noise, and one can't integrate their signal for velocity or position for any meaningful period of time.

Hence, for projects like drone position and navigation one can incorporate the gyro data with the accel, GPS, and barometer data, etc., (typ. Kalman filter), for the control system.

 

I think it would be helpful if you described what your overall project / task is.

 

JC

 

Edit: Typo

 

 

Last Edited: Wed. May 1, 2019 - 03:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

No, not true.

 

The drift (e.g.  CHANGE in value) will be the same, whether corrected or not. 

 

Jim

Hi Jim,

Okay.

 

ka7ehk wrote:

It will just be a change in a small value rather than the same change in a somewhat larger value.

Also what do you mean by this?

Last Edited: Wed. May 1, 2019 - 05:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi JC,

DocJC wrote:

but will the gyro, we can be certain that a fall really did occurred.

???

That is a typo and i have edited the reply. FYI its "with" not "will".

 

DocJC wrote:

but will the gyro, we can be certain that a fall really did occurred.

???

 

Some accelerometers have built-in free-fall detection, with an interrupt generation.

If that is your goal, then it might be easier to simply select an accelerometer that provides you the signal (data) you need.

 

Free fall detection is often determined, IIRC, by checking the vector sum of the 3 axis's G forces.

 

A gyro isn't necessary to detect free fall, and in fact one can easily imagine an object falling without a rotational component to the fall.

 

Cheap accelerometers have a lot of noise, and one can't integrate their signal for velocity or position for any meaningful period of time.

Hence, for projects like drone position and navigation one can incorporate the gyro data with the accel, GPS, and barometer data, etc., (typ. Kalman filter), for the control system.

 

I think it would be helpful if you described what your overall project / task is.

 

JC

I am developing a fall detection system using raspberry pi. I need to use the accelerometer to detect the G-force in order to detect the fall and i have planned to use the gyroscope as well to detect fall as i can get the orientation before and after the fall.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your using an Rpi and you are here asking for help? WTH?

Jim

Edit: well it is the general electronics forum so heave ho...lol

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Wed. May 1, 2019 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My point in all this is that you probably need to know axis accelerations only within 1/4g or so. That is, is the acceleration greater or less than (about) 1/4 g? If all axes are less than 1/4 g, it is falling. No other way to get ALL axes that low unless in free-fall. With that kind of test, you really do not need zero offset calibration. And, you probably do not need full scale calibration, either.

 

Gyro will NOT give orientation. It only gives RATE OF ROTATION. Once motion has stopped, the accelerometer will have all of the orientation information. Gyro will only tell you if the body is rotating as it falls or if it is rolling on the floor/ground

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

My point in all this is that you probably need to know axis accelerations only within 1/4g or so. That is, is the acceleration greater or less than (about) 1/4 g? If all axes are less than 1/4 g, it is falling. No other way to get ALL axes that low unless in free-fall. With that kind of test, you really do not need zero offset calibration. And, you probably do not need full scale calibration, either.

Hi Jim,

But this only works for free-fall?

 

ka7ehk wrote:

Once motion has stopped, the accelerometer will have all of the orientation information. 

And how exactly can i do to find out that?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

By reading each axis of the accelerometer. Thats all you need.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

By reading each axis of the accelerometer. Thats all you need.

 

Jim

Hi Jim,

Okayyyy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

The MPU 6050 has accelerometer and gyro.

There is lots of information about calibrating an accelerometer in your previous thread

https://www.avrfreaks.net/forum/...

 

The gyro will probably have zero offset as well ie. when it's not rotating it probably won't read exactly zero.

You can compensate for these offsets like with the accelerometer.

Just take some readings with it not moving, that gives you your x,y and z gyro offsets (the orientation doesn't matter).

Anything more than this I think is not so simple for gyro, but  just compensating for the offsets will probably be easily good enough for your application.

 

Hi MrKendo,

According to your suggestion, are these correct?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, X axis is the gravity axis. Those readings are the full scale readings ("contaminated" by offset). Y and Z readings DO give you offset. 

 

To get X offset, either orient it so that the X axis is at right angles to gravity, or turn it over and do the sum and difference dance to get offset AND full scale value.

 

I am really puzzled. We have been over this several times and you don't seem to be "getting it". What more can we do?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. May 2, 2019 - 04:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

ka7ehk wrote:

No, X axis is the gravity axis. Those readings are the full scale readings ("contaminated" by offset). Y and Z readings DO give you offset. 

Hi Jim,

So, the Y and Z axis offsets are good to go?

 

ka7ehk wrote:

To get X offset, either orient it so that the X axis is at right angles to gravity, or turn it over and do the sum and difference dance to get offset AND full scale value.

Jim

X-Axis of Rotation : -357
X-Axis of Rotation : -369
X-Axis of Rotation : -344
X-Axis of Rotation : -340
X-Axis of Rotation : -372
X-Axis of Rotation : -352
X-Axis of Rotation : -357
X-Axis of Rotation : -349
X-Axis of Rotation : -362
X-Axis of Rotation : -376

These are the data i get when x-axis is at the right angle to gravity. Total = -3578, Average = -357.8 and?

 

ka7ehk wrote:
I am really puzzled. We have been over this several times and you don't seem to be "getting it". What more can we do?

I am really sorry for all these, but i really do believe that this is one of the inevitable step i need to take in order for me to continue on my project..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a minute now. Took a look at the spec sheet.

 

When you say "X axis of rotation", is that gyro reading or accelerometer reading? Your terminology is confusing (or incomplete).

 

The spec sheet shows the Z axis as the axis through (e.g. normal to) the face of the chip. X is through one of the  two edges. So, things don't add up.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. May 2, 2019 - 05:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Just a minute now. Took a look at the spec sheet.

 

When you say "X axis of rotation", is that gyro reading or accelerometer reading? Your terminology is confusing (or incomplete).

Its the gyro reading.

 

ka7ehk wrote:

The spec sheet shows the Z axis as the axis through (e.g. normal to) the face of the chip. X is through one of the  two edges. So, things don't add up.

 

Jim

Alright.

Last Edited: Thu. May 2, 2019 - 05:57 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your readings from #28 look believeable if they are gyro radings from MPU6050.

If I remember correctly, MPU6050 outputs signed 16 bit values (-32768 to +32767), so a reading of around 350 is about 1% of full scale.

Seems possible.

So, yes, that gives you your gyro offsets.

However, based on what others have said, these offsets are likely to change over time.

So, to be of much use, you might have to recalibrate from time to time.

I don't know how quickly and by how much they are likely to change.

You could do some experiments to find out.

Alternatively, don't worry about the calibration.

An error of a few % probably doesn't matter.

 

As I said before, when you start writing the code it makes sense to include variables for these offsets, but to start with you can just set them to 0.

Adding or subtracting 0 is pretty harmless!

You can then implement calibration later if you ever need it.

 

I think you are going to find it very challenging to implement your fall detection application (lots of maths involved), but I wish you luck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrKendo wrote:

Your readings from #28 look believeable if they are gyro radings from MPU6050.

If I remember correctly, MPU6050 outputs signed 16 bit values (-32768 to +32767), so a reading of around 350 is about 1% of full scale.

Seems possible.

So, yes, that gives you your gyro offsets.

However, based on what others have said, these offsets are likely to change over time.

So, to be of much use, you might have to recalibrate from time to time.

I don't know how quickly and by how much they are likely to change.

You could do some experiments to find out.

Alternatively, don't worry about the calibration.

An error of a few % probably doesn't matter.

 

As I said before, when you start writing the code it makes sense to include variables for these offsets, but to start with you can just set them to 0.

Adding or subtracting 0 is pretty harmless!

You can then implement calibration later if you ever need it.

 

I think you are going to find it very challenging to implement your fall detection application (lots of maths involved), but I wish you luck.

Hi MrKendo,

That means i can now set xGyroOffset = -351.8, yGyroOffset = -18.9, zGyroOffset = -93.6?