Porting to Python

[kdschlosser]

I am working with an ESP32 and I am using MicroPython on the ESP32. I have not come across a working library for the mpu9250 sensors. I have ported the library you have written to Python. It does run but it is not updating properly and I am not sure as to why, there is some very complex math being used and I am not sure what the values should be at each step.

This is the output I am getting (click to expand)

``` rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:5008 ho 0 tail 12 room 4 load:0x40078000,len:10600 ho 0 tail 12 room 4 load:0x40080400,len:5684 entry 0x400806bc I (539) cpu_start: Pro cpu up. I (539) cpu_start: Application information: I (539) cpu_start: Compile time: Sep 2 2020 03:00:08 I (542) cpu_start: ELF file SHA256: 0000000000000000... I (548) cpu_start: ESP-IDF: v3.3.2 I (553) cpu_start: Starting app cpu, entry point is 0x40082f30 I (0) cpu_start: App cpu up. I (563) heap_init: Initializing. RAM available for dynamic allocation: I (570) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (576) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (582) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (588) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM I (595) heap_init: At 3FFCA9E8 len 00015618 (85 KiB): DRAM I (601) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (607) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (613) heap_init: At 4009DE28 len 000021D8 (8 KiB): IRAM I (620) cpu_start: Pro cpu start user code I (303) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (2640) pm_esp32: Frequency switching config: CPU_MAX: 240, APB_MAX: 240, APB_MIN: 240, Light sleep: DISABLED MicroPython v1.13 on 2020-09-02; ESP32 module with ESP32 Type "help()" for more information. >>> MPU9250 9-axis motion sensor... I AM 0x71 I should be 0x71 MPU9250 is online... x-axis self test: acceleration trim within: 6.457741 % of factory value y-axis self test: acceleration trim within : -13.87926 % of factory value z-axis self test: acceleration trim within : -2.408951 % of factory value x-axis self test: gyration trim within : -98.55352 % of factory value y-axis self test: gyration trim within : -114.2787 % of factory value z-axis self test: gyration trim within : -99.50471 % of factory value accel biases (mg) 2776.599 2967.328 -436.5662 gyro biases (dps) 474.8746 16.53683 470.9267 MPU9250 initialized for active data mode.... AK8963 I AM 0x48 I should be 0x48 AK8963 initialized for active data mode.... Mag Calibration: Wave device in a figure eight until done! Mag Calibration done! AK8963 mag biases (mG) 975.921 368.4808 57575.68 AK8963 mag scale (mG) 51.94824 80.57665 0.3368887 Calibration values: X-Axis sensitivity adjustment value 1.210938 Y-Axis sensitivity adjustment value 1.222656 Z-Axis sensitivity adjustment value 1.171875 ax = 0 mg ay = 0 mg az = 0 mg gx = 0.0 deg/s gy = 0.0 deg/s gz = 0.0 deg/s mx = 0 mG my = 0 mG mz = 0 mG q0 = 1.0 qx = 0.0 qy = 0.0 qz = 0.0 Gyro temperature is 21.0 degrees C Yaw, Pitch, Roll: 13.8 , -0.0 , 0.0 ax = -336 mg ay = -177 mg az = 840 mg gx = 250.0 deg/s gy = 460.6247 deg/s gz = 250.0 deg/s mx = -7592 mG my = -6499 mG mz = -19319 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.09818 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -342 mg ay = -179 mg az = 945 mg gx = 250.0 deg/s gy = 492.2791 deg/s gz = 250.0 deg/s mx = -8536 mG my = -5908 mG mz = -19326 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.09219 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -328 mg ay = -133 mg az = 918 mg gx = 250.0 deg/s gy = 471.6339 deg/s gz = 250.0 deg/s mx = -7970 mG my = -6204 mG mz = -19322 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.10717 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -358 mg ay = -117 mg az = 915 mg gx = 250.0 deg/s gy = 490.8142 deg/s gz = 250.0 deg/s mx = -8347 mG my = -6204 mG mz = -19323 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.10717 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -776 mg ay = -16 mg az = 690 mg gx = 250.0 deg/s gy = 92.59033 deg/s gz = 250.0 deg/s mx = -9762 mG my = 12851 mG mz = -19384 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11016 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -500 mg ay = -437 mg az = 721 mg gx = 250.0 deg/s gy = 468.1702 deg/s gz = 250.0 deg/s mx = -141 mG my = 8715 mG mz = -19343 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11016 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -196 mg ay = -960 mg az = 508 mg gx = 250.0 deg/s gy = 476.2726 deg/s gz = 250.0 deg/s mx = 16364 mG my = -886 mG mz = -19339 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11915 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ax = -71 mg ay = -967 mg az = 4419 mg gx = 250.0 deg/s gy = 481.6666 deg/s gz = 250.0 deg/s mx = 20420 mG my = -3988 mG mz = -19343 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.13113 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165 ```

the yaw pitch and roll never change even tho the accel, gyro and mag values change.

These are the settings that are being used. AHRS = True Gscale = GFS_250DPS Ascale = AFS_2G Mscale = MFS_16BITS Mmode = 0x06

If you are willing to help me to get this working properly that would great. I am really in need of this thing working for a project I am doing.

If you would like a copy of the ported code to have a look at it let me know. I do not know if you are familiar with Python but the syntax is really not hard to understand coming from c/cpp and is really not terribly different.

[kriswiner]

accel biases (mg) 2776.599 2967.328 -436.5662 gyro biases (dps) 474.8746 16.53683 470.9267

Not possible without a math error or broken sensor.

I suggest you look at how your code converts register data bytes into int16_t signed integers. Likely getting the byte order or 2-s complement conversion wrong.

On Sat, Feb 13, 2021 at 10:53 PM Kevin Schlosser notifications@github.com wrote:

I am working with an ESP32 and I am using MicroPython on the ESP32. I have not come across a working library for the mpu9250 sensors. I have ported the library you have written to Python. It does run but it is not updating properly and I am not sure as to why, there is some very complex math being used and I am not sure what the values should be at each step. This is the output I am getting (click to expand)

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:5008 ho 0 tail 12 room 4 load:0x40078000,len:10600 ho 0 tail 12 room 4 load:0x40080400,len:5684 entry 0x400806bc I (539) cpu_start: Pro cpu up. I (539) cpu_start: Application information: I (539) cpu_start: Compile time: Sep 2 2020 03:00:08 I (542) cpu_start: ELF file SHA256: 0000000000000000... I (548) cpu_start: ESP-IDF: v3.3.2 I (553) cpu_start: Starting app cpu, entry point is 0x40082f30 I (0) cpu_start: App cpu up. I (563) heap_init: Initializing. RAM available for dynamic allocation: I (570) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (576) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (582) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (588) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM I (595) heap_init: At 3FFCA9E8 len 00015618 (85 KiB): DRAM I (601) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (607) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (613) heap_init: At 4009DE28 len 000021D8 (8 KiB): IRAM I (620) cpu_start: Pro cpu start user code I (303) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (2640) pm_esp32: Frequency switching config: CPU_MAX: 240, APB_MAX: 240, APB_MIN: 240, Light sleep: DISABLED MicroPython v1.13 on 2020-09-02; ESP32 module with ESP32 Type "help()" for more information.

MPU9250 9-axis motion sensor... I AM 0x71 I should be 0x71 MPU9250 is online...

x-axis self test: acceleration trim within: 6.457741 % of factory value y-axis self test: acceleration trim within : -13.87926 % of factory value z-axis self test: acceleration trim within : -2.408951 % of factory value

x-axis self test: gyration trim within : -98.55352 % of factory value y-axis self test: gyration trim within : -114.2787 % of factory value z-axis self test: gyration trim within : -99.50471 % of factory value

accel biases (mg) 2776.599 2967.328 -436.5662 gyro biases (dps) 474.8746 16.53683 470.9267 MPU9250 initialized for active data mode....

AK8963 I AM 0x48 I should be 0x48 AK8963 initialized for active data mode....

Mag Calibration: Wave device in a figure eight until done! Mag Calibration done!

AK8963 mag biases (mG) 975.921 368.4808 57575.68 AK8963 mag scale (mG) 51.94824 80.57665 0.3368887

Calibration values: X-Axis sensitivity adjustment value 1.210938 Y-Axis sensitivity adjustment value 1.222656 Z-Axis sensitivity adjustment value 1.171875

ax = 0 mg ay = 0 mg az = 0 mg gx = 0.0 deg/s gy = 0.0 deg/s gz = 0.0 deg/s mx = 0 mG my = 0 mG mz = 0 mG q0 = 1.0 qx = 0.0 qy = 0.0 qz = 0.0 Gyro temperature is 21.0 degrees C Yaw, Pitch, Roll: 13.8 , -0.0 , 0.0

ax = -336 mg ay = -177 mg az = 840 mg gx = 250.0 deg/s gy = 460.6247 deg/s gz = 250.0 deg/s mx = -7592 mG my = -6499 mG mz = -19319 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.09818 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -342 mg ay = -179 mg az = 945 mg gx = 250.0 deg/s gy = 492.2791 deg/s gz = 250.0 deg/s mx = -8536 mG my = -5908 mG mz = -19326 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.09219 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -328 mg ay = -133 mg az = 918 mg gx = 250.0 deg/s gy = 471.6339 deg/s gz = 250.0 deg/s mx = -7970 mG my = -6204 mG mz = -19322 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.10717 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -358 mg ay = -117 mg az = 915 mg gx = 250.0 deg/s gy = 490.8142 deg/s gz = 250.0 deg/s mx = -8347 mG my = -6204 mG mz = -19323 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.10717 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -776 mg ay = -16 mg az = 690 mg gx = 250.0 deg/s gy = 92.59033 deg/s gz = 250.0 deg/s mx = -9762 mG my = 12851 mG mz = -19384 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11016 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -500 mg ay = -437 mg az = 721 mg gx = 250.0 deg/s gy = 468.1702 deg/s gz = 250.0 deg/s mx = -141 mG my = 8715 mG mz = -19343 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11016 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -196 mg ay = -960 mg az = 508 mg gx = 250.0 deg/s gy = 476.2726 deg/s gz = 250.0 deg/s mx = 16364 mG my = -886 mG mz = -19339 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.11915 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

ax = -71 mg ay = -967 mg az = 4419 mg gx = 250.0 deg/s gy = 481.6666 deg/s gz = 250.0 deg/s mx = 20420 mG my = -3988 mG mz = -19343 mG q0 = 0.005637491 qx = 0.7220599 qy = 0.42573 qz = -0.5452996 Gyro temperature is 27.13113 degrees C Yaw, Pitch, Roll: 99.77722 , 52.39892 , -131.6165

the yaw pitch and roll never change even tho the accel, gyro and mag values change.

These are the settings that are being used. AHRS = True Gscale = GFS_250DPS Ascale = AFS_2G Mscale = MFS_16BITS Mmode = 0x06

If you are willing to help me to get this working properly that would great. I am really in need of this thing working for a project I am doing.

If you would like a copy of the ported code to have a look at it let me know. I do not know if you are familiar with Python but the syntax is really not hard to understand coming from c/cpp and is really not terribly different.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWLASFBDPIYO2UTC3LS65XNPANCNFSM4XS55PEA .

[kdschlosser]

i am pretty sure it is a bad sensor. I got 2 of them from amazon and one of them had locked readings right out of the package. and now this one is acting all screwy as well. All of the ones being sold now are counterfeit as TDK stopped making the things and marked them as EOL back in 2018 and the last orders were taken in Feb of 2019. I ordered up 2 ICM-20948's IDK what kind of changes are going to need to be made for these sensors to work.

Exactly how you are doing it in your script I am doing it as well.

here are the read functions.

def readMPU9250Data(destination):
    rawData = [0] * 14  
    readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 14, rawData) 
    destination[0] = (int(rawData[0]) << 8) | rawData[1]  
    destination[1] = (int(rawData[2]) << 8) | rawData[3]
    destination[2] = (int(rawData[4]) << 8) | rawData[5]
    destination[3] = (int(rawData[6]) << 8) | rawData[7]
    destination[4] = (int(rawData[8]) << 8) | rawData[9]
    destination[5] = (int(rawData[10]) << 8) | rawData[11]
    destination[6] = (int(rawData[12]) << 8) | rawData[13]

def readAccelData(destination):
    rawData = [0] * 6  
    readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 6, rawData)  
    destination[0] = (int(rawData[0]) << 8) | rawData[1]  
    destination[1] = (int(rawData[2]) << 8) | rawData[3]
    destination[2] = (int(rawData[4]) << 8) | rawData[5]

def readGyroData(destination):
    rawData = [0] * 6  
    readBytes(MPU9250_ADDRESS, GYRO_XOUT_H, 6, rawData)  
    destination[0] = (int(rawData[0]) << 8) | rawData[1]  
    destination[1] = (int(rawData[2]) << 8) | rawData[3]
    destination[2] = (int(rawData[4]) << 8) | rawData[5]

def readMagData(destination):
    rawData = [0] * 7  
    if readByte(AK8963_ADDRESS, AK8963_ST1) & 0x01: 
        readBytes(AK8963_ADDRESS, AK8963_XOUT_L, 7, rawData)  
        c = rawData[6] 
        if not c & 0x08: 
            destination[0] = (int(rawData[1]) << 8) | rawData[0]  
            destination[1] = (int(rawData[3]) << 8) | rawData[2]  
            destination[2] = (int(rawData[5]) << 8) | rawData[4]

def readTempData():
    rawData = [0] * 2  
    readBytes(MPU9250_ADDRESS, TEMP_OUT_H, 2, rawData)  
    return (int(rawData[0]) << 8) | rawData[1]  

[kdschlosser]

and then the portion in the loop function

    if newData is True:  
        newData = False  
        readMPU9250Data(MPU9250Data) 
        ax = float(MPU9250Data[0]) * aRes - accelBias[0]  
        ay = float(MPU9250Data[1]) * aRes - accelBias[1]
        az = float(MPU9250Data[2]) * aRes - accelBias[2]
        gx = float(MPU9250Data[4]) * gRes  
        gy = float(MPU9250Data[5]) * gRes
        gz = float(MPU9250Data[6]) * gRes
        newMagData = bool(readByte(AK8963_ADDRESS, AK8963_ST1) & 0x01)
        if newMagData is True:
            readMagData(magCount)  
            mx = float(magCount[0]) * mRes * magCalibration[0] - magBias[0]  
            my = float(magCount[1]) * mRes * magCalibration[1] - magBias[1]
            mz = float(magCount[2]) * mRes * magCalibration[2] - magBias[2]
            mx *= magScale[0]
            my *= magScale[1]
            mz *= magScale[2]

[kriswiner]

destination[0] = (int(rawData[0]) << 8) | rawData[1]

This implicit conversion from bytes to signed integer is based on C++, might not work in python. I am suggesting that you simply check it.

On Sun, Feb 14, 2021 at 10:06 AM Kevin Schlosser notifications@github.com wrote:

and then the portion in the loop function

if newData is True:
    newData = False
    readMPU9250Data(MPU9250Data)
    ax = float(MPU9250Data[0]) * aRes - accelBias[0]
    ay = float(MPU9250Data[1]) * aRes - accelBias[1]
    az = float(MPU9250Data[2]) * aRes - accelBias[2]
    gx = float(MPU9250Data[4]) * gRes
    gy = float(MPU9250Data[5]) * gRes
    gz = float(MPU9250Data[6]) * gRes
    newMagData = bool(readByte(AK8963_ADDRESS, AK8963_ST1) & 0x01)
    if newMagData is True:
        readMagData(magCount)
        mx = float(magCount[0]) * mRes * magCalibration[0] - magBias[0]
        my = float(magCount[1]) * mRes * magCalibration[1] - magBias[1]
        mz = float(magCount[2]) * mRes * magCalibration[2] - magBias[2]
        mx *= magScale[0]
        my *= magScale[1]
        mz *= magScale[2]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-778815973, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUU2CQXMQWX525KOETS7AGLHANCNFSM4XS55PEA .

[kriswiner]

Maybe start with something known to work like this and this?

Or better yet, this.

[hedayat95]

Hi Kris, Offset shift may exist after the MEMS motion sensor being mounted onto the PCB board. some of my sensor had 11G bias . I change full scale rang to 16G and calibrate it and work well. I have a question about i2c multiplexer. I have 2 tca9548a . I can read 8 sensor without any problem, but when I switched to the second i2c multiplexer IC , I couldn't read magnetometer but read accel and gyro. I checked it with a scope and noticed that when I switch, the clock change to 330kHZ and voltage level is not good(a bit) . Do you have any idea for me? decrease or increase the pull up resistors(10k)? how can get the enough time to stablish the clock and make connection with magnetometer ?, thanx #need help

[kriswiner]

11G as in 11 x gravity? This is a bad sensor indeed! I wouldn't use it.

If you have a lot of capacitance (sensors) on the I2C bus then you might need to drop the pullup values. I would use 2K2 for 8 sensors on a single bus. But I don;t know enough about your system to really be sure this is the problem. Kind of out of my area of expertise...

On Sun, Feb 14, 2021 at 12:05 PM hedayat95 notifications@github.com wrote:

Hi Kris, Offset shift may exist after the MEMS motion sensor being mounted onto the PCB board. some of my sensor had 11G bias . I change full scale rang to 16G and calibrate it and work well. I have a question about i2c multiplexer. I have 2 tca9548a . I can read 8 sensor without any problem, but when I switched to the second i2c multiplexer IC , I couldn't read magnetometer but read accel and gyro. I checked it with a scope and noticed that when I switch, the clock change to 330kHZ and voltage level is not good(a bit) . Do you have any idea for me? decrease or increase the pull up resistors(10k)? how can get the enough time to stablish the clock and make connection with magnetometer ?, thanx

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-778833843, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKR3SEBR4INYRAV7SHLS7AUHFANCNFSM4XS55PEA .

[hedayat95]

That bias is not for ADC or measurement, it is just because of Offset Registers.

when I use i2c multiplexer that means in each channel I have just one sensor . is it right? and the problem happened when the second Tca9548 selected . can I use tow i2c bus simultaneously in teensy3.2 with i2c_t3.h library?

[kdschlosser]

i could slap myself in the forehead. you are correct with the bit shifting C++ does the conversion internally where as Python does not, not to a signed integer. I need to instill twos complement in order to get it to be signed.. I need to keep it just like it is and then process it with twos compliment to change the 16 bit unsigned integer to signed.

I knew another set of eyes would help me out with this.

[kdschlosser]

and none of those solutions would work for me. I am not building a quadcopter/drone. I am not using these sensors for anything flight related.

What I am building is a set of horizon active and curve active headlamps for my car. In each headlamp there is going to be the following.

esp32 8 port PWM servo controller 4 servos 8 limit switches mpu9250 CAN-Bus interface 1.3" OLED display 4 button key pad

so I need to have a decent number of GPIO pins available. I am using the mpu9250 for pitch and roll and probably use the yaw in conjunction with the steering angle I get from the cars stability control system.

I have one of the lenses almost complete as far as the mechanical end of it and I have it all set up with the electronics. I have most of the control software written I have to go through the code and test each piece of it to make sure it works, then put the pieces together and deal with code cleanup and memory management problems that I know are going to arise.

[kdschlosser]

ok so I added in the unsigned to signed conversion. and this is what the numbers look like now

x-axis self test: acceleration trim within:  1.550003 % of factory value
y-axis self test: acceleration trim within : -0.8949127 % of factory value
z-axis self test: acceleration trim within : -0.7434082 % of factory value
x-axis self test: gyration trim within : -66.70217 % of factory value
y-axis self test: gyration trim within : 28.17288 % of factory value
z-axis self test: gyration trim within : 4.269691 % of factory value

accel biases (mg) -1103.717 -1167.407 -426.3733
gyro biases (dps) -0.754771 1.362786 -26.77824
MPU9250 initialized for active data mode....

AK8963  I AM 0x48  I should be 0x48
AK8963 initialized for active data mode....

Mag Calibration: Wave device in a figure eight until done!
Mag Calibration done!

AK8963 mag biases (mG) -48.11517 642.5498 1614.772
AK8963 mag scale (mG) 1.061728 0.9885057 0.9555555

Calibration values:
X-Axis sensitivity adjustment value  1.210938
Y-Axis sensitivity adjustment value  1.222656
Z-Axis sensitivity adjustment value  1.171875

ax =  0  mg
 ay =  0  mg
 az =  0  mg
gx =  0.0  deg/s
 gy =  0.0  deg/s
 gz =  0.0  deg/s
mx =  0 mG
 my =  0 mG
 mz =  0 mG
q0 =  1.0
 qx =  0.0
 qy =  0.0
 qz =  0.0
Gyro temperature is  21.0  degrees C
Yaw, Pitch, Roll:  13.8 ,  -0.0 ,  0.0

ax =  0  mg
 ay =  -2  mg
 az =  993  mg
gx =  0.02288818  deg/s
 gy =  0.02288818  deg/s
 gz =  0.3585815  deg/s
mx =  18 mG
 my =  4 mG
 mz =  6 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.18426  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  4.086046  Hz

ax =  0  mg
 ay =  -2  mg
 az =  996  mg
gx =  0.01525879  deg/s
 gy =  0.08392334  deg/s
 gz =  0.2746582  deg/s
mx =  4 mG
 my =  2 mG
 mz =  8 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.17827  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  352.7573  Hz

ax =  0  mg
 ay =  -1  mg
 az =  996  mg
gx =  -0.08392334  deg/s
 gy =  0.1144409  deg/s
 gz =  -0.1068115  deg/s
mx =  -10 mG
 my =  6 mG
 mz =  5 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.1603  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.4981  Hz

ax =  1  mg
 ay =  -2  mg
 az =  998  mg
gx =  -0.1068115  deg/s
 gy =  0.08392334  deg/s
 gz =  -0.03814697  deg/s
mx =  -8 mG
 my =  -9 mG
 mz =  0 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.18426  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  353.1415  Hz

ax =  0  mg
 ay =  -2  mg
 az =  998  mg
gx =  -0.1296997  deg/s
 gy =  0.05340576  deg/s
 gz =  0.1831055  deg/s
mx =  0 mG
 my =  -2 mG
 mz =  -6 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.19026  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.3262  Hz

ax =  -1  mg
 ay =  0  mg
 az =  998  mg
gx =  -0.07629395  deg/s
 gy =  0.1296997  deg/s
 gz =  0.2441406  deg/s
mx =  -4 mG
 my =  4 mG
 mz =  -6 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.18127  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.4107  Hz

ax =  0  mg
 ay =  -3  mg
 az =  999  mg
gx =  -0.1296997  deg/s
 gy =  0.03814697  deg/s
 gz =  0.1602173  deg/s
mx =  10 mG
 my =  -2 mG
 mz =  3 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.16929  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.1419  Hz

ax =  1  mg
 ay =  -3  mg
 az =  996  mg
gx =  -0.05340576  deg/s
 gy =  0.08392334  deg/s
 gz =  0.08392334  deg/s
mx =  0 mG
 my =  9 mG
 mz =  -5 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.15731  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.4711  Hz

ax =  -1  mg
 ay =  -3  mg
 az =  995  mg
gx =  -0.1068115  deg/s
 gy =  0.1144409  deg/s
 gz =  0.07629395  deg/s
mx =  0 mG
 my =  2 mG
 mz =  8 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.14233  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  353.3693  Hz

ax =  0  mg
 ay =  0  mg
 az =  998  mg
gx =  -0.007629395  deg/s
 gy =  0.05340576  deg/s
 gz =  0.1068115  deg/s
mx =  12 mG
 my =  0 mG
 mz =  1 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.17827  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  354.4842  Hz

ax =  -1  mg
 ay =  -2  mg
 az =  998  mg
gx =  -0.06866455  deg/s
 gy =  0.06866455  deg/s
 gz =  0.1754761  deg/s
mx =  0 mG
 my =  2 mG
 mz =  -1 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.18726  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  352.8857  Hz

ax =  0  mg
 ay =  -2  mg
 az =  996  mg
gx =  0.03051758  deg/s
 gy =  0.007629395  deg/s
 gz =  0.07629395  deg/s
mx =  -6 mG
 my =  2 mG
 mz =  -15 mG
q0 =  0.0366761
 qx =  0.001199451
 qy =  -0.02266953
 qz =  -0.9990693
Gyro temperature is  25.17528  degrees C
Yaw, Pitch, Roll:  198.0058 ,  0.04204425 ,  2.601254
rate =  348.9118  Hz

[kriswiner]

Mag is way wrong still; gyro awfully noisy.. How did you calibrate the sensors.

The flight controller board is useful for not only UAVs. It has an easy-to-program STM32L4 as well as a full 10 DoF sensor suite with motion co-processor. So if you need to measure absolute orientation for any purpose, this would be an easy way to do it accurately with little fuss...

On Sun, Feb 14, 2021 at 3:10 PM Kevin Schlosser notifications@github.com wrote:

ok so I added in the unsigned to signed conversion. and this is what the numbers look like now

x-axis self test: acceleration trim within: 1.550003 % of factory value y-axis self test: acceleration trim within : -0.8949127 % of factory value z-axis self test: acceleration trim within : -0.7434082 % of factory value x-axis self test: gyration trim within : -66.70217 % of factory value y-axis self test: gyration trim within : 28.17288 % of factory value z-axis self test: gyration trim within : 4.269691 % of factory value

accel biases (mg) -1103.717 -1167.407 -426.3733 gyro biases (dps) -0.754771 1.362786 -26.77824 MPU9250 initialized for active data mode....

AK8963 I AM 0x48 I should be 0x48 AK8963 initialized for active data mode....

Mag Calibration: Wave device in a figure eight until done! Mag Calibration done!

AK8963 mag biases (mG) -48.11517 642.5498 1614.772 AK8963 mag scale (mG) 1.061728 0.9885057 0.9555555

Calibration values: X-Axis sensitivity adjustment value 1.210938 Y-Axis sensitivity adjustment value 1.222656 Z-Axis sensitivity adjustment value 1.171875

ax = 0 mg ay = 0 mg az = 0 mg gx = 0.0 deg/s gy = 0.0 deg/s gz = 0.0 deg/s mx = 0 mG my = 0 mG mz = 0 mG q0 = 1.0 qx = 0.0 qy = 0.0 qz = 0.0 Gyro temperature is 21.0 degrees C Yaw, Pitch, Roll: 13.8 , -0.0 , 0.0

ax = 0 mg ay = -2 mg az = 993 mg gx = 0.02288818 deg/s gy = 0.02288818 deg/s gz = 0.3585815 deg/s mx = 18 mG my = 4 mG mz = 6 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.18426 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 4.086046 Hz

ax = 0 mg ay = -2 mg az = 996 mg gx = 0.01525879 deg/s gy = 0.08392334 deg/s gz = 0.2746582 deg/s mx = 4 mG my = 2 mG mz = 8 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.17827 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 352.7573 Hz

ax = 0 mg ay = -1 mg az = 996 mg gx = -0.08392334 deg/s gy = 0.1144409 deg/s gz = -0.1068115 deg/s mx = -10 mG my = 6 mG mz = 5 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.1603 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.4981 Hz

ax = 1 mg ay = -2 mg az = 998 mg gx = -0.1068115 deg/s gy = 0.08392334 deg/s gz = -0.03814697 deg/s mx = -8 mG my = -9 mG mz = 0 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.18426 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 353.1415 Hz

ax = 0 mg ay = -2 mg az = 998 mg gx = -0.1296997 deg/s gy = 0.05340576 deg/s gz = 0.1831055 deg/s mx = 0 mG my = -2 mG mz = -6 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.19026 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.3262 Hz

ax = -1 mg ay = 0 mg az = 998 mg gx = -0.07629395 deg/s gy = 0.1296997 deg/s gz = 0.2441406 deg/s mx = -4 mG my = 4 mG mz = -6 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.18127 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.4107 Hz

ax = 0 mg ay = -3 mg az = 999 mg gx = -0.1296997 deg/s gy = 0.03814697 deg/s gz = 0.1602173 deg/s mx = 10 mG my = -2 mG mz = 3 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.16929 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.1419 Hz

ax = 1 mg ay = -3 mg az = 996 mg gx = -0.05340576 deg/s gy = 0.08392334 deg/s gz = 0.08392334 deg/s mx = 0 mG my = 9 mG mz = -5 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.15731 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.4711 Hz

ax = -1 mg ay = -3 mg az = 995 mg gx = -0.1068115 deg/s gy = 0.1144409 deg/s gz = 0.07629395 deg/s mx = 0 mG my = 2 mG mz = 8 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.14233 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 353.3693 Hz

ax = 0 mg ay = 0 mg az = 998 mg gx = -0.007629395 deg/s gy = 0.05340576 deg/s gz = 0.1068115 deg/s mx = 12 mG my = 0 mG mz = 1 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.17827 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 354.4842 Hz

ax = -1 mg ay = -2 mg az = 998 mg gx = -0.06866455 deg/s gy = 0.06866455 deg/s gz = 0.1754761 deg/s mx = 0 mG my = 2 mG mz = -1 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.18726 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 352.8857 Hz

ax = 0 mg ay = -2 mg az = 996 mg gx = 0.03051758 deg/s gy = 0.007629395 deg/s gz = 0.07629395 deg/s mx = -6 mG my = 2 mG mz = -15 mG q0 = 0.0366761 qx = 0.001199451 qy = -0.02266953 qz = -0.9990693 Gyro temperature is 25.17528 degrees C Yaw, Pitch, Roll: 198.0058 , 0.04204425 , 2.601254 rate = 348.9118 Hz

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-778857830, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRDSWLS4ZQIVVD7ISTS7BJ6DANCNFSM4XS55PEA .

[kdschlosser]

they are calibrated using whatever mechanism is in place to calibrate them in the script.

[kriswiner]

So you don't know, and this is the reason why the AHRS solution is crappy.

On Sun, Feb 14, 2021 at 4:04 PM Kevin Schlosser notifications@github.com wrote:

they are calibrated using whatever mechanism is in place to calibrate them in the script.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-778865481, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTHTF5YNFGOB2VWTY3S7BQKBANCNFSM4XS55PEA .

[kdschlosser]

????? ya lost me...

[kriswiner]

How do you know the sensors are properly calibrated? How did you check?

On Sun, Feb 14, 2021 at 10:18 PM Kevin Schlosser notifications@github.com wrote:

????? ya lost me...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-778975666, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKURNJ7VETGKYAELQZDS7C4DDANCNFSM4XS55PEA .

[kdschlosser]

As far as the calibration is concerned, I am not concerned about it actually. the reason why is I am looking at the change in values, not the values themselves. so as an example if the sensor starts off with a reading of 10 for the pitch and the next time I collect the data it is an 11 the only thing I care about is the 1 the difference between the 2 values. so now I know the pitch changed by 1 degree and that I need to make an adjustment based on the change.

I did get it working, it works good if a small amount of latency is not going to cause a problem. with what I am doing I need as close to real time as I can get. I can most likely get rid of the latency if I write it in C code and compile the sensor driver as a c extension for Python. That would be a large undertaking for myself as I am not familiar with the MicroPython C API, and I am not seasoned in writing C code. I did get the update frequency to 500hz, I believe it needs to be somewhere around 2000hz in order to not have any latency and MicroPython simply has to much overhead in order to accomplish that using Python code.

So now I am going to change gears somewhat and I am going to ask questions about the sensors that you sell. These have their own processor and memory so that is a plus... do the sensors come pre loaded with firmware? and if so does that firmware communicate over I2C or SPI, preferably SPI?. Also can it be set up so there is a pin that can be pulled high or low that can be connected to another micro controller for an interrupt? If it is pre loaded with firmware and that firmware does the above mentioned things, then I can see spending $50.00 on them. I would need 2 of them to start off with. once I have the prototype up and running There is a list of people that are ready to place orders. so it would not be a one time thing, this might be a motivator if there is no firmware that is already written. You are far more knowledgeable with these sensors and the calculations then I am. If there is no firmware available you would be a hell of a lot faster at putting something together then I would.

I need to be able to collect the roll pitch and yaw from it. and I would need to pass the user changeable settings to the sensor. If there is an option to set the decimal places to round to and an option that would smooth the data some that would be a huge plus.

[kriswiner]

Both the EM7180-based or MAX32660-based motion co-processor solutions use I2C to read scaled sensor data, Euler angles, quaternions, etc at the rate of the gyro. The former guaranteed up to 400 Hz, the latter we have tested at up to 1660 Hz, but this is really overkill.

They both have a data ready interrupt, both come with necessary firmware loaded onto the co-processor and there are well-commented Arduino (C++) sketches on github to make them run on many popular host MCUs (ESP32, Teensy, STM32, etc).

The USFSMAX module cones pre-calibrated, so it is more of a plug and play solution but it still requires https://github.com/gregtomasch/USFSMAX_MMC_Module a knowledgeable user to get best results.

The standard USFS with either MPU9250 or LSM6DSM+LIS2MDL sensors will deliver ~2 degree rms heading estimation, while the USFSMAXModule (our latest) deliver <<1 degree rms heading accuracy.

Cheapest option would be to try this https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/ and see if you can get reasonable (~2 degree heading accuracy) out of it. If so, you can move to the USFSMAX for better accuracy if needed for your application. If it was me, I would go right for the best solution available and pay the extra $14. But not all applications require << 1 degree heading accuracy,.....

On Mon, Feb 15, 2021 at 7:05 AM Kevin Schlosser notifications@github.com wrote:

As far as the calibration is concerned, I am not concerned about it actually. the reason why is I am looking at the change in values, not the values themselves. so as an example if the sensor starts off with a reading of 10 for the pitch and the next time I collect the data it is an 11 the only thing I care about is the 1 the difference between the 2 values. so now I know the pitch changed by 1 degree and that I need to make an adjustment based on the change.

I did get it working, it works good if a smll amount of latency is not going to cause a problem. with what I am going I need as close to real time as I can get. works OK. I can most likely get rid of the latency if I write it in C code and compile the sensor driver as a c extension for Python. That would be a large undertaking for myself as I am not familiar with the MicroPython C API, and I am not seasoned in writing C code. I did get the update frequency to 500hz, I believe it needs to be somewhere around 2000hz in order to not have any latency and MicroPython simply has to much overhead in order to accomplish that using Python code.

So now I am going to change gears somewhat and I am going to ask questions about the sensors that you sell. These have their own processor and memory so that is a plus... do the sensors come pre loaded with firmware? and if so does that firmware communicate over I2C or SPI, preferably SPI?. Also can it be set up so there is a pin that can be pulled high or low that can be connected to another micro controller for an interrupt? If it is pre loaded with firmware and that firmware does the above mentioned things, then I can see spending $50.00 on them. I would need 2 of them to start off with. once I have the prototype up and running There is a list of people that are ready to place orders. so it would not be a one time thing, this might be a motivator if there is no firmware that is already written. You are far more knowledgeable with these sensors and the calculations then I am. If there is no firmware available you would be a hell of a lot faster at putting something together then I would.

I need to be able to collect the roll pitch and yaw from it. and I would need to pass the user changeable settings to the sensor. If there is an option to set the decimal places to round to and an option that would smooth the data some that would be a huge plus.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779279287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRVEI7D2LH6MVVIB2LS7EZ27ANCNFSM4XS55PEA .

[hedayat95]

please answer my question.

[kriswiner]

I have no idea how you can get better results from the tCA9548A.

On Mon, Feb 15, 2021 at 1:05 PM hedayat95 notifications@github.com wrote:

please answer my question.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779446858, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKU7A6WT32K7Z422TQ3S7GEAXANCNFSM4XS55PEA .

[hedayat95]

I have tow i2c multiplexer(Tca9548a). the first one read 8 sensors without any problem. but when I switched to the second Tca9548 the magnetometer lost connection (all of them). which function in i2c_t3.h library can help for this bug

[kriswiner]

please ask at the Teensy forum, I can't help you.

On Mon, Feb 15, 2021 at 1:12 PM hedayat95 notifications@github.com wrote:

I have tow i2c multiplexer(Tca9548a). the first one read 8 sensors without any problem. but when I switched to the second Tca9548 the magnetometer lost connection (all of them). which function in i2c_t3.h library can help for this bug

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779449644, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSHQZ2VGDKT5JGPFGDS7GE3RANCNFSM4XS55PEA .

[hedayat95]

ok . thank you very much

[kdschlosser]

with my application the heading is less important then the pitch and roll. I am able to use the steering angle sensor that is apart of the vehicles stability control system. The heading would used as a backup/double check that the steering angle sensor is functioning properly. don't want to be blinding oncoming traffic because of a bad steering angle sensor. and I do not want to have what I am building to stop working if the steering angle sensor goes bad.... I will need to have the <1° accuracy. the servos I am using have a 0.12° precision so the need for <1° precision is pretty much a requirement. The only thing I am trying to figure out how to tackle is the mag calibration. The electronics are going to be installed inside of the headlight and attached to a car. so not exactly something that is going to be able to be waved about in a figure 8 pattern. Is there a way to build the mag calibration data in more of a "live" type of situation? where it would be updating the calibration while it was in use?.. The calibration data could be written to the flash between power cycles.

It looks like the accel and gyro bias calibrations require the sensors to be motionless this is not a problem because it takes a few seconds from the time a car gets powered on to the time it starts moving. This is more then enough time to get that portion done.

I am going to be using a 15 farad super cap to keep the power for a few seconds after the vehicle has been turned off. this should give me more then enough time to move the lamps into a parked position and save any data that I need to save. The data would also be saved at specified time intervals. I am going to connect one of the micro controllers GPIO pins to the input voltage before the cap so the micro controller will know when it has been powered off.

How well do these things operate in a high temperature environment? The temps might get upwards of 140 degrees or so inside the headlamp housing. If I do run into a temperature issue I will be using 40mm Noctua suspended oil bearing fans to cool things down. Or I will add onto the housing to make a separate compartment for the electronics, if I am unable to manage the temps using the fans.

Also I am OK with overkill. overkill is a good thing... rather have to much then not enough. I need speed from this thing. Pointing the headlights down 1 second after the front of a vehicle reaches the top of a speed bump is 1 second to late. By that time the front of the car will already be over the speed bump. This is going to be installed into motor vehicles, Everything has to be more then what is needed. don't want to have things fail or act in a manner they aren't supposed to.

[kdschlosser]

maybe changing the name of the issue will keep it from getting hijacked LOL..

[kriswiner]

From the github link I sent you previously:

"There are actually two user-selectable versions of the DHI corrector available: 3-D and 2-D. They are both capable of yielding excellent hard iron correction offset estimates but are intended for different use cases. If the test object to which the USFSMAX is attached is small/light and can easily be tumbled in 3-Space, the 3-D corrector is the best choice. If the test object is unwieldy or its motion is largely constrained to the X-Y (horizontal) plane the 2-D corrector may be a better choice. Both correctors collect a pre-determined number of data points at enforced spatial separation before calculating the final correction estimate. When the estimate is complete, the hard iron corrector status bit in the calibration status register toggles true (0->128) and the R-squared value populates the appropriate I2C data registers. The DHI corrector version is chosen by user command from the host MCU, defined in the "config.h" tab of the example sketches in this repository. To get the best hard iron correction estimate:

• 3-D corrector: Tumble the USFSMAX (attached to the test object) in 3-Space trying to sample all possible orientations. Training should take ~60-90s. If done properly, R-square >= 0.98 is quite normal
• 2-D corrector: Rotate the USFSMAX (attached to the test object) in the X-Y (horizontal) plane. The 2D corrector algorithm has been updated to correct for tilt when data points are within +/-10deg of level. For larger tilts, data are rejected. Training should complete in ~20 revolutions in the X-Y plane. If done properly, R-square >= 0.98 is quite normal"

This allows some correction for magnetic field environment when installed. Temperature range is typical consumer range -40 C to 85 C.

On Mon, Feb 15, 2021 at 3:19 PM Kevin Schlosser notifications@github.com wrote:

with my application the heading is less important then the pitch and roll. I am able to use the steering angle sensor that is apart of the vehicles stability control system. The heading would used as a backup/double check that the steering angle sensor is functioning properly. don't want to be blinding oncoming traffic because of a bad steering angle sensor. and I do not want to have what I am building to stop working if the steering angle sensor goes bad.... I will need to have the <1° accuracy. the servos I am using have a 0.12° precision so the need for <1° precision is pretty much a requirement. The only thing I am trying to figure out how to tackle is the mag calibration. The electronics are going to be installed inside of the headlight and attached to a car. so not exactly something that is going to be able to be waxed about in a figure 8 pattern. Is there a way to build the mag calibration data in more of a "live" type of situation? where it would be updating the calibration while it was in use?.. The calibration data could be written to the flash between power cycles.

It looks like the accel and gyro bias calibrations require the sensors to be motionless this is not a problem because it takes a few seconds from the time a car gets powered on to the time it starts moving. This is more then enough time to get that portion done.

I am going to be using a 15 farad super cap to keep the power for a few seconds after the vehicle has been turned off. this should give me more then enough time to move the lamps into a parked position and save any data that I need to save. The data would also be saved at specified time intervals. I am going to connect one of the micro controllers GPIO pins to the input voltage before the cap so the micro controller will know when it has been powered off.

How well do these things operate in a high temperature environment? The temps might get upwards of 140 degrees or so inside the headlamp housing. If I do run into a temperature issue I will be using 40mm Noctua suspended oil bearing fans to cool things down. Or I will add onto the housing to make a separate compartment for the electronics, if I am unable to manage the temps using the fans.

Also I am OK with overkill. overkill is a good thing... rather have to much then not enough. I need speed from this thing. Pointing the headlights down 1 second after the front of a vehicle reaches the top of a speed bump is 1 second to late. By that time the front of the car will already be over the speed bump. This is going to be installed into motor vehicles, Everything has to be more then what is needed. don't want to have things fail or act in a manner they aren't supposed to.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779489789, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRS2VTWD7FCD5H6RXTS7GTY3ANCNFSM4XS55PEA .

[kriswiner]

Lots of people are starved for attention (and help with their troubles)...

On Mon, Feb 15, 2021 at 3:24 PM Kevin Schlosser notifications@github.com wrote:

maybe changing the name of the issue will keep it from getting hijacked LOL..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779491073, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKT7MJFN32XQ4PE7DWDS7GUJZANCNFSM4XS55PEA .

[kdschlosser]

Lots of people are starved for attention (and help with their troubles)...

Yeah I hear ya on that one...

I am still stuck with the calibration even using a 2D model as I am not able to move a full sized car in a manner that would allow the calibration to work properly. It is something that would have to be done over time and use of the vehicle. I don't think that have to drive the car in circles 20 times in order to calibrate would be an ideal way to go about it.

I do not know if a dynamic approach exists or has even been tried. The calibration would get better as the sensor gets used. Maybe doing something like the following. With the mag sensor all of the sample points used in the calibration are collected within a specified period of time, instead of doing that collect samples at random intervals during the operation/use of the sensor and each time a sample is collected then recalculate the calibrations. I would think that this approach would produce a more accurate calibration and it would be a calibration that changes along with the environment the sensor is in.

so as an example If I calibrate the mag sensor for a flight controller the traditional way, and then while operating the aircraft if I happen to be flying in an area that for some reason has a higher level of magnetic fields in the area the mag in the flight controller is no longer going to be able to function properly. Where as a system that calibrates on the fly would be able to adjust...

Maybe I am not understanding what exactly the calibration does, I am taking it as the sensor is being calibrated to the environment around it. but with something like an aircraft or a vehicle that environment is in a constant state of change so calibrating to a specific point in a single location doesn't seem like it would produce the best calibration.

[kriswiner]

The good news is that even though dynamic hard iron correction is likely required, it would have to be done only once, or once in a great while. No way around the need to calibrate if you want accuracy. The 2D corrector is feasible in your application. Without it you would have very large heading errors.

On Mon, Feb 15, 2021 at 4:22 PM Kevin Schlosser notifications@github.com wrote:

Lots of people are starved for attention (and help with their troubles)...

Yeah I hear ya on that one...

I am still stuck with the calibration even using a 2D model as I am not able to move a full sized car in a manner that would allow the calibration to work properly. It is something that would have to be done over time and use of the vehicle. I don't think that have to drive the car in circles 20 times in order to calibrate would be an ideal way to go about it.

I do not know if a dynamic approach exists or has even been tried. The calibration would get better as the sensor gets used. Maybe doing something like the following. With the mag sensor all of the sample points used in the calibration are collected within a specified period of time, instead of doing that collect samples at random intervals during the operation/use of the sensor and each time a sample is collected then recalculate the calibrations. I would think that this approach would produce a more accurate calibration and it would be a calibration that changes along with the environment the sensor is in.

so as an example If I calibrate the mag sensor for a flight controller the traditional way, and then while operating the aircraft if I happen to be flying in an area that for some reason has a higher level of magnetic fields in the area the mag in the flight controller is no longer going to be able to function properly. Where as a system that calibrates on the fly would be able to adjust...

Maybe I am not understanding what exactly the calibration does, I am taking it as the sensor is being calibrated to the environment around it. but with something like an aircraft or a vehicle that environment is in a constant state of change so calibrating to a specific point in a single location doesn't seem like it would produce the best calibration.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/454#issuecomment-779506673, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTVWVIDTMNVSJI7UX3S7G3DRANCNFSM4XS55PEA .