luisrodenas
-
Posts
82 -
Joined
-
Last visited
-
Days Won
22
Everything posted by luisrodenas
-
I haven't tried to put magnetometer data in fifo, but I think many people has tried without success. What I tried and searched a lot was a way to fuse magnetometer data IN the dmp's algorithm, my conclusion was that it is not possible and MPU9150's library also fuses mag data at host processor, not with DMP. This was my conclusion after a few days looking for info, but I am not 100% sure of this. Btw, what is the advantage of putting mag data in fifo if you still have to fuse it outside?
-
I couldn't achieve this and I don't know if it is even possible. If you achieve something let us know.
-
Glad it worked. I don't know if it is possible to change it in the program, I always change it in the library.
-
What I2c speed are you using? MPU supports up to 500KHz and Arduino's default is only 100KHz
-
So wierd... Could you attach the same sketch you are running? I will try to reproduce the error in my mega. I guess you haven't changed anything in the library, have you? What board is it? Do you have an schematic?
-
Is your DMP working at 100Hz or 200Hz?
-
MPU6050 + GPS
luisrodenas replied to jd58's topic in MPU-6050 6-axis accelerometer/gyroscope (InvenSense)
How long does it take to receive via softwareserial all the gps data? -
MPU6050 + GPS
luisrodenas replied to jd58's topic in MPU-6050 6-axis accelerometer/gyroscope (InvenSense)
Have you already changed the frecuency of DMP to your desired 50Hz? -
Yes, gyro gain or scale is broken. Now, I think this could be caused by, from most probable to less probable: - MPU broken - Something wrong in your ported code - DMP using wrong gain, no idea why. On the other hand we have those jumps... and you say they only occur while DMP is enabled... so wierd. To reach the end of this topic I believe you need to get another MPU or an Arduino, or better both. If you don't need it fast and want to save some $, buy them on ebay. MPUs on board alone are like 8 $, and Arduino Pro Mini is like 5$. If you want it fast it will cost you a bit more.
-
Ok. I think we narrowed the error to the gyros scale. Try to get YPR integrating gyro's measures. Then you will see if it is deg/sec or what constant you have to multiply them for. Try this setting the scale to 250 degrees, 500, and 2000. Im interested only in the gyro's estimate, do not fuse it yet. To check scale you can do a simple experiment: try to rotate your board at constant speed. For example rotate it 360º in 10 sec (try to do it at constant speed), and you know you should get something close to 36º/sec
-
YES, try to use DMP, check the example DMP sketch and adapt it to your project. I believe you can work without the interruptions, but you will need to read the fifo buffer at least at the same frecuency (I recommend higher) that the DMP is working. You can change DMP's frecuency to your needs. If you read at lower frecuency it will overflow and start giving errors. Just mopdify the example sketch and erase the interruption part, put a delay to get the frecuency you want (just to try) and check that it works. If using DMP you will also need to calibrate your MPU.
-
I have those equations implemented in my project. It is true they improve yaw measure coming from magnetometer, in the way that it does not oscillate so much when you change pitch and roll. Anyway I reached the conclusion that magnetometer yaw measure shouldn't be used indoors, because of big electromagnetic interference. Or maybe it is just my lab, with cables running under the floor and inside walls. When I start to use it outdoors I will check its measure again and fuse them. Thank you for the info
-
Well, I believe that BEFORE calibration, gravity vector length at rest will not be 1g exactly, due to sensor imperfections, where you are in Earth, etc. Ofcourse we could try to implement something to make it be as close as possible to 1g, I don't know if it will improve DMP's measure, but we can try. If the internal algorithm is using the three coordinates of gravity vector, I believe it is using its angle, and doesn't care about its length, as long as the vector is not distorted. But maybe I am wrong. I'll test it out when I have some free time. Thanks
-
The [-180,+180] yaw range is normal. Maybe your problem is something related to sensor ranges? Try to change gyro's range to something higher (500 or more). I believe this change should be made between offsets and setDMPenabled. You can also check this getting accel and gyro info from dmp, something like dmpGetAccel, and dmpGetgyro. Check those values. I think the first one should be in gs already, and the second one in degrees/second. This way you can move your board and you can manually check if values have sense or not. I can't think of any other possible error, apart from your coding or the sensor itself being faulty. An arduino would be nice to check this last thing fast.
-
At 200Hz the measure is a bit more noisy, but little difference. For example in my application, a quadrotor with motors vibrating etc, when running DMP at 200Hz the noise is aproximately +- 0.1 or +-0.15 degrees. Instead, when running at 100Hz, noise goes down to +- 0.05 degrees, sometimes a bit more. For my aplication this noise is not relevant.
-
Offsets are usually necesary to run DMP, if not its measures fluctuate. It is not a startup thing, it will not work if offsets are very different from what should be. The easiest way is to run one of the automatic offset sketchs... but if you don't own an Arduino, it's going to take you a bit longer. You can try 2 things: -Adapt the calibration sketch to your Beaglebone. If so, please share it later. Arduino code is here: http://www.i2cdevlib.com/forums/topic/96-arduino-sketch-to-automatically-calculate-mpu6050-offsets/ - Faster way maybe is to read raw values from sensors, and change offsets iteratively until you get that raw measures from every gyro and Xaccel and Yaccel are 0, and Zaccel is 16384. Then use those offsets with DMP.
-
That's rigth if you only want to use RAW values... or if you read fifo whenever you want... but the optimal way is by interruptions. Read the DMP sketch's comments. In order to use interruptions you have to connect your MPU's INT pin to Arduino UNO's 0 pin. By default DMP runs at 100Hz, but can be modified if you want to. (Max is 200Hz)
-
That is so strange. The measure I get with DMP is almost perfect, and I am comparing it with much pricer products like MicroStrain's. Did you set the correct offsets for your sensor? Are you using interrupts or how are you checking fifo buffer? Have you tried with an Arduino and original Jeff's sketch?
-
Well, if it works for you... then I guess you can read it using (mpu.dmpGetXXXXXXXX) every time you want, but be sure to read it at a faster frecuency than DMP is running, or fifo will overflow. Anyway, I haven't checked how does this (mpu.dmpGetXXXXXXXX) function work, so I am only speculating. Besides, this long wait you mention has never happened to me. Are you sure that INT pin is connected where it should be connected?
-
Wierd. This has never happened to me. Let us know what you find. This is another topic I think. I believe it does not have anything to do with the i2c library, but how the sensor and fifo buffer works. Once you set the DMP to use fifo buffer, and its frecuency, you have to read the fifo at least at that frecuency, or it will overflow and then the errors appear. In my experience, if it overflows just once sometimes, its no big trouble, but if it overflows several times DMP's measures go crazy, reset, etc. For example I am running DMP at 200Hz, so there is a measure every 5ms. I check and read fifo every 3ms and I have no problem at all. So, configure your DMP's frecuency to one you can check fifo faster.
-
Fixed!! There was a bug in the sketch. Variables were overflowing in 8-bit Arduinos, like the UNO or Leonardo. Now it works fine in my Leonardo, but took a while to converge, 2-3 minutes. Thank you for your contribution and let me know if it works for you now.
-
I have an Arduino Leonardo somewhere, I am going to try it. Anyway, calibration shouln't take more than 1 minute with default settings.
-
MPU6050 connection failed
luisrodenas replied to Riccati's topic in MPU-6050 6-axis accelerometer/gyroscope (InvenSense)
It seems like you are doing everything fine... The MPU6050 is supposed to be powered and communicated at 3.3V. But this depends on the board you are using, because it could have a logical level translator. Anyway, let's try this: - Have you tried with both I2C adresses? 0x69 and 0x68 - Schematic of you MPU board? - Can you try with another Arduino operating at 3.3V? Maybe an Arduino DUE, or some Arduino Pro Mini running at 3.3V... - Do you have an oscilloscope? If so, could you measure the voltage in SDA and SCL while the sketch is running? - Can you try with another MPU? It could also be that your MPU is dead. I have used like 10 of them, and just one died after 2 months of using it. In Ebay you can get really cheap MPUs and generic Arduinos. -
Maybe, instead of putting the includes in sensor.h, try to put them all in sensor.cpp
-
I believe your problem doesn't have anything to do with the sensor itself, but is more related to programming. Programming is not one of my strengths, so I think I cannot help much. Anyway, it looks like it has something to do with duplicated includes... looking at the error you posted. You can try two things: - Put all the includes in the arduino project, not in sensor.h. Its only 2 or 3 lines... - In sensor.cpp, you are including sensor.h, is it necessary? I mean, you are including it from the arduino project and from that file, maybe that's the cause? Sorry I can't be of more help.
