Component side : Printed circuit board - Wikipedia
So I must solder the resistor on the board? I can't pur them on the breadboard?
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.
Did you run the i2c_scanner ?
Ok, now I've understood, thank you. I'll run the i2c tester as fast asse I can.
On the eBay page you supplied there is a link to some github code https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino
Does it work as expected using this code instead of the code you downloaded from the playground?
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
Hi everyone! I've just solved my problem! I've ran the i2c scanner and I have found like i2c address 0x69. Now I' m reading on the serial monitor this
MPU-6050
Read accel, temp and gyro, error = 0
accel x,y,z: -2120, 108, 17856
temperature: 20.224 degrees Celsius
gyro x,y,z : 236, -164, -98,
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?
That's why I added my own measurements to that page : Arduino Playground - MPU-6050
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.
Ok thank you. But how can I change the i2c address in 0x69?
Krodal:
That's why I added my own measurements to that page : Arduino Playground - MPU-6050Your 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.
Thank you so much for this reply. Also I have emailed to jeff, but he did't replie me yet. ok. let's try XD
Ok. I've modified the source and now Arduino can find my board, but it does the same value that the first sketch did... How is this possible?
Initializing I2C devices...
Testing device connections...
MPU6050 connection successful
a/g: -4488 244 17336 236 -134 -76
a/g: -4476 252 17184 259 -146 -78
a/g: -4436 368 17380 254 -162 -84
a/g: -4496 336 17364 250 -173 -62
a/g: -4544 200 17308 261 -189 -68
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.
The DMP example code writes to the sensors FIFO buffer and uses an interrupt to notify the Arduino of incoming data. You have to have the interrupt pin on your sensor board connected to pin #2 I think of your Arduino (at least for my Uno R3)
Ok. I've connected the pin 2 to the pin int of my board, but it doesn't change. Howerever, now I want to try the "teapot" sketch, but I don't find the toxi libraries. Have you a dowload link for it?
import toxi.geom.*;
import toxi.processing.*;
Are you able to see anything at all in the serial monitor? If you aren't seeing anything in the serial monitor, you will not be able to get the teapot sketch to work. I never tried to get the teapot sketch to work and have never used processing for anything. I just output the yaw/pitch/roll and accelerations and wrote some C# code to view it. So I can't help you with getting that processing thing to work.
Here's a video of one of my C# programs using the output serial data.
wow! amazing! In serial monitor I read this:
Testing device connections...
MPU6050 connection successful
a/g: -1900 264 17964 250 -172 -72
a/g: -2024 140 17784 241 -160 -95
a/g: -1888 212 17700 228 -162 -93
a/g: -1932 172 17632 233 -170 -85
a/g: -1872 192 17880 239 -146 -94
a/g: -1952 184 17796 268 -175 -80
a/g: -1932 284 17880 254 -160 -87
a/g: -1984 288 17844 220 -191 -72
a/g: -1964 228 17872 249 -160 -83
etc.
The problem is that this values are strange and i can't use it... Can you understand them?
The first 3 sets of values are are the raw accelerometer values. The 2nd set of 3 values looks to be the yaw/pitch/roll or Euler angles of the gyro.
The raw values for the accelerometer don't mean much. I think the sensors are 16 bit, so a number between 0-65k. Divide that by the G-range of the sensor. By default I think it is 4. Anyway, the DMP example has an option to enable real-world acceleration and/or readable acceleraction in G's instead of raw values. Read through the example code, you just have to un-comment a #define variable if I recall correctly. If you post your code, I will point it out for you.