Electrical – MPU 6050 Digital Motion Processor Gyro Units

accelerometergyroscopemotion

I'm running into an odd issue with a motion control processor (MPU 6050 / 9150) that is returning raw gyroscope values as specified between the -/+ 32768 which in the way this gyro is configured corresponds to -/+ 2000 deg / sec. This makes total sense as this goes along with the specified documentation.

However, when I process data from the digital motion processor (6 axis sensor fusion) I get a maximum of 1429. I don't think that there's an error reading the data from the MPU buffer as the other measurements look good (reading from the same FIFO buffer). I assume this is likely some units issue that has to do with the 6 axis sensor fusion, and also likely involving radians

Wondering if any of you bright people with your light bulb brains have some insight here?

Best Answer

So it turns out that my dmp packet structure is off from the specification.

The DMP returns a 48byte packet, and the accelerometer and gyroscope values coming out are 32 bit integers. When handled improperly this gives scaled and wrong data.

    /* ================================================================================================ *
 | Default MotionApps v4.1 48-byte FIFO packet structure:                                           |
 |                                                                                                  |
 | [QUAT W][      ][QUAT X][      ][QUAT Y][      ][QUAT Z][      ][GYRO X][      ][GYRO Y][      ] |
 |   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  |
 |                                                                                                  |
 | [GYRO Z][      ][MAG X ][MAG Y ][MAG Z ][ACC X ][      ][ACC Y ][      ][ACC Z ][      ][      ] |
 |  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  |
 * ================================================================================================ */

Related Solutions

Electronic – IMU (gyro + accelerometer) breakout board with integrated Kalman filtering

I've worked on a project to implement the Kalman filter on an embedded system that was similar in hardware to the iNemo unit from STMicroelectronics.

Even if you can find these IMU (Inertial Measuring Unit) with 90% chance you will have to implement your algorithm by yourself; or if you're lucky, you can find someone that has the code. The problem is that this filter requires a lot of computation, and in our best experiment (using fixed point variables and trying to optimize the code) we were able to run it 45 times per second, in a STM32 at 72 MHz.

So maybe there is one, but as far as I know requires a good microcontroller or maybe a FPGA\ASIC.

Electronic – MEMS Gyroscope BMI055 – random high spikes in data

Edit: I found the cause of the spikes. The BMI055 chip is internally flawed, I am sure of it now. If you read out the FIFO in Bypass mode (that means only one frame is kept) then you have to expect data errors. If you read it faster than the sampling rate you receive 10% 0x8000 (smallest possible number) in the mix. Not zero, not the last value .. a MAXIMUM value!

If you read the data a bit slower than the sampling rate, you receive valid data with 1-8 spikes per second.

This happens if you use the FIFO register in 6 or 8 byte burst mode.
Now I got curious, I read the 0x02 register in 6 byte burst and this gives the same data (x,y,z) and I changed absolutely nothing else.
The spikes are reliable gone.

previous text:

It seems that the gyroscope itself is flawed and it is not just that one.

I first expected an error in I2C communication, turned down the speed and exchanged the voltage shifting circuit without any change in results.

Now as I identified the problem to come from random high spikes I could also find many other people with similar issues or reports.
Surprising fact is that there are rarely any answers.

My first test was a moving exponential average filter, but as I expected that ruins many subsequent readings and only dampens the spikes.

The best solution I can think about is to use two gyroscopes, that is what I will do longterm. They will likely both have spikes and by comparing both frames with each other it should be possible to get a very good result and no spikes.

The simple solution is to filter spikes based on a hardcoded max-change value.
I first considered capturing data at twice the current rate and then always lagging behind one frame.
That way I would know the 'future' and the past, if the 'current' data is way off from future and past it is a spike (or someone hit a hammer on the sensor).

But for gyros with high degree/s resolution and pratical use outside of 2000deg/sec the filtering can be easier.
I played around and was shaking the gyro heavily, the raw values rarely exceeded +10k and no matter what I did they did not have any such sudden changes, even during a drop on the table.
I use this now:

if (abs(old-current)>0x3000) use_value();

So if the result is off by more than 12,000 raw values in comparison to the previous value than the previous value will stay in the variable. Otherwise the variable is updated with the new value.

Now I have a quite low drift which even works for many minutes.

Sidenotes about the used gyro:
a) The BMI055 gyroscope is specified to return ZERO if you sample it too fast, in reality it returns random values. b) The BMI055 gyroscope crashes the I2C bus if you send a soft_reset to it (the onchip ACC doesn't do that) c) Sudden spikes are not described in the datasheets of the gyros and still many people notice them. That's quite strange.

I would appreciate a better answer, maybe I am wrong.
However, the spike filtration made my program work quite reliable compared to the unusable results earlier.

Best Answer

Related Solutions

Electronic – IMU (gyro + accelerometer) breakout board with integrated Kalman filtering

Electronic – MEMS Gyroscope BMI055 – random high spikes in data

Related Topic