Kuba

Your code is very strange. The easiest way to do the integration is this: float velocity = 0; float currAccel; float prevAccel = 0; unsigned long prevTime = millis(); unsigned long currTime; void loop() { //other stuff //refresh currAccel currTime = millis(); velocity += (currAccel + prevAccel)/2*(currTime - prevTime)/1000; //1000 added to get the same units prevAccel = currAccel; prevTime = currTime; } But this will give you a "drift problem". The results won't be even close to good. That are my results. Sensor was not moving during data integration. As you can see the velocity is growing despite the fact that MPU was stationary.

Unfortunately you cannot do much about it. It is a well known issue. A quote from wikipedia http://en.wikipedia.org/wiki/Inertial_navigation_system: You can find also useful information in this talk: Especially parts starting at 18:40 (single integration) and 23:40 (double integration).

It seems ok and you are getting OUTPUT_READABLE_REALACCEL. You are doing almost the same that is done by this functions: Your code contains the same logic, but written in slightly different order (but if you look closely you will see the same multiplications, shift operations, subtractions etc). I just think that my suggestions would make the code much easier to read.

One of these two is exactly what you want, because it should return 0 values when MPU is stationary. The only difference should be axes: If MPU6050 is stationary then it will return 0 (almost 0) in all three axes. You just have to use the code from lines 324-352 (or copy/modify it). If you want to have the teapot example and these values you can modify the code like this: Now you should be able to use world acceleration data inside teapot demo. Just be careful because teapot array structure has been slightly modified.

I know that this is an old topic but just the information for the future generations. I was using the same board GY-87 with BMP180 and I was able to use BMP85 library without any changes. BMP180 and BMP85 have the same "software" (probably also all the registers are the same, but I wasn't comparing them so accurately). BMP180 is just a later version that is more accurate.

Hi, I think that you want to get exaclty the same thing that is implemented in the example file You have to uncomment one of this definitions: and you will get acceleration without gravity. Check lines 324-352 to see what is exaclty happening.

Hi! Did you manage to solve the problem? I have exaclty the same problem with one of my MPU6050 (breakboard GY-87). It slides for about 6 seconds and after that the readings are constant. On the other hand my second MPU6050 on GY-521 is working fine from the very begining right after start up. I am using DMP.

Regarding your first question: I don't have DUE but this site: http://arduino.cc/en/Reference/attachInterrupt says that it should be possibe. So just use another pin and change this fragment of code: attachInterrupt(0, dmpDataReady, RISING); To be honest I didn't understand the second question.

You should call this functions once: accelGyroMag.setFullScaleGyroRange(MPU9150_GYRO_FS_1000); accelGyroMag.setFullScaleAccelRange(MPU9150_ACCEL_FS_4); You can put them at the end of setup(). Check out MPU9150.cpp for detailed description and more useful functions. BTW This is MPU6050 topic, so this should be theoretically moved to MPU9150.

Hi, I know that there are some eamples showing how to put magnetometer data into DMP. For example this one: http://www.i2cdevlib.com/forums/topic/111-arduino-example-sketch-to-read-magnetometer-while-dmp-is-on/ but it does not make any sensor fusion. I couldn't find any library which would make magnetometer fusion inside DMP. Does such library exist? Maybe code in this file MPU6050_9Axis_MotionApps41.h make DMP+magnetometer fusion? I couldn't find any tips in the code and right now I am not able to test it. So the question is: does such library exist or the only way to do this is to make own fiters (for example complementary filter)? Maybe there is some MPU9150 library that can be used with MPU6050+magnetometer?

What does ledPin7 and ledPin6 exactly mean? Is is some RGB led? I suppose that ledPin6 means red and ledPin7 means green. You have written that you got this color sequence: - red - green - yellow and green blinking The problem is probably that you are not always turning off your leds. I have added two "else" with comments. if ( ypr[0] * 180/M_PI < 90) { if(currentMillis - previousMillis > interval) { // save the last time you blinked the LED previousMillis = currentMillis; // if the LED is off turn it on and vice-versa: if (ledState == LOW) ledState = HIGH; else ledState = LOW; // set the LED with the ledState of the variable: digitalWrite(ledPin6, ledState); } } else { digitalWrite(ledPin6, LOW); // this turns this led off, beacuse we want to blink another led } if ( ypr[0] * 180/M_PI > 90) { if(currentMillis - previousMillis > interval) { // save the last time you blinked the LED previousMillis = currentMillis; // if the LED is off turn it on and vice-versa: if (ledState == LOW) ledState = HIGH; else ledState = LOW; // set the LED with the ledState of the variable: digitalWrite(ledPin7, ledState); } } else { digitalWrite(ledPin7, LOW); // this turns this led off, beacuse we want to blink another led } I guess that you color sequence was: - red was blinking and later it turned off - green was blinking but it didn't turn off (because you tilt your sensor while it was on) - green was on and red was blinking what causes green+yellow (becasue red+green=yellow)

I managed to solve this. The problem was reading to many bytes as once. I was reading always the same amount of bytes (64 as this is the size of my buffer) but used only 42 (as this is the default size of DMP packet). As a result bytes were removed from FIFO without actually using them. I will also answer the question I asked above: what is the proper way of working this function: int8_t I2Cdev::readBytes(uint8_t devAddr, uint8_t regAddr, uint8_t length, uint8_t *data, uint16_t timeout) It should read length bytes starting from register number regAddr at once. I am not sure why it works fine while reading bytes from FIFO. We are reading 42 bytes at once starting from register number 116, so theoretically we will should read registers 116-157, but it seems to read byte by byte only from register 116. Anyway as I mentioned before, it seems to work fine.

Hi, I've searched hole forum and the Internet ant haven't found many (to be honest almost none) information if anyone have successfully implemented I2CDev library on BeagleBone Black. I would like to use it with MPU6050. I've started to implement it, but without any success so far. Below, there is one question abut this library, I hope it is not too big offtop. What is the proper way of working this function: int8_t I2Cdev::readBytes(uint8_t devAddr, uint8_t regAddr, uint8_t length, uint8_t *data, uint16_t timeout) All the time I was thinking that it shoud read length bytes starting from regAddr. So for exaple int8_t I2Cdev::readBytes(devAddr, 10, 4, data, timeout) would read bytes from registers 10, 11, 12 and 13. But we have this function (from MPU6050 library): void MPU6050::getFIFOBytes(uint8_t *data, uint8_t length) { I2Cdev::readBytes(devAddr, MPU6050_RA_FIFO_R_W, length, data); } and in my opinion it should read length bytes from one register (MPU6050_RA_FIFO_R_W = 74) byte by byte and this is something different from what I described before. I have the same concers about writeBytes function. I would appreciate any help with understanding this functions