Jeff Rowberg's post in Getting "Error moving uploaded dump file from temporary directory. Please try again." when uploading file was marked as the answer
Sorry for the delayed reply. I moved the site to a new server a while ago and didn't correctly verify that the analyzer upload function still works. I have fixed the problems with upload permissions, and tested a new upload successfully just a moment ago.
Also, there should be a "Report" link towards the bottom right of every post in the forum which allows you to report things for moderation. This link is next to the "Quote" button, and it is a very light faded gray unless your mouse is hovering over the post.
Jeff Rowberg's post in MPU_DMP6 with Arduino DUE (TWBR not declared) was marked as the answer
Removing the TWBR assignment in this case should still work fine, though I2C may operate at 100kHz. This line was added to switch the I2C clock to 400kHz, but it is specific to the ATmega chips. The ARM used on the Due does not have this register, and so the assignment fails.
Jeff Rowberg's post in REALACCEL vs WORLDACCEL for dummies was marked as the answer
The REALACCEL numbers are calculated with respect to the orientation of the sensor itself, so that if it is flat and you move it straight up, the "Z" accel will change, but if you flip it up on one side and move it in the new relative "up" direction (along the sensor's Z axis), it will still register acceleration on the Z axis. Essentially, it is sensor-oriented acceleration which removes the effects of gravity and any non-flat/level orientation.
The WORLDACCEL numbers are calculated to ignore orientation. Moving it straight up while flat will look the same as the REALACCEL numbers, but if you then flip it upside-down and do the exact same movement ("up" with respect to you), you'll get exactly the same numbers as before, even though the sensor itself is upside-down.
This would be easier to explain in person with a solid object for reference, but hopefully this is enough.
Jeff Rowberg's post in FIFO Overflow was marked as the answer
Other than overclocking (not typically a good idea) or switching to a faster CPU (e.g. Arduino Due), one thing you can do to help with I2C transactions is to change the I2C clock rate from 100kHz (default) to 400kHz (assuming you are running at 16MHz, otherwise it will be 200kHz). This is done with the following direct register write after you call "Wire.begin()":
TWBR = 12; // set 400kHz mode @ 16MHz CPU or 200kHz mode @ 8MHz CPU Alternatively, you can change the DMP output rate by modifying the last bye of the last DMP configuration command on line 261 of the MPU6050_6Axis_MotionApps_20.h file:
0x02, 0x16, 0x02, 0x00, 0x01 // D_0_22 inv_set_fifo_rate // This very last 0x01 WAS a 0x09, which drops the FIFO rate down to 20 Hz. 0x07 is 25 Hz, // 0x01 is 100Hz. Going faster than 100Hz (0x00=200Hz) tends to result in very noisy data. // DMP output frequency is calculated easily using this equation: (200Hz / (1 + value)) // It is important to make sure the host processor can keep up with reading and processing // the FIFO output at the desired rate. Handling FIFO overflow cleanly is also a good idea. You do have to read all of the data that goes into the FIFO in order to prevent an overflow, but you can slow down the data that goes into the FIFO easily enough.
Jeff Rowberg's post in Multiple MPU6050's using DMP and interrupts was marked as the answer
The MPU6050.* files (the actual device libraries) don't have any of the actual interrupt detection or pin assignment code in them; this is found in the MPU6050_DMP6.ino example sketch, specifically (at the moment) on line 196:
// enable Arduino interrupt detection Serial.println(F("Enabling interrupt detection (Arduino external interrupt 0)...")); attachInterrupt(0, dmpDataReady, RISING); mpuIntStatus = mpu.getIntStatus(); This uses interrupt 0, which on the Arduino Uno is digital pin 2. You would need to assign an additional interrupt with a different pin connection, and duplicate the "dmpDataReady" function (perhaps into "dmpDataReady2") and set a new "mpuIntStatus2" variable which can be tested in the main loop.
Jeff Rowberg's post in How to Calculate "Yaw Roll Pitch" from Mpu6050 ? was marked as the answer
The code you link to in the Keyglove repository works tolerably well, but since it relies entirely on the accelerometer readings (e.g. tilt with respect to gravity), it only works if the accelerometer is holding still. If there is any linear motion, then the calculations are messed up because non-gravitational acceleration is introduced. This is why the DMP is so valuable; it fuses the data from both the gyroscope and accelerometer to produce accurate results regardless of whether the sensor is moving or not.
Jeff Rowberg's post in Compass to use with MPU-6050 was marked as the answer
I haven't added support for anything besides the AK8975, which is what was built into the MotionApps code. However, Github user @muzhig has made it work with the HMC5883L:
Note that this doesn't work with the DMP, but does provide raw magnetometer readings in the external sensor data registers as described in his comment.
Jeff Rowberg's post in A question to change the sample rate in MPU6050.h file was marked as the answer
The setRate() method only applies to raw measurements, but not to the DMP which has its own rate. This is defined on line 261 (currently) of MPU6050_6Axis_MotionApps_20.h. The default rate is 100Hz (the last byte is 0x01), but you can increase it to 50Hz by changing that byte to 0x03 instead. To the best of my knowledge, the internal sensors are still read at a very fast rate, but the DMP algorithms compensate such that the output data is appropriate for 50Hz intervals.
If you don't want to use the interrupt pin (which is a shame since it's much more efficient), you can simply poll regularly for a FIFO count that is >= 42 (which is the size of a typical MotionApps 2.0 DMP packet), and read those 42 bytes anytime they are available until there are less than 42 bytes available. It's kind of an ugly way to do it, but it does work as long as you read fast enough that the FIFO doesn't overflow (>= 1024 bytes).
Jeff Rowberg's post in Why is the DMP yaw stable? was marked as the answer
My (rudimentary) understanding is that after that much time, the DMP algorithm realizes that the constant value it's getting for yaw drift from the gyro is error rather than movement, and it appropriately zeroes it out. I can't begin to tell you exactly how this happens, but it does seem to work that way. One idea is that if the accel X/Y values aren't exactly zero, then if the heading really were changing, the X/Y accel values should rotate accordingly. If they are stable but the heading is shifting, then the effect would necessarily have to be error rather than real movement. This is just a guess though.
One thing I have discovered recently through testing is that you can manually set your own axis offset values to "kickstart" this calibration process. For example, adding the mpu.setXXXXXOffset code after the mpu.dmpInitialize() call to MPU6050_DMP6.ino:
// load and configure the DMP Serial.println(F("Initializing DMP...")); devStatus = mpu.dmpInitialize(); // supply your own gyro offsets here, scaled for min sensitivity mpu.setXGyroOffset(220); mpu.setYGyroOffset(76); mpu.setZGyroOffset(-85); mpu.setZAccelOffset(1788); // 1688 factory default for my test chip ...makes the initialization routine on the specific MPU I was using for testing virtually unnecessary. It starts up with a nearly rock-solid orientation value and changes a fraction of a degree over the first 8 seconds. These values are unique to every sensor, so don't just use the ones above; the easiest way I've found so far to determine them is to use the MPU6050_raw.ino example sketch and simply play with different values while the sensor is stationary and level until all of the measurements are suitably close to zero, accounting for noise. This process could undoubtedly be automated such that you could just run a "calibration" sketch and leave it sitting still for a few seconds--maybe even taking advantage of the DMP to do the work for you--but I haven't got this far yet.
Jeff Rowberg's post in double MPU6050 (Sparkfun) was marked as the answer
This would be much easier if you create two instances of the device:
MPU6050 mpu1(MPU6050_ADDRESS_AD0_LOW); MPU6050 mpu2(MPU6050_ADDRESS_AD0_HIGH); Then simply use them as independent objects. The device constructor is meant to take the slave address as an optional parameter for this purpose.
Jeff Rowberg's post in integration was marked as the answer
Thanks for your comments about the project! I am hopeful that it can continue to grow into a very useful community.
You are correct on all five points in your list. In short, we can make the DMP work to spit out quaternion data, but we don't know how it works. Displacement is hard to calculate accurately since it requires double integration of acceleration, and therefore is prone to a whole lot of error unless timing is very precise and the measurement error is low. Assuming the measurement data is accurate though, a rough estimate should be possible of both linear and rotational displacement. I believe a guy named Seb Madgwick was working this very problem using an Arduino, though I could have that wrong and I'm not sure if he's working with this particular sensor.
I'm not sure whether the DMP itself could be made to do this calculation for you, but I have no idea how to approach that goal. I figure InvenSense is opaque about it because it's a unique value-add feature for them, and opening it wide up would deprive them of some opportunities. (Of course, it would also open up many other opportunities, but that's apparently not their focus.)