Jump to content
I2Cdevlib Forums

robjames66

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by robjames66

  1. The mag on the 9150 is fine as long as you're happy filtering it. My HMC5883L gives be a heading +/- half a degree and with the 9150 I get +/- 2 degrees. Proper hard/soft calibration helps a lot and a hefty low pass filter.
  2. It sucks doesn't it! Much worse than a HMC5883 A simple low pass filter helps. If x,y hold the raw values and xf,yf are global floats: xf = xf - (xf / 24) + (float)x/180.0; yf = yf - (yf / 24) + (float)y/180.0; // not tilt compensated... heading = atan2(xf / 24, yf / 24);
  3. I used the Motion Driver 5.1.2 core libs and wrote a test sketch using the the motion driver test example code.
  4. I've ported by application from the I2CDevLib MPU6050 libraries to the official Invensense libs and I get very poor DMP behaviour. The reported orientation does not always return to the original value when there us yaw rotation one way and back. This is not drift - it's a sudden step change in the yaw and it sucks. The I2CDevLibs behave much better for me. Invensense forums are a wast of time (full of spam) and very little response to queries. Rob J.
  5. There are other causes of drift but this is one way to address low levels of background yaw drift without the need for magnetometers. Works very well for me. http://reprapdad.wordpress.com/2014/04/16/mpu-6050-yaw-drift-and-how-to-combat/ Cheers, Rob J.
  6. Hi Folks, I've been using the I2C MPU-6050 libs as a basis for an arduino based orientation tracker. All working well but I'm now delving deeping into the Invensense docs and examples and they differ in how calibration is handled. Do I have the following right ? The gyro/accel offset registers used by the I2Cdevlibs (setXGyroOffset etc) appear to be undocumented by invensense and used for factory calibration. I can see these are useful if re-calibration is needed as they're non-volatile and automatically used by DMP. The invensense motion driver code/examples recalibrate by pushing bias values calulated by the host (from raw gyro/accel data) down to the DMP using dmp_set_gyro_bias, etc. This is volatile so needs to be stored by the host somewhere such as additional EEPROM. The DMP can also be configured to perform 'self calibration' of gyro data after 8 seconds of no motion. Using the I2Cdevlib calibration I get good results. To combat yaw drift I add a drift compensation to the values which works very well as yaw drift seems to be consistent and stable even with lots of motions. Cheers, Rob
×
×
  • Create New...