luisrodenas

I managed to read magnetometer connected to MPU's aux I2C lines while DMP is ON. Check this topic where I left an example in case anyone was looking for this: http://www.i2cdevlib.com/forums/topic/111-arduino-example-sketch-to-read-magnetometer-while-dmp-is-on/ I will try to fuse DMP + magnetometer in a few weeks maybe.

Hello, I am attaching an Arduino example sketch to show how to read a magnetometer (HMC5883L) while MPU's DMP is active. This is only useful if you have your magnetometer attached to MPU's I2C internal aux lines, like many 10DOF boards do, and you want to use DMP. If you can, I believe it is always best to connect your magnetometer to your main I2C lines directly and you won't need this sketch. This sketch does NOT fuse DMP + magnetometer. You will have to do it by yourself in your host processor. I would only try to fuse magnetometer if it is going to be used outdoors, as electromagnetic interferences caused by electronics indoor make it quite difficult. Besides, the DMP's yaw measure is very good if you don't need much precision or long running times, in these cases you should fuse magnetometer + DMP. Please read sketch comments, as many things are explained there. Remember to put your MPU's address (0x68 or 0x69) and to set your interruption pin. Please give feedback, wheter it works or you have trouble with it. If people find it useful maybe Jeff can add it to the library once it is bugfree. Thank you MPU6050_DMP_mag.zip

When you run the DMP example, add this line as shown here: mpu.dmpGetQuaternion(&q, fifoBuffer); mpu.dmpGetGyro(gyro, fifoBuffer); mpu.dmpGetGravity(&gravity, &q); mpu.dmpGetYawPitchRoll(ypr, &q, &gravity); dmpGetGyro will give you angular velocity. Anyway, I believe it is not processed, but the sensor raw reading multiplied by its gain.

Hi rflmota, What arduino are you using? How is your MPU placed when you are running the sketch? It must be completely still. Did you change anything on Jeff's library? Try this: Where the calibration() functions is defined, change the Serial.println("..."); to Serial.print(mean_ax); Serial.print("\t"); Serial.print(mean_ay); Serial.print("\t"); Serial.print(mean_az); Serial.print("\t"); Serial.print(mean_gx); Serial.print("\t"); Serial.print(mean_gy); Serial.print("\t"); Serial.println(mean_gz); Copy what is printed to your console to a file and attach it here.

More info needed. What Arduino are you using? Are you including any other library? Which ones? What board are you using? Some picture or schematic?

I am rigth now working on this matter... As far as I know, DMP cannot fuse HMC5883L's data. So you have to run DMP 6 axis on the MPU, and at the same time read magnetometer measures, and find some ¿? way to fusionate them at your host processor. If I am not mistaken it should be easier to use both sensors independently. In my case I have HMC5883L connected to MPU's aux I2C... and I am still trying to get mag measures while DMP is running, can anyone else give us a hand?

Thanks for the explanation. I think I got it now. Just two more questions: -what is the advantage of using MotionDriver 5.x.x vs older MotionDriver versions? - is this file "MPU6050_6Axis_MotionApps20.h" based on MotionDriver v2.0 or they are different things?

There was somebody in this forum who achieved something similar with a rocket. Check this topic: http://www.i2cdevlib.com/forums/topic/10-why-is-the-dmp-yaw-stable/?hl=rocket#entry30 Taking into account the high Gs and the vibrations that will appear, I think you will have to forget about DMP and accelerometers... I would calibrate giros as best as I can, considering temperature changes and maybe vibrations of a test launch, and then just integrate giros to get yaw, pitch, roll. This measure should be reliable for a few seconds (10 or 20 maybe with good calibration) and then it will start to drift. You can also try to fusionate with accelerometer once rocket motor has stopped and it is falling. Best thing is to ask the guys linked above maybe.

I imagine you are using an xbee library as well? Maybe there is come conflict between both? I believe it should be fine, because Xbee communicates by serial and MPU by I2C... but if you upload your code maybe somebody can give you a hand.

Wow, so many things to try to answer... Bottleneck is your microcontroller, the SD writing and wireless transmission. MPU can go much faster. Do you know you can wire two MPUs at the same I2C bus if each one has a different address? (0x68 and 0x69) And I remember there was somebody in this forum who achieved more MPUs at the same bus using some controller. Yes. I don't really know if offset is applied by sensor or by software, but it is applied. I made a skecth to get this oofsets easily. http://www.i2cdevlib.com/forums/topic/96-arduino-sketch-to-automatically-calculate-mpu6050-offsets/ Offset is accounted, but it is not so straigth-forward, check topic linked before. What precission do you need? 1 second is ok? In that case I would configure both RTC at the same time only once and they should keep time fine for some days maybe? If it is only 30 minutes... maybe you don't even need a RTC and with internal timers since reset you are fine. Maybe you don't even need to time it if both Arduinos are started at the same time, and run their sketches at the same frecuency, and send data as fast as they read it, and receiver reads data very fast and organices it. Btw, what is it for?

So, I understang you made it work using Android program as reference. In terms of functionality and performance, is there any improvement over I2Cdevlib actual library? Apart from it being written in "pure C". Would you share it when it's finished? I didn't understand your last message. You are saying that library does the same you just achieved? All this is only for MPU9150 or MPU6050, or both? Sorry for so many questions....

So you want to get those two measures of that point, angular acceleration and horizontal displacement, rigth? I find it quite difficult. Because translational acceleration will cause problems trying to get pitch and roll, and displacement will drift over time... In case you want to try I would forget about DMP. Set your Arduino to read at the highest frecuency it can, then set that rate to the MPU, and configure de low pass filter to something like 20Hz. Read raw giros and accels and print them with Matlab or similar. Check that accelerometers are not saturating, if they are, change your accel range. Same thing with giros. Once you have that info registered for a period of time (1-2 minutes), you can start to process it. You can integrate accels twice to see what results. About the angular acceleration, I would take giros measure and derive it, instead of integrating twice pitch and roll. I would read everything at highest possible rate, altough you are quite sure it is vibrating at 5-10 Hz. If once you process info you achieve a bad result, then I think you should try other sensor or other methods. Maybe a flashing ligth to get vibration frecuency and something like a IR distance sensor to get displacement?

By default I think the DMP is working with +-2g configuration. Maybe it can be changed, but I don't know how. I would say no. But it depends on how long those Gs are applied. I mean, everytime the accelerometer saturates, DMP's measures will start to drift over time. So if those accelerations are only suffered for a small amount of time (less than a second for example), I believe you should be fine. If acceleration is going to be constant or for long periods of time, forget about DMP. Other users have noticed that DMP drifts while big translational acceleration is applied. If you say what is your application maybe I can be of any more help.

Thanks for the feedback Violinuxer! Sure, I forgot to mention that step, topic edited. I am using several MPUs so I was bored of calibrating all of them by hand.

What are you actually trying to measure? Displacement of some building's points while it vibrates? What is the frecuency of the vibration? I didn't understand why would you need Yaw, pitch, roll. Without having much understanding on the matter, I would put the MPU on top of the building, and only measure acelerometers at the highest possible rate. You can try with different MPU's lowpass filters. Later process that data trying to get that sinusoidal behavior.

Oh oh... this is not nice. Any forum moderator??? Jeff??

If I am not mistaken, what you want to do is to use I2Cdevlib library, maybe update/complete it with things found in those file and use it on Android?? Or are you suggeting that we should take a look at Android's code in order to improve I2Cdevlib library for microcontrollers? I'm confused....

I know this is quite an old topic, but maybe is the rigth place to ask. Jeff, when you say: Do you mean that the DMP inside the 9150 is running a 9 axis sensor fusion algorithm by itself? Or is it running a 6 axis algorithm and later fusionates with magnetometer readings at host? Btw, some extra questions. Can the DMP run at 200Hz instead of 100Hz? Maybe new DMP firmware? I have seen people saying it can, at Invensense's developers corner. (http://www.invensense.com/developers/forum/viewtopic.php?f=7&t=633) And here: (http://harinadha.wordpress.com/2013/07/03/mpu9150datalog) And what does Embedded MotionDriver v5.1 have to do with all this thing? Thank you for your time or anyone's who answer!

I have made an Arduino sketch that simplifies the task of calibrating the MPU6050's offsets. Easy steps: - Wire your MPU6050 to your Arduino. - Put the MPU6050 as horizontal as possible and leave it there, don't touch it. - Check the sketch in order to configure your MPU's I2C address (0x68 or 0x69). - Upload the sketch to your Arduino. - Open Arduino serial monitor and send any character to the Arduino. - Wait. - Write down your offsets for that particular MPU6050 and use them with library's functions "...setoffset..." in your projects. There are also a few options in the code in case you want to fine tune it. There may be bugs, or maybe it does not converge for everyone, so let me know your experience. I use it with an Arduino DUE, configured to 400KHz I2C bus speed, but I think you can use any Arduino and standard bus speed (100KHz). If people find it useful maybe Jeff can add it to the library once it is bugfree. Happy new year. UPDATE 30th January: New version 1.1 available. It fixes a bug related to variables overflowing in Arduinos other than the DUE. MPU6050_calibration_v1.1.zip

First of all you need to calibrate the offsets for the DMP, check this other topic: http://www.i2cdevlib.com/forums/topic/91-how-to-decide-gyro-and-accelerometer-offsett/ To use only the DMP there is no need to apply manual offsets. Just use the functions defined in the library "SetOffset..." as described in the topic I just linked. Once you have the DMP working correctly (check it printing values on screen or something), you can try to use the other functions, as acceleration in real world coordinates, etc. If you are looking for some precision I would not use the function in world coordinates. This is because the yaw measure from the MPU is not really good, as it is not using a magnetometer measure. You can try but it didn't work for me. So I suggest you use the real accel function, in local coordinates. In case you want to rotate the measures to another coordinate system, I would use pitch and roll from the DCM and yaw from the DCM fusionated with another reading from a magnetometer, for example. In my experience, if there are many vibrations where your MPU6050 is located, you will need an extra calibration for the accel measures that return the realaccel function. I have found that this function returns a little offset depending on the frecuencies of this "environmental" vibrations. This is a bit complex and maybe far from your intentions.... Let us know if you achieve it!

Yes, you have to remove that line about TWBR... Then it should work. Check this topic: http://www.i2cdevlib.com/forums/topic/88-mpu-dmp6-with-arduino-due-twbr-not-declared/

BTW, I think you should have started a new thread for your question... :\

Yes, it should be possible. I think you will have to change your I2C frequency to 400KHz (max is 500KHz), only read accelerometers, configure the MPU sample rate to 350 Hz or higher, configure the MPU low pass filter to 175Hz or higher and check the accelerometer range so that it does not saturate. Besides you need an Arduino or similar capable or doing all this and having extra time to process what you want to do with those measures. I guess you should be fine with 16MHz Arduino, but can't confirm because I usually use Arduino DUE (84 MHz). There are 3 ways of reading this info from sensor, but that's other matter. Let me know if you achieve it!

I think it is not possible, at least datasheet says so.

I am sure you have solved it by now. Anyway it is mentioned in the datasheet. You have to divide the temperature reading by 340 and then add +36.53. The result is Celsius. Care because your variable has to be a float, etc.