hi everyone! I have a problem with the gyroscope-accelerometer MPU6050. I've just bought it from ebay: http://www.ebay.it/itm/280791436843?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_1890wt_1037 it's the drotech brekout board. When it arrived i soldered 6 pin headers on the board and next i put it on a bread board. I've connected +5v and the gnd pin to arduino, the SDA pin to A4 arduino's pin and the SCL to A5 arduino's pin. I've also uploated this sketch on the board Arduino Playground - MPU-6050 but it send on the serial monitor only this
I never had to deal with errors. I just return them in case they occur.
I think error 2 is from Wire.endTransmission() and indicates that a NACK is received after the address is send.
It could be a bad connection on the bread board.
Can you try the i2c_scanner : Arduino Playground - HomePage
Let it run for a while to see if it always can detect your sensor.
On the backside is a solder pad for PULLUP. I can't see in the photo if that is connected. It seems to connect the two 10k resistors to the 3.3V. You need those pull-up resistors.
The resistors are already on the component side. The two smd components with "103" on them (10k resistors). I don't know if the solder pads with the label "PULLUP" are connected.
Also with this code the problem is the same: the arduino doesn't recognize the board... I'm start thinking that the board is broken... Maybe I fused it when I soldered the pin header on the board. Is possible that I heat up too much the mpu? Or maybe that I touched one of the resistor whit the welding and I broke it? Later I' ll do the i2c scanner.
SUBSEA:
Also with this code the problem is the same: the arduino doesn't recognize the board... I'm start thinking that the board is broken... Maybe I fused it when I soldered the pin header on the board. Is possible that I heat up too much the mpu? Or maybe that I touched one of the resistor whit the welding and I broke it? Later I' ll do the i2c scanner.
Once you have run the I2C scanner you will know if the board is responding and if it does then confirm the example sketch your using has the correct I2C device address.
I have been using wire.h I2C scanner with the MPU6050 and also get no response.
Looking at the clock and data signal on a scope the MPU6050 does respond with an ACK but wire is not reporting it. The scanner does a 8 bit clock for all other addresses but extends this to 16 bits for the 0x68 as the hardware sees the address ACK and also gets a data ACK.
On my Raspberry pi the i2cdevice 0 scanner finds the 0x68 ok.
With I2Cdev.h on the Due it also finds the mpu6050 si It looks like a problem with the wire.h driver ?? . See forum "MPU-6050 errors reading data" on how to use the i2cdev
I don't understand what this values mean... The acceleration on the z axis should't be 1? And also the other values are strange... Maybe I need to calibrate the sensor. How can I do this?
Your values seem okay. If you want to know what they mean, you have to read the datasheet about bits and range.
For serious use, you can now move on to use the library by Jeff Rowberg. But you have to connect the INT to Arduino digital pin 2.
Your values seem okay. If you want to know what they mean, you have to read the datasheet about bits and range.
For serious use, you can now move on to use the library by Jeff Rowberg. But you have to connect the INT to Arduino digital pin 2.
Another option you have is to use the FreeIMU library, which supports generic MPU6050 breakout boards. Be sure to modify freeIMU.h, and comment out the line the by default sets to the libary to use FreeIMU hardware, and un-comment out the line that say GenericMPU6050.
I have used both Rowbergs code and the FreeIMU library. They are both very good. Here are few things to know about each to get them up and running.
Rowbergs code is designed to use I2CDev library and his code accesses the DMP (digital motion processor) on the MPU6050. This offloads a lot of the motion calculations to the MPU6050 instead of your Arduino doing the calculations. Getting your MPU6050 working with Rowberg's code is pretty easy, and the resulting data output from the DMP looks good. It will output Yaw/Pitch/Roll, Euler Angles, and Accelerations from the accelerometer.
FreeIMU takes a little more work to get up and running, but not by much. FreeIMU does not use the DMP, and comes with a library that uses a MARG orientation algorithm to calculate the Yaw/Pitch/Roll of your sensor. FreeIMU comes with an older I2CDev library that does NOT work with Rowbergs DMP code. So make sure you keep the I2CDev libararies separate somehow. I name one directory I2CDev_Master and one I2CDev_FreeIMU. Whichever code I am using (I often switch between the two for comparison) I rename to just I2CDev. I am working on modifying the I2CDev libaries to work with both, but I am slow at it. FreeIMU does not output just acclerations, it only uses the accelerometer to aid in determinging yaw/pitch/roll and Euler angles. I may be wrong about that, as I need to spend more time looking at the examples and code, but from what I saw initially, I did not find anything in the code that would suggest it outputs accelerations on their own. I am working on a sketch that integrates the FreeIMU code to get the yaw/pitch/roll and Rowberg's DMP code to get the acclerations. The problem has been the I2CDev versions that are incompatible. The freeIMU libary's yaw/pitch/roll data seems to be stable and faster than using the DMP, which is why I want to use freeIMU's code for it.
Another thing to keep in mind is support. I've emailed Jeff before with questions about quaternions and gymbal lock with respect to his code and he responded very quickly and was very helpful, so that is a bonus. FreeIMU's founder Fabio Varesano sadly passed away last month so support for FreeIMU will only be from other users until/unless somebody else takes over FreeIMU and continues to develop it.
Looks like you are using the raw data example. There is another example directory included called "DMP6 Example" or something like that. That is the one that uses the DMP to process the data, and will allow you to output in degrees and accelerations instead of raw sensor values.