Better MPU6050 support

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Better MPU6050 support

Post by Sebbi »

Hi there,

I am sure lots of you are flying with an IMU that uses the MPU6050 (FreeIMU? NanoWii?) and nobody really considers taking apart a Wii motion controller and nunchuck to build a quadrocopter anymore. How about better support for this chip? I start ;-)

https://github.com/sebastianherp/multiw ... pu6050_dmp

This branch is where I wanted to experiment with DMP code, but my first try was to get all sensor data from the MPU in one i2c read instead of 3 separate ones (or 4 if you count those 2 consecutive gyro reads in computeIMU()). It results in a littlebit over 900 bytes savings for the binary sketch size and is 400 to 500 µS faster despite getting new magnetometer values on EVERY cycle. And you get gyroTemperature for free if you want to display it somewhere ;-)

Next up: DMP code

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Better MPU6050 support

Post by Alexinparis »

Sebbi wrote:(or 4 if you count those 2 consecutive gyro reads in computeIMU())

You know, the "magical" 650 micro seconds + the way to smooth the gyro values explains perhaps why multiwii is so stable in acro mode ;)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

I haven't flight tested it yet. Maybe this "magic" is what makes it stable, but maybe it doesn't work that way at all with the MPU6050? Gyro_init() sets it to a 1 kHz sample rate, so there will be a new value in the registers (all registers: gyro, acc, mag, temp) every 1000 µs. No reason to read it out any faster than this, right? For the MPU both values should nearly always be the same, except for the cases where the MPU samples new data right between those two calls (in the magical 650 µs).

You can configure the gyro to run at 8 kHz, but I doubt precision will get better with higher sample rates. Acc will always run with 1 kHz max. And if low pass filters are set - and they are with a default of 256HZ - the effective sample frequency is even lower than 1 kHz because the MPU does the smoothing for you.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Better MPU6050 support

Post by Alexinparis »

Sebbi wrote:I haven't flight tested it yet. Maybe this "magic" is what makes it stable, but maybe it doesn't work that way at all with the MPU6050? Gyro_init() sets it to a 1 kHz sample rate, so there will be a new value in the registers (all registers: gyro, acc, mag, temp) every 1000 µs. No reason to read it out any faster than this, right? For the MPU both values should nearly always be the same, except for the cases where the MPU samples new data right between those two calls (in the magical 650 µs).

You can configure the gyro to run at 8 kHz, but I doubt precision will get better with higher sample rates. Acc will always run with 1 kHz max. And if low pass filters are set - and they are with a default of 256HZ - the effective sample frequency is even lower than 1 kHz because the MPU does the smoothing for you.


I agree, this data cooking was never rethink since the first implementation with WMP.
And now we have access to some internal tuning functions via LPF of BW setting.
I don't think you can expect a substantial stability improvement, but it's worth trying

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

I have to correct myself. With the default DLPF value the sample rate of the gyro is indeed 8 kHz ... it's only 1 kHz when some other value than the default DLPF is chosen.

I agree with you on stability improvements. It just runs faster and results in smaller code. What I set out to do was running DMP code with MultiWii and see how this performs for angle/horizon mode ;-)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

DMP code is a tricky thing ... I think I can get it to work and it can output orientation quaternions (with unknown precision and this propbably also needs calibrations and we know nothing about what the DMP really does?) AND gyro data at the same time, so it is possible to have the normal acro mode and replace getEstimatedAttitude by this. Because of the rather huge DMP binary code I think this wont be smaller, but probably faster, than the current way to calculate attitude. We'll see ... i've read on diydrones, that Invensense at least changed their license so it is ok for open source to use DMP code. It is still very undocumented, however :/

yoan1509
Posts: 5
Joined: Fri Oct 19, 2012 5:20 pm
Location: France

Re: Better MPU6050 support

Post by yoan1509 »

Hello, I'm new to this forum but I follow the evolutions for a while.
I wish you good luck for this development, which seems to me very interresting... ;)

mahowik
Posts: 332
Joined: Sun Apr 10, 2011 6:26 pm

Re: Better MPU6050 support

Post by mahowik »

Hi Sebbi !
It's really quite cool what you are doing! Don't stop on this! Thanks a lot!
You know, if you doing this OPEN, a lot of eyes see you... ;)

Really, I'm very appreciate on your effort! Many thanks!
Alex

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

I am doing this open, but haven't push recent commits to Github, because it doesn't work yet (the DMP part that is). I was trying to adapt the i2cdevlib implementation for MultiWii (https://github.com/jrowberg/i2cdevlib), but found out Arducopter/Ardupilot has a nearly complete implementation of DMP code already (experimental and they talk to it via SPI instead of I2C): http://code.google.com/p/ardupilot-mega ... PU6000.cpp

They use it in parallel to the existing code at fixed 200 Hz sample (and DMP) rate.

From those code examples I found out:
- there are some calibration registers to set gain, bias and alignment (??) for all the sensors
- 9 axis fusion should be possible, but I haven't found a working implementation (with FreeIMU) yet
- DMP and sensors are separate entities, so it's possible to use DMP for quaternions and still read out sensor data via normal registers ... or you get those values from the FIFO
- the FIFO is a nice concept where you can expect new values every x µs ... since the buffer is quite large it's unlikely to miss values, so integration of acceleration to support alt hold (baro) and position hold (GPS) at fixed time intervals should be possible even if we don't retrieve the data from the FIFO at fixed time intervals
- from the examples (i2cdevlib) it looks like drift is an issue, but settles few seconds after initialisation. Maybe the DMP has some auto calibration feature (that would be nice for mag) or it's just the Kalman filter effect.

Invensense should release documentation for this feature ... damn it ;-) It seems to be very powerful, but nobody is really using it ... well over a year after this sensor was announced :/

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Better MPU6050 support

Post by timecop »

There is nothing special about i2cdevlib or whatever.
you can access DMP just the same as you access any sensor in mwc now.

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

@timecop:
I know that, but i2cdevlib has a complete implementation AND example of 6-axis sensor fusion, so it was a good starting point for me ;-)

Hmm ... looks like full source code for everything regarding the use of DMP is available in the Invensense developer section ... and it is huge, but it's all there and documented as far as variable names and some code comments go.

P.S.: What is the open source license of MultiWii? The license agreement of Invensense states that it is not allowed "to take any actions that would cause the Software or any portion thereof to become subject to the GNU General Public License or any other open source license that imposes any limitation, restriction or condition on the right or ability to use, license or distribute the Software or any portion thereof." But diydrones.com says it's open source compatible (http://diydrones.com/profiles/blog/show ... e=activity) ... well, I'm no lawyer ;-)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Better MPU6050 support

Post by copterrichie »

Glad someone is taking the time to read the fine print!! Kudos!


Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

We are working on incorporating this DMP info into future product register maps, there may also be a standalone document created. We will notify you when the documentation is ready.


From Invensense developer support. That's better than anything I heard from them before ;-)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Better MPU6050 support

Post by copterrichie »

Question please: What effects if any does the temperature have on the performance or sensitivity on the MPU6050?

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

http://www.invensense.com/mems/gyro/doc ... -6000A.pdf

Page 12 for the gyro, tl;dr: +-2% sensitivity scale factor variation over temperature and +-20 deg/second variation of the bias (zero level) value over -40 to +85 °C ... btw: cross axis sensitivity is also at +- 2%

Page 13 for the accelerometer, tl;dr: sensitivity change (scale factor) at +-2 g setting is +-0.02%/°C ... not enough to cause problems with attitude estimation, but enough for velocity/position integration errors to sum up quickly. Bias change between 0 and 70°C is 35 mg in x/y axis and 60 mg in z axis. That's a 6% change when the z-axis is aligned with gravity (normally the case for a multicopter) for the full range and might be a 2-3% change for indoors 25°C to outdoor 5°C which explains mahowiks "problems" with the fixed acc_1g variable.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Better MPU6050 support

Post by copterrichie »

Thank you, I believe (not sure) I am experiencing something similar, need to confirm it. Seems on cold mornings, Mollie picks up a wobble but as the day warms up, it goes away. Weird.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Better MPU6050 support

Post by copterrichie »

Going to try this, power up the electronics, let it sit for a few minutes, then power off, then back on so the gyro can recalibrate or use the stick combination to calibrate it.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Better MPU6050 support

Post by copterrichie »

copterrichie wrote:Going to try this, power up the electronics, let it sit for a few minutes, then power off, then back on so the gyro can recalibrate or use the stick combination to calibrate it.


I need to validate my findings from this morning testing with a few more cold morning start ups however, allowing the Electronics warm up, then Recalibrate SEEMS to be the answer for me.

User avatar
IceWind
Posts: 115
Joined: Fri Mar 25, 2011 2:11 am
Contact:

Re: Better MPU6050 support

Post by IceWind »

Get the temperature reading from the atmega and use it to compensate the drift. :)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

You can get the temperature from the gyro (see code linked in the first post of this thread). Can't do much in November, since I am not at home most of the time. Feel free to pick up the idea presented here and improve upon it ;-)

User avatar
jstapels
Posts: 23
Joined: Sun Mar 04, 2012 8:50 pm
Location: Software Engineer

Re: Better MPU6050 support

Post by jstapels »

Doesn't Fabio's latest FreeIMU library take temperature into account as well as using the DMP fusion code? I never dug through the code but assumed MW already used all this since Fabio's released the very first MW patch way back he released FreeIMU v4.

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: Better MPU6050 support

Post by QuadBow »

Hi all,

Even if I am quite new to this forum, I have been interested in the further development of the source for a while.
Therefore, I have already been following this thread and other threads questioning how to take out the best of the MPU6050.
In my view the facts as to the MPU6050 are as follows:

1. The MPU6050 is an excellent sensor like it is implemented as of today.
2. Furthermore, the MPU6050 is able to collect i2c data of other devices (eg compass)
Due to the following calculation this can save roughly 100us time (3 requests of 2 bytes header plus 6 bytes data result in 24 bytes which last 500us at 400kbaud - a single request of 2 common header bytes plus 18 bytes data result in 20 bytes which last 400us) each cycle. The additional gyro sampling in imu.ino is required in any case and therefore doesn't impact the difference. 100us sound nice, but I think there is a greater potential since the processor is waiting 400-500us for the i2c device each cycle. Furthermore, there might be an issue with long lasting i2c readings since the function "waitTransmissionI2C" blocks the FC maybe for 400us. Maybe it's better to wait 3 times for 166us than one time for 500us. So at that stage I don't see that great advantage reading in all sensor data at one strike.

My question related to the i2c request would be: Has anyone tried to inmplement an interrupt driven i2c routine ? At the first glance however this could require a change of the program structure like using a fix cycle time approach.

3. The MPU6050 can run a binary code to initialise the Digital Motion Processor (DMP) for sensor fusion.
This is an undocumented feature which already has been proven partially.
However, this approach leads to a maximum sample time of quite high 5ms, which doesn't match to the 650us delay between
the two measurements in imu.ino. So, a significant change in the program would be the result (eg fix cycle time 5ms).
In principle I support the idea to let the stronger processor on the MPU do the extensive work of angle calculation.
However, the current implemenations of DMP result in 4 quaternions of 4 byte each which don't cover the compass sensor data. The required i2c and FIFO processing time should be more or less the same as before. Only the time for complemantary filter calculations would be saved.

Now the question arises: What about the quality of the resulting data? Is it worth to go for that approach?
Since the sensor fusion algorithm is quite undocumented (Is it a more or less another kind of complementary filter? Are extended algorithms like kalman filtering used?) this question can't be answered right now.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Better MPU6050 support

Post by Hamburger »

from others' statements it seems your last paragraph sums up the current situation. Little is known beyond current status, info is not easy to get by.
So it is free open space for you to explore (where noone has gone before) ...

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

I agree with your last point, QuadBow. The DMP feature is undocumented and and not fully understood and it might not save much time at all while the current algorithm (used by MultiWii) is already pretty fast and accurate in standard situations. Some flipping and incorrect angles occur in different (static) situations, but I am sure the code can be modified to fix this (doesn't concern normal flight with a copter, but could be problematic for fixed wings).

About the first part: I am not sure why a seconds gyro reading is needed. One sample taken every 2-3 ms should be good enough, especially when smoothing/LPF is used and those two values get smoothed anyway, so just use LPF on the MPU for the same effect.

Interrupt driven sensor reading sounds interesting ;-)

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

Amazingly Invensense just released a new version of their "Embedded Motion Driver" which has somewhat decent documentation included and seems to be independent of the used microcontroller architecture. It supports 6 DOF sensor fusion, some calibration methods and who'd new that when the DMP is active there is always a pedometer running on it ;-)

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: Better MPU6050 support

Post by QuadBow »

Sebbi wrote:Amazingly Invensense just released a new version of their "Embedded Motion Driver" which has somewhat decent documentation included and seems to be independent of the used microcontroller architecture.


Are you entitled to make the documentation available to us or has everybody who registers at Invensense's developer forum to sign a non-disclosure agreement?

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

There is no NDA I am aware of and everybody can sign up and download/read it.

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: Better MPU6050 support

Post by QuadBow »

Sebbi wrote:There is no NDA I am aware of and everybody can sign up and download/read it.


I signed up and also signed the additional agreement, but I am currently not entitled to view any of the documents.
My question as to it to invensense's support is still pending (of course, it is weekend...)

Sebbi wrote:Amazingly Invensense just released a new version of their "Embedded Motion Driver" which has somewhat decent documentation included and seems to be independent of the used microcontroller architecture. It supports 6 DOF sensor fusion, some calibration methods and who'd new that when the DMP is active there is always a pedometer running on it ;-)


Before this issue will be resolved, I got some quesions to you, Sebbi:
Does that mean that DMP and sensor fusion is now officially supported?
Are you planning to port the code to multiwii?

Best

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: Better MPU6050 support

Post by Sebbi »

It still is a black box, so we don't really know what the DMP does internally. And for 9-axis fusion (with magnetometer) you still need to do some stuff for youself. Also the highest frequency for sensor fusion data is 200 Hz which might be perceived as too slow by the MultiWii community (no matter the fact that other copter fly fine with 100 Hz). I'd say it's not worth the effort but an interesting project if you want to have fun with mystery DSP stuff ;-)

Lalitha
Posts: 3
Joined: Fri Sep 19, 2014 4:51 pm

Re: Better MPU6050 support

Post by Lalitha »

Hello everyone!

I was wondering if anyone of you can help me find the data sampling frequency of the accelerometer and gyroscope in flyduino nanowii board. I read in one of the blogs that the sampling frequency is 1 KHz (the values of the 6 axes get updated every 1ms). But I am not able to find any specific mention of the sampling frequency in the multiwii code. Can anyone please help? Am a bit desperate!

Thanks a lot!
Lalitha

waltr
Posts: 733
Joined: Wed Jan 22, 2014 3:21 pm
Location: Near Philadelphia, Pennsyvania, USA

Re: Better MPU6050 support

Post by waltr »

If I remember properly, the sampling and LPF is done within the 6050 chip. So look for the MW code that does the setup of the 6050 then study the 6050 data sheet to interpret the setup commands.

Lalitha
Posts: 3
Joined: Fri Sep 19, 2014 4:51 pm

Re: Better MPU6050 support

Post by Lalitha »

Thank you! Will try and let you know my findings :)

Post Reply