Which is better to use for ESP32 and Sparkfun 9250 breakout?

[MiloMindbender]

@kriswiner I'm a little confused looking at your ESP32 repository and your MPU9250 repository.

I'm using a Sparkfun 9250 breakout (https://www.sparkfun.com/products/13762) and an Adafruit Feather ESP32 board.

Between these two repositories you have a number of MPU9250 sketches and I'm a bit confused about which one is most appropriate for the setup I'm running. I'm looking to get sensor fusion for a balancing robot.

My robot runs it's main loop every 10ms and I want to get/fuse "latest" data from the sensor at the top of the loop.

I've tried sparkfun's 9250 repositories but theirs all seem broken in some way.

[kriswiner]

What's wrong with this https://github.com/kriswiner/ESP32/tree/master/MPU9250_MS5637 one?

On Fri, Sep 7, 2018 at 12:03 PM MiloMindbender notifications@github.com wrote:

@kriswiner https://github.com/kriswiner I'm a little confused looking at your ESP32 repository and your MPU9250 repository.

I'm using a Sparkfun 9250 breakout ( https://www.sparkfun.com/products/13762) and an Adafruit Feather ESP32 board.

Between these two repositories you have a number of MPU9250 sketches and I'm a bit confused about which one is most appropriate for the setup I'm running. I'm looking to get sensor fusion for a balancing robot.

My robot runs it's main loop every 10ms and I want to get/fuse "latest" data from the sensor at the top of the loop.

I've tried sparkfun's 9250 repositories but theirs all seem broken in some way.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qp7JI_6FL-Hsr6tSsazDnA82hb7uks5uYsMcgaJpZM4WfU5t .

[MiloMindbender]

It's not building for me, MadgwickQuaternionUpdate not declared in this scope.

Did I miss a library/file I need to get from someplace else? Didn't see anything in a readme.

[kriswiner]

Add the filter file to your sketch using the tab...

On Fri, Sep 7, 2018 at 1:46 PM MiloMindbender notifications@github.com wrote:

It's not building for me, MadgwickQuaternionUpdate not declared in this scope.

Did I miss a library/file I need to get from someplace else? Didn't see anything in a readme.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419561132, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qkIeLoqW8VxkxqtKnb2i8nUkZRQeks5uYtsygaJpZM4WfU5t .

[MiloMindbender]

Sorry to be such a dummy, but now I'm getting errors in the wire.h include file.

In file included from C:\Users\gcorson\Downloads\ESP32-master\ESP32-master\MPU9250_MS5637\MPU9250_MS5637_AHRS\MPU9250_MS5637_AHRS.ino:29:0:

C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h: In function 'uint8_t readByte(uint8_t, uint8_t)':

C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h:99:13: note: candidate 1: uint8_t TwoWire::requestFrom(int, int)

 uint8_t requestFrom(int address, int size);

         ^

C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h:97:13: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t)

 uint8_t requestFrom(uint8_t address, uint8_t size);

         ^

Archiving built core (caching) in: C:\Users\gcorson\AppData\Local\Temp\arduino_cache_78456\core\core_espressif_esp32_featheresp32_FlashFreq_80,UploadSpeed_921600,DebugLevel_verbose_69dfa191d1244698fa99bf793b8c9f27.a

[MiloMindbender]

@kriswiner Sorry, apparently it still built, but when I run it doesn't connect to my MPU9250

[V][esp32-hal-i2c.c:1436] i2cInit(): num=0 sda=21 scl=22 freq=400000 [V][esp32-hal-i2c.c:1621] i2cSetFrequency(): Fifo threshold=9 Scanning... No I2C devices found

MPU9250 9-axis motion sensor... MPU9250 I AM 0 I should be 71 Could not connect to MPU9250: 0x0

[MiloMindbender]

Looks like pins 21 and 22 are not the SDA and SCL pins on my ESP32. Changed to Wire.begin()

Now it finds the chip, but the output I get for the sensors never changes.

[V][esp32-hal-i2c.c:1436] i2cInit(): num=0 sda=23 scl=22 freq=0 [V][esp32-hal-i2c.c:1621] i2cSetFrequency(): Fifo threshold=3 Scanning... I2C device found at address 0x0C ! I2C device found at address 0x68 ! done

MPU9250 9-axis motion sensor... MPU9250 I AM 71 I should be 71 MPU9250 is online... x-axis self test: acceleration trim within : 1.2% of factory value y-axis self test: acceleration trim within : 0.3% of factory value z-axis self test: acceleration trim within : 2.2% of factory value x-axis self test: gyration trim within : -4.3% of factory value y-axis self test: gyration trim within : -0.6% of factory value z-axis self test: gyration trim within : 0.9% of factory value Calibrate gyro and accel accel biases (mg) 36.93 102.11 17.94 gyro biases (dps) -1.88 1.93 -0.58 MPU9250 initialized for active data mode.... AK8963 I AM 48 I should be 48 AK8963 initialized for active data mode.... Mag Calibration: Wave device in a figure eight until done! Mag Calibration done! AK8963 mag biases (mG) 87.15 45.39 -115.97 AK8963 mag scale (mG) 0.92 0.92 1.20 X-Axis sensitivity adjustment value 1.21 Y-Axis sensitivity adjustment value 1.21 Z-Axis sensitivity adjustment value 1.17 MS5637 pressure sensor reset... PROM dta read: C0 = 12032 C1 = 12032 C2 = 12032 C3 = 12032 C4 = 12032 C5 = 12032 C6 = 12032 Checksum = 8 , should be 2 ax = 0.00 ay = 0.00 az = 0.00 mg gx = 0.00 gy = 0.00 gz = 0.00 deg/s mx = 0 my = 0 mz = 0 mG q0 = 1.00 qx = 0.00 qy = 0.00 qz = 0.00 Gyro temperature is 32.3 degrees C Digital temperature value = -10.34 C Digital temperature value = 13.38 F Digital pressure value = -268.76 mbar Altitude = nan feet Yaw, Pitch, Roll: 13.80, 0.00, 0.00 Grav_x, Grav_y, Grav_z: 0.00, 0.00, 1000.00 mg Lin_ax, Lin_ay, Lin_az: 0.00, 0.00, -1000.00 mg sumCount = 0 sum = 0.00 rate = nan Hz ax = 0.00 ay = 0.00 az = 0.00 mg gx = 0.00 gy = 0.00 gz = 0.00 deg/s mx = 0 my = 0 mz = 0 mG q0 = 1.00 qx = 0.00 qy = 0.00 qz = 0.00 Gyro temperature is 32.3 degrees C Digital temperature value = -10.32 C Digital temperature value = 13.42 F Digital pressure value = -268.72 mbar Altitude = nan feet Yaw, Pitch, Roll: 13.80, 0.00, 0.00 Grav_x, Grav_y, Grav_z: 0.00, 0.00, 1000.00 mg Lin_ax, Lin_ay, Lin_az: 0.00, 0.00, -1000.00 mg sumCount = 0 sum = 0.00 rate = nan Hz ax = 0.00 ay = 0.00 az = 0.00 mg gx = 0.00 gy = 0.00 gz = 0.00 deg/s mx = 0 my = 0 mz = 0 mG q0 = 1.00 qx = 0.00 qy = 0.00 qz = 0.00 Gyro temperature is 32.3 degrees C Digital temperature value = -10.36 C Digital temperature value = 13.35 F

[kriswiner]

Do you have the interrupt pin properly specified?

On Fri, Sep 7, 2018 at 2:32 PM MiloMindbender notifications@github.com wrote:

Reopened #17 https://github.com/kriswiner/ESP32/issues/17.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#event-1833794443, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtrWd5WNY-P8hK7soX5hf-55QCaoks5uYuYJgaJpZM4WfU5t .

[MiloMindbender]

I just noticed this, your hookup guide in the comments didn't mention the interrupt pin at all so I missed it.

Is there a sketch that doesn't need the interrupt pin? None of sparkfun's stuff requires it so the int pin isn't tied to the breadboard right now....

[MiloMindbender]

I should say, thanks very much for all your work, it is really appreciated. I've been having so much trouble ferriting out stuff that works. Sparkfun has 3 repositories for this board, all out of date, two with serious bugs. They have hacked some of your code, mention using interrupts but they have changed the code to not use them (but leaving comments/code about interrupts in) so getting this 9250 working has been very confusing!

Also, the Invensense DMP stuff furthers the confusion by talking about having 9dof fusion on-chip when they really only have 6 (the mag stuff is done in the MCU).

Anyway, I think I can use sparkfun's method for not using interrupts if (myIMU.readByte(MPU9250_ADDRESS, INT_STATUS) & 0x01)

The robot I'm working on has a precise timed main loop every 10ms, so I really want to get the sensor data at the top of that loop every time. Do you have any recommendation for keeping in sync with the 9250?

[kriswiner]

Use the interrupt...

On Fri, Sep 7, 2018 at 2:55 PM MiloMindbender notifications@github.com wrote:

I should say, thanks very much for all your work, it is really appreciated. I've been having so much trouble ferriting out stuff that works. Sparkfun has 3 repositories for this board, all out of date, two with serious bugs. They have hacked some of your code, mention using interrupts but they have changed the code to not use them (but leaving comments/code about interrupts in) so getting this 9250 working has been very confusing!

Also, the Invensense DMP stuff furthers the confusion by talking about having 9dof fusion on-chip when they really only have 6 (the mag stuff is done in the MCU).

Anyway, I think I can use sparkfun's method for not using interrupts if (myIMU.readByte(MPU9250_ADDRESS, INT_STATUS) & 0x01)

The robot I'm working on has a precise timed main loop every 10ms, so I really want to get the sensor data at the top of that loop every time. Do you have any recommendation for keeping in sync with the 9250?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419576203, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qkXZCvYgcVJspuBSHO9mUvmQnci8ks5uYuttgaJpZM4WfU5t .

[MiloMindbender]

My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time.

I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either.

Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data.

Thanks for your help.

[kriswiner]

Set the gyro and accel sample rates to 1 kHz. You might need to use something better than a poky AVR MCU...

On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender notifications@github.com wrote:

My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time.

I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either.

Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data.

Thanks for your help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419592352, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t .

[kriswiner]

Set the gyro and accel rates to 1 kHz and simply read both plus mag data (100 Hz) at the top of the loop. The important one is the gyro, this way the PID loop sees the freshest daya available, no interrupt or status register polling needed.

On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation tleracorp@gmail.com wrote:

Set the gyro and accel sample rates to 1 kHz. You might need to use something better than a poky AVR MCU...

On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender notifications@github.com wrote:

My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time.

I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either.

Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data.

Thanks for your help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419592352, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t .

[kriswiner]

This https://www.tindie.com/products/TleraCorp/ladybug-flight-controller/ would make a better choice for robot controller.

On Fri, Sep 7, 2018 at 4:45 PM Tlera Corporation tleracorp@gmail.com wrote:

Set the gyro and accel rates to 1 kHz and simply read both plus mag data (100 Hz) at the top of the loop. The important one is the gyro, this way the PID loop sees the freshest daya available, no interrupt or status register polling needed.

On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation tleracorp@gmail.com wrote:

Set the gyro and accel sample rates to 1 kHz. You might need to use something better than a poky AVR MCU...

On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender notifications@github.com wrote:

My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time.

I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either.

Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data.

Thanks for your help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419592352, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t .

[kriswiner]

Or this https://www.tindie.com/products/onehorse/superfly-hackable-esp8266-flight-controller/ ...

On Fri, Sep 7, 2018 at 4:51 PM Tlera Corporation tleracorp@gmail.com wrote:

This https://www.tindie.com/products/TleraCorp/ladybug-flight-controller/ would make a better choice for robot controller.

On Fri, Sep 7, 2018 at 4:45 PM Tlera Corporation tleracorp@gmail.com wrote:

Set the gyro and accel rates to 1 kHz and simply read both plus mag data (100 Hz) at the top of the loop. The important one is the gyro, this way the PID loop sees the freshest daya available, no interrupt or status register polling needed.

On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation tleracorp@gmail.com wrote:

Set the gyro and accel sample rates to 1 kHz. You might need to use something better than a poky AVR MCU...

On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender notifications@github.com wrote:

My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time.

I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either.

Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data.

Thanks for your help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419592352, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t .

[MiloMindbender]

@kriswiner don't know if I was clear earlier, I'm using an ESP32 microcontroller 240hz dual core. Should be much faster than an AVR or 8266.

I got your MPU9250_MS5637_AHRS code running on it but am having an issue with YAW similar to what I had with Sparkfun's code.

I orient the board so the YAW reads 0, then rotate the board 90 degrees right and I get yaw 75, rotate 180 and I get 112, reorient the board the way it was and I go back to zero.

pitch and roll both seem ok, turn them +- 90 and I get +- 90 on the output.

Also, when I rotate the board in yaw, it seems to take several seconds to "settle" to a new stationary value. Pitch and roll seem to stop immediately when the board stops moving.

Quaternions seem to be doing the same thing.

Am I doing something wrong?

Below is a sample before and after a 180 degree yaw.

ax = 0.92 ay = -3.48 az = 995.42 mg gx = -0.02 gy = 0.18 gz = -0.13 deg/s mx = -27 my = 142 mz = 29 mG q0 = 0.99 qx = -0.00 qy = -0.00 qz = -0.13 Gyro temperature is 34.7 degrees C Digital temperature value = -827.59 C Digital temperature value = -1457.66 F Digital pressure value = 31118.61 mbar Altitude = -133550.08 feet Yaw, Pitch, Roll: 358.37, -0.10, -0.26 Grav_x, Grav_y, Grav_z: 4.48, -1.77, 999.99 mg Lin_ax, Lin_ay, Lin_az: -3.57, -1.71, -4.57 mg sumCount = 1010 sum = 0.54 rate = 1856.52 Hz After 180 degree rotation ax = -21.97 ay = -26.25 az = 994.38 mg gx = 0.05 gy = 0.14 gz = -0.08 deg/s mx = 589 my = -61 mz = 48 mG q0 = 0.64 qx = 0.00 qy = -0.02 qz = 0.76 Gyro temperature is 34.9 degrees C Digital temperature value = -826.46 C Digital temperature value = -1455.63 F Digital pressure value = 30847.15 mbar Altitude = -133085.45 feet Yaw, Pitch, Roll: 113.53, -1.80, -1.64 Grav_x, Grav_y, Grav_z: 28.54, -31.41, 999.10 mg Lin_ax, Lin_ay, Lin_az: -50.51, 5.17, -4.71 mg sumCount = 1000 sum = 0.54 rate = 1834.88 Hz

[kriswiner]

Are you calibrating the sensors? How?

Are you feeding the sensor data into the fusion filter in NED order?

On Mon, Sep 10, 2018 at 9:55 AM MiloMindbender notifications@github.com wrote:

@kriswiner https://github.com/kriswiner don't know if I was clear earlier, I'm using an ESP32 microcontroller 240hz dual core. Should be much faster than an AVR or 8266.

I got your MPU9250_MS5637_AHRS code running on it but am having an issue with YAW similar to what I had with Sparkfun's code.

I orient the board so the YAW reads 0, then rotate the board 90 degrees right and I get yaw 75, rotate 180 and I get 112, reorient the board the way it was and I go back to zero.

pitch and roll both seem ok, turn them +- 90 and I get +- 90 on the output.

Also, when I rotate the board in yaw, it seems to take several seconds to "settle" to a new stationary value. Pitch and roll seem to stop immediately when the board stops moving.

Quaternions seem to be doing the same thing.

Am I doing something wrong?

Below is a sample before and after a 180 degree yaw.

ax = 0.92 ay = -3.48 az = 995.42 mg gx = -0.02 gy = 0.18 gz = -0.13 deg/s mx = -27 my = 142 mz = 29 mG q0 = 0.99 qx = -0.00 qy = -0.00 qz = -0.13 Gyro temperature is 34.7 degrees C Digital temperature value = -827.59 C Digital temperature value = -1457.66 F Digital pressure value = 31118.61 mbar Altitude = -133550.08 feet Yaw, Pitch, Roll: 358.37, -0.10, -0.26 Grav_x, Grav_y, Grav_z: 4.48, -1.77, 999.99 mg Lin_ax, Lin_ay, Lin_az: -3.57, -1.71, -4.57 mg sumCount = 1010 sum = 0.54 rate = 1856.52 Hz After 180 degree rotation ax = -21.97 ay = -26.25 az = 994.38 mg gx = 0.05 gy = 0.14 gz = -0.08 deg/s mx = 589 my = -61 mz = 48 mG q0 = 0.64 qx = 0.00 qy = -0.02 qz = 0.76 Gyro temperature is 34.9 degrees C Digital temperature value = -826.46 C Digital temperature value = -1455.63 F Digital pressure value = 30847.15 mbar Altitude = -133085.45 feet Yaw, Pitch, Roll: 113.53, -1.80, -1.64 Grav_x, Grav_y, Grav_z: 28.54, -31.41, 999.10 mg Lin_ax, Lin_ay, Lin_az: -50.51, 5.17, -4.71 mg sumCount = 1000 sum = 0.54 rate = 1834.88 Hz

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419983903, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qj1Xr_NXXXmmHgz-mpieR9inmw19ks5uZpl1gaJpZM4WfU5t .

[MiloMindbender]

I'm just running your MPU9250_MS5637_AHRS code and doing the mag calibration that's included. I haven't changed anything else.

Do I need to do separate accel/gyro calibration? I'm not looking for perfect true-north accuracy.

[kriswiner]

The sketches are not black boxes, you need to calibrate your sensors and know what you are doing...

And the sensor data order in the fusion filter? This is likely wrong.

On Mon, Sep 10, 2018 at 10:06 AM MiloMindbender notifications@github.com wrote:

I'm just running your MPU9250_MS5637_AHRS code and doing the mag calibration that's included. I haven't changed anything else.

Do I need to do separate accel/gyro calibration? I'm not looking for perfect true-north accuracy.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419987450, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgVzTGPoZX58j8HTdceVC9n6NEflks5uZpwggaJpZM4WfU5t .

[MiloMindbender]

Honestly sorry if I'm being a pain. I was under the impression that the sketch was basic example of doing it correctly but you seem to be saying sensor data order is wrong and I shouldn't expect correct results?

I'll do some more reading, maybe I can figure it out.

By the way, my setup has the chip oriented flat on the board with the z axis pointed up. I thought that would match your sketch. Also not sure what you mean by NED order?

[kriswiner]

You'll need to calibrate your sensors well to have any hope of getting accurate results. How do you know when the sensors are calibrated?

https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration

The Madgwick or Mahony filters expect to receive the sensor data in North, East. Down order. Choose which direction is to be North for your board. Which accel axis is aligned with board North? East? Down? Now same for gyro and mag, this is the order to feed the fusion filter, AN, AE, AD, GN, GE, GD, MN, ME, MD.

Poor calibration and incorrect sensor order cover 99% of the causes of poor absolute orientation results.

If your yaw is laggy, and the calibration and sensor order are correct, I would increase the accel/gyro sample rates to 1 kHz and make sure the fusion filter is iterated at least 10 times for each new data sample.

On Mon, Sep 10, 2018 at 10:33 AM MiloMindbender notifications@github.com wrote:

Honestly sorry if I'm being a pain. I was under the impression that the sketch was basic example of doing it correctly but you seem to be saying sensor data order is wrong and I shouldn't expect correct results?

I'll do some more reading, maybe I can figure it out.

By the way, my setup has the chip oriented flat on the board with the z axis pointed up. I thought that would match your sketch. Also not sure what you mean by NED order?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-419995931, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm2TK7cKaIyDz00n6o725mlfUWccks5uZqJLgaJpZM4WfU5t .

[MiloMindbender]

Thanks @kriswiner I understand your terms now, but not why it isn't working....

According to my PCB stencil I am in NED order X north, Y east, Z down. I'm double checking the signs of the data but at least the axis is correct (unless the stencil on the board is wrong) and that's the way your MPU9250_MS5637_AHRS (from this repo) sample seems to be feeding them into MadgwickQuaternionUpdate.

Your sample also seems to iterate MadgwickQuaternionUpdate 10 times on each read of the IMU and it calls your magcalMPU9250 to calibrate the magnetometer at the start of the sketch by waving the board in figure 8 patterns.

Your sketch has mmode set to 0x06 (100hz) for the mag and while I'm not entirely certain, it looks like the gyro/accel are set to 1khz .

So does this sound like things are setup as you described above?

With the board x pointed at magnetic north, the yaw reads 73 degrees.

Every time I re-do the mag calibration the bias numbers are significantly different while the scales are about the same. The accel and gyro biases are always pretty close.

I could understand north not reading as yaw 0, I don't understand a 180 degree rotation reading as 130 degrees.

Have I missed a step? If I understand you right this sample is calibrating the mag and doing the other stuff right.

MPU9250 9-axis motion sensor... MPU9250 I AM 71 I should be 71 MPU9250 is online... x-axis self test: acceleration trim within : 1.0% of factory value y-axis self test: acceleration trim within : 0.1% of factory value z-axis self test: acceleration trim within : 1.8% of factory value x-axis self test: gyration trim within : -4.1% of factory value y-axis self test: gyration trim within : -0.4% of factory value z-axis self test: gyration trim within : 0.9% of factory value Calibrate gyro and accel accel biases (mg) 35.16 0.92 22.40 gyro biases (dps) -1.81 1.92 -0.54 MPU9250 initialized for active data mode.... AK8963 I AM 48 I should be 48 AK8963 initialized for active data mode.... Mag Calibration: Wave device in a figure eight until done! Mag Calibration done! AK8963 mag biases (mG) -94.41 -10.89 47.44 AK8963 mag scale (mG) 1.57 0.71 1.04 X-Axis sensitivity adjustment value 1.21 Y-Axis sensitivity adjustment value 1.21 Z-Axis sensitivity adjustment value 1.17 MS5637 pressure sensor reset... PROM dta read: C0 = 50431 C1 = 50431 C2 = 50431 C3 = 50431 C4 = 50431 C5 = 50431 C6 = 50431 Checksum = 4 , should be 12 ax = 4.21 ay = 1.22 az = 990.54 mg gx = 0.18 gy = 0.13 gz = -0.07 deg/s mx = -48 my = 81 mz = -128 mG q0 = 0.40 qx = -0.71 qy = -0.20 qz = -0.54 Gyro temperature is 33.9 degrees C Digital temperature value = -689.91 C Digital temperature value = -1209.83 F Digital pressure value = 22063.12 mbar Altitude = -115882.60 feet Yaw, Pitch, Roll: 348.74, -68.06, -103.77 Grav_x, Grav_y, Grav_z: 362.85, -927.60, -88.91 mg Lin_ax, Lin_ay, Lin_az: -358.64, 928.82, 1079.45 mg sumCount = 10 sum = 38.31 rate = 0.26 Hz

[kriswiner]

mx = -48 my = 81 mz = -128 mG

this cannot be correct. Average magnetic field at Earth's surface is 0.5 Gauss...

I dont think you are roperly calibrating the mag. Check the calibration by plotting Mx vs My, Mx vs. Mz, and My vs, Mz measured while moving the sensor in a figure eight. Are they circular clouds centered on the origin?

By the way, figure eight means all aroubnd evry which way in all three dimensions.

On Mon, Sep 10, 2018 at 11:52 AM MiloMindbender notifications@github.com wrote:

Thanks @kriswiner https://github.com/kriswiner I understand your terms now, but not why it isn't working....

According to my PCB stencil I am in NED order X north, Y east, Z down. I'm double checking the signs of the data but at least the axis is correct (unless the stencil on the board is wrong) and that's the way your MPU9250_MS5637_AHRS (from this repo) sample seems to be feeding them into MadgwickQuaternionUpdate.

Your sample also seems to iterate MadgwickQuaternionUpdate 10 times on each read of the IMU and it calls your magcalMPU9250 to calibrate the magnetometer at the start of the sketch by waving the board in figure 8 patterns.

Your sketch has mmode set to 0x06 (100hz) for the mag and while I'm not entirely certain, it looks like the gyro/accel are set to 1khz .

So does this sound like things are setup as you described above?

With the board x pointed at magnetic north, the yaw reads 73 degrees.

Every time I re-do the mag calibration the bias numbers are significantly different while the scales are about the same. The accel and gyro biases are always pretty close.

I could understand north not reading as yaw 0, I don't understand a 180 degree rotation reading as 130 degrees.

Have I missed a step? If I understand you right this sample is calibrating the mag and doing the other stuff right.

MPU9250 9-axis motion sensor... MPU9250 I AM 71 I should be 71 MPU9250 is online... x-axis self test: acceleration trim within : 1.0% of factory value y-axis self test: acceleration trim within : 0.1% of factory value z-axis self test: acceleration trim within : 1.8% of factory value x-axis self test: gyration trim within : -4.1% of factory value y-axis self test: gyration trim within : -0.4% of factory value z-axis self test: gyration trim within : 0.9% of factory value Calibrate gyro and accel accel biases (mg) 35.16 0.92 22.40 gyro biases (dps) -1.81 1.92 -0.54 MPU9250 initialized for active data mode.... AK8963 I AM 48 I should be 48 AK8963 initialized for active data mode.... Mag Calibration: Wave device in a figure eight until done! Mag Calibration done! AK8963 mag biases (mG) -94.41 -10.89 47.44 AK8963 mag scale (mG) 1.57 0.71 1.04 X-Axis sensitivity adjustment value 1.21 Y-Axis sensitivity adjustment value 1.21 Z-Axis sensitivity adjustment value 1.17 MS5637 pressure sensor reset... PROM dta read: C0 = 50431 C1 = 50431 C2 = 50431 C3 = 50431 C4 = 50431 C5 = 50431 C6 = 50431 Checksum = 4 , should be 12 ax = 4.21 ay = 1.22 az = 990.54 mg gx = 0.18 gy = 0.13 gz = -0.07 deg/s mx = -48 my = 81 mz = -128 mG q0 = 0.40 qx = -0.71 qy = -0.20 qz = -0.54 Gyro temperature is 33.9 degrees C Digital temperature value = -689.91 C Digital temperature value = -1209.83 F Digital pressure value = 22063.12 mbar Altitude = -115882.60 feet Yaw, Pitch, Roll: 348.74, -68.06, -103.77 Grav_x, Grav_y, Grav_z: 362.85, -927.60, -88.91 mg Lin_ax, Lin_ay, Lin_az: -358.64, 928.82, 1079.45 mg sumCount = 10 sum = 38.31 rate = 0.26 Hz

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-420021273, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qrsGFmIPGWKzyxxGx61cjgw_C--Kks5uZrUIgaJpZM4WfU5t .

[MiloMindbender]

That comment may have solved the problem, I just noticed that when I point the thing north (and it reads 41 deg yaw) and then raise it about 3 feet off my desk. The yaw goes to zero, it takes a few seconds, but it goes.

Also, the mx value goes from about 124 on the desk to -60 3 foot above while Y and Z stay about the same.

My desk is all wood, but it seems there is a magnetic anomaly there somewhere.

If I plot a vector from the mx/my/mz would it be pointing in the direction of the strongest magnetic field (or north)? (so I could use it to track down the anomaly).

Is there a range of mx,my,mz or calibration values that would definitely be out of the normal range?

[kriswiner]

Check the expected value of MX, MY, MZ for your area from the USGS or equivalent

On Mon, Sep 10, 2018 at 1:23 PM MiloMindbender notifications@github.com wrote:

That comment may have solved the problem, I just noticed that when I point the thing north (and it reads 41 deg yaw) and then raise it about 3 feet off my desk. The yaw goes to zero, it takes a few seconds, but it goes.

Also, the mx value goes from about 124 on the desk to -60 3 foot above while Y and Z stay about the same.

My desk is all wood, but it seems there is a magnetic anomaly there somewhere.

If I plot a vector from the mx/my/mz would it be pointing in the direction of the strongest magnetic field (or north)? (so I could use it to track down the anomaly).

Is there a range of mx,my,mz or calibration values that would definitely be out of the normal range?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/ESP32/issues/17#issuecomment-420047841, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qkeNtum1-bR8r_-vGNDs39fLZ7_iks5uZspVgaJpZM4WfU5t .