Doesn't seem to be working

phase1 commented 10 years ago

Hello Kris,

I have downloaded the source to the 9250 AHRS, but the system dones't seem to be functioning well at all.

The problems i'm experiencing are that the sensor fusion will settle on a value yaw value and whenever the IMU is rotated on the yaw axis, the yaw ill move slightly, and then return to the settled value it initialized to. The roll and the pitch axis are fine and working.

I'm not sure what I should be doing to help correct the problem.

Thanks

floflofloflo commented 9 years ago

Hi, I am rewriting my IMU with fixed point math, I was really keen to explore this device (MPU9250) but it is really confusing. I will setup 2 FW with accel_fchoice_b set to 0 and 1 and see what is the outcome; thanks for your init code I am checking it. I ve played already with the magnetometer AK8963, my first impression is that it shows lower performance than freescale or honeywell. Honeywell has been the reference so far for me, even STMICRO is using their techno in their sensors. The AKM chip seems OK but heading is quite unstable in the degrees range while other sensors are OK with the same algo.

floflofloflo commented 9 years ago

The other point is we dont know how the data is sync from magnetometer versus gyro/Acc...It seems the MPU9250 send a single measurement command to the AK8963 @ ODR rate, and it takes roughly 10ms to get the magnetometer data. there could be a latency time of 10ms max that would decrease the performance of the IMU filter (like Kalman), we are supposed to feed this kind of algos with synchronized inputs. That could lead to issues at higher rates like the one you are using. I haven t asked invensense since they never reply!

kriswiner commented 9 years ago

This is the opposite to my experience. I have found Freescale's mags to be low resolution and jittery while the AK mags, when properly calibrated for bias, provide pretty steady data and a good heading accuracy in sensor fusion.

The MPU9250 does require a bit of concentration to learn to use well but it's not really that much harder than any other sensor solution. Take a look at the BMX055 mag in comparison. The sensor data has to be converted to magnetic field in software. Ridiculous!

I have found the MPU9250 to be the best overall 9 DoF in terms of low jitter and drift. These are more important to me than a few extra minutes parsing the data sheet.

Kris

-----Original Message----- From: floflofloflo [mailto:notifications@github.com] Sent: June 18, 2015 10:49 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi, I am rewriting my IMU with fixed point math, I was really keen to explore this device (MPU9250) but it is really confusing. I will setup 2 FW with accel_fchoice_b set to 0 and 1 and see what is the outcome; thanks for your init code I am checking it. I ve played already with the magnetometer AK8963, my first impression is that it shows lower performance than freescale or honeywell. Honeywell has been the reference so far for me, even STMICRO is using their techno in their sensors. The AKM chip seems OK but heading is quite unstable in the degrees range while other sensors are OK with the same algo.

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-113382433 . https://github.com/notifications/beacon/AGY1qnudRwR36UwGxviDC4q6oAVm8LKDks5 oU6TOgaJpZM4CEl0o.gif

kriswiner commented 9 years ago

I agree Invensense is not very responsive. AFAIK one cannot get the mag data into the FIFO. That is the way to guarantee time syncing. So yes, there will be some latency, but at 100 Hz continuous read it shouldn't be too bad for all but the most demanding applications.

-----Original Message-----. From: floflofloflo [mailto:notifications@github.com] Sent: June 19, 2015 12:01 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

The other point is we dont know how the data is sync from magnetometer versus gyro/Acc...It seems the MPU9250 send a single measurement command to the AK8963 @ ODR rate, and it takes roughly 10ms to get the magnetometer data. there could be a latency time of 10ms max that would decrease the performance of the IMU filter (like Kalman), we are supposed to feed this kind of algos with synchronized inputs. That could lead to issues at higher rates like the one you are using. I haven t asked invensense since they never reply!

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-113399446 . https://github.com/notifications/beacon/AGY1qqrb3GPATF8gTQ4FFVaXWk9nwMmpks5 oU7W6gaJpZM4CEl0o.gif

floflofloflo commented 9 years ago

Hi Kris, got some tests measurements over the week end, found the AK magnetometer a bit less accurate than honeywell and freescale, the output seems more noisy (I use a 2.5V LDO regulator as VCC supply with high noise rejection and very good CAP filtering). I recorded the magnetometer output in the MCU flash then made a clear log on MATLAB, the steady state seems containing more noise. I'll carry on with more experiments this week.

kriswiner commented 9 years ago

I'd like to see the comparison. Please PM me at onehorse@earthlink.net.

floflofloflo commented 9 years ago

Hi Kris, just sent

wiesener commented 8 years ago

Hi, i've got the board from http://www.drotek.fr/shop/en/home/421-mpu9250-gyro-accelerometer-magnetometer.html In the schematic you can see, that the pin 1 and VCC are connected. But we are still facing sporadically the issue, that the Magnetometer does not show up either in bypass or normal mode. And it gets worst if we connect to MPU in parrallel at the same I2C port. Then both IMU show up with 0x69 and 0x68 but one of them sometimes gets no Magnetometer values. Could it be something regarding the power supply.

kriswiner commented 8 years ago

Yes, this is likely a problem of the mag address, which is 0x0C for both your IMUs. So the solution is to place in bypass mode the one you want to talk to and take the other out of bypass mode, then switch when you want to talk to the other magnetometer. Alternatively you could use a TCA9548A I2C multiplexer, but doing it in software is probably easier.

-----Original Message----- From: wiesener [mailto:notifications@github.com] Sent: September 25, 2015 3:02 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi, i've git the board from http://www.drotek.fr/shop/en/home/421-mpu9250-gyro-accelerometer-magnetomete r.html In the schematic you can see, that the pin 1 and VCC are connected. But we are still facing sporadically the issue, that the Magnetometer does not show up either in bypass or normal mode. And it gets worst if we connect to MPU in parrallel at the same I2C port. Then both IMU show up with 0x69 and 0x68 but one of them sometimes gets no Magnetometer values. Could it be something regarding the power supply.

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143177672 . https://github.com/notifications/beacon/AGY1qn2Grs52rYOL3qkOQZxy8Hr0uw4-ks5 o1RL7gaJpZM4CEl0o.gif

wiesener commented 8 years ago

Hi kris,

but the issue is not, that I cannot get proper data. It is just sometimes only one of the Magnetometer is responding after a power down and up. Everything is working just fine: The code for initialization ist the following:

    //{0x80, MPUREG_PWR_MGMT_1},     // Reset Device
    {0x01, MPUREG_PWR_MGMT_1},     // Clock Source
    {0x00, MPUREG_PWR_MGMT_2},     // Enable Acc & Gyro
    {low_pass_filter, MPUREG_CONFIG},         // Use DLPF set Gyroscope bandwidth 184Hz, temperature bandwidth 188Hz
    {0x18, MPUREG_GYRO_CONFIG},    // +-2000dps
    {0x08, MPUREG_ACCEL_CONFIG},   // +-4G
    {0x09, MPUREG_ACCEL_CONFIG_2}, // Set Acc Data Rates, Enable Acc LPF , Bandwidth 184Hz
    {0x30, MPUREG_INT_PIN_CFG},    //
    //{0x40, MPUREG_I2C_MST_CTRL},   // I2C Speed 348 kHz
    //{0x20, MPUREG_USER_CTRL},      // Enable AUX
    {0x20, MPUREG_USER_CTRL},       // I2C Master mode
    {0x0D, MPUREG_I2C_MST_CTRL}, //  I2C configuration multi-master  IIC 400KHz

    {AK8963_I2C_ADDR, MPUREG_I2C_SLV0_ADDR},  //Set the I2C slave addres of AK8963 and set for write.
    //{0x09, MPUREG_I2C_SLV4_CTRL},
    //{0x81, MPUREG_I2C_MST_DELAY_CTRL}, //Enable I2C delay

    {AK8963_CNTL2, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer
    {0x01, MPUREG_I2C_SLV0_DO}, // Reset AK8963
    {0x81, MPUREG_I2C_SLV0_CTRL},  //Enable I2C and set 1 byte

    {AK8963_CNTL1, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer
    {0x12, MPUREG_I2C_SLV0_DO}, // Register value to continuous measurement in 16bit
    {0x81, MPUREG_I2C_SLV0_CTRL}  //Enable I2C and set 1 byte

And the reading of the Magnetometer data is done using the following:

//Send I2C command at first
i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_ADDR,AK8963_I2C_ADDR|READ_FLAG); //Set the I2C slave addres of AK8963 and set for read.
i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_REG, AK8963_HXL); //I2C slave 0 register address from where to begin data transfer
i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_CTRL, 0x87); //Read 7 bytes from the magnetometer
//must start your read from AK8963A register 0x03 and read seven bytes so that upon read of ST2 register 0x09 the
//AK8963A will unlatch the data registers for the next measurement.

usleep(1000);
i2c_smbus_read_block_data(MPUREG_ACCEL_XOUT_H, 21, response);

Am I doing something wrong?

Kind regards, Constantin

floflofloflo commented 8 years ago

Hi,

Was away, maybe I’ve been missing something, have just read quickly your Email. As I remember pin 1 has to be tied up to VCC (wrong info in the datasheet as I remember, it shows the pin floating on one hand and tied up to Vcc on the other hand in the app note). The pin 1 is the reset of the AK chip, prob it doesn’t start properly because of that.

Anyway, I found the AK not very accurate, if you need something stable in the 1 degree resolution, I guess you’ll have to move to Honeywell or freescale. I am using my own board, 4 layers ultra low noise, can t get any good accuracy and I am 99% sure it comes from the AK chip.

B.Rgds

florent

From: wiesener [mailto:notifications@github.com] Sent: Monday, September 28, 2015 10:27 PM To: kriswiner/MPU-9250 MPU-9250@noreply.github.com Cc: floflofloflo fantasiopop@gmail.com Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi kris,

but the issue is not, that I cannot get proper data. It is just sometimes only one of the Magnetometer is responding after a power down and up. Everything is working just fine: The code for initialization ist the following:

//{0x80, MPUREG_PWR_MGMT_1},     // Reset Device
{0x01, MPUREG_PWR_MGMT_1},     // Clock Source
{0x00, MPUREG_PWR_MGMT_2},     // Enable Acc & Gyro
{low_pass_filter, MPUREG_CONFIG},         // Use DLPF set Gyroscope bandwidth 184Hz, temperature bandwidth 188Hz
{0x18, MPUREG_GYRO_CONFIG},    // +-2000dps
{0x08, MPUREG_ACCEL_CONFIG},   // +-4G
{0x09, MPUREG_ACCEL_CONFIG_2}, // Set Acc Data Rates, Enable Acc LPF , Bandwidth 184Hz
{0x30, MPUREG_INT_PIN_CFG},    //
//{0x40, MPUREG_I2C_MST_CTRL},   // I2C Speed 348 kHz
//{0x20, MPUREG_USER_CTRL},      // Enable AUX
{0x20, MPUREG_USER_CTRL},       // I2C Master mode
{0x0D, MPUREG_I2C_MST_CTRL}, //  I2C configuration multi-master  IIC 400KHz

{AK8963_I2C_ADDR, MPUREG_I2C_SLV0_ADDR},  //Set the I2C slave addres of AK8963 and set for write.
//{0x09, MPUREG_I2C_SLV4_CTRL},
//{0x81, MPUREG_I2C_MST_DELAY_CTRL}, //Enable I2C delay

{AK8963_CNTL2, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer
{0x01, MPUREG_I2C_SLV0_DO}, // Reset AK8963
{0x81, MPUREG_I2C_SLV0_CTRL},  //Enable I2C and set 1 byte

{AK8963_CNTL1, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer
{0x12, MPUREG_I2C_SLV0_DO}, // Register value to continuous measurement in 16bit
{0x81, MPUREG_I2C_SLV0_CTRL}  //Enable I2C and set 1 byte

And the reading of the Magnetometer data is done using the following:

//Send I2C command at first i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_ADDR,AK8963_I2C_ADDR|READ_FLAG); //Set the I2C slave addres of AK8963 and set for read. i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_REG, AK8963_HXL); //I2C slave 0 register address from where to begin data transfer i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_CTRL, 0x87); //Read 7 bytes from the magnetometer //must start your read from AK8963A register 0x03 and read seven bytes so that upon read of ST2 register 0x09 the //AK8963A will unlatch the data registers for the next measurement.

usleep(1000); i2c_smbus_read_block_data(MPUREG_ACCEL_XOUT_H, 21, response);

Am I doing something wrong?

Kind regards, Constantin

— Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143759006 .

kriswiner commented 8 years ago

Hi Constantin.

I don't do it this way but it should work. I usually just set the MPU9250 to bypass mode. One problem in using the MPU9250 master bus is there can be traffic jams and latency. This might be what you are seeing.

I suppose you have defines the second AK8963 as slave 1? It's an issue of reliable readings from two AK8963, yes?

Kris

-----Original Message----- From: wiesener [mailto:notifications@github.com] Sent: September 28, 2015 7:27 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi kris,

but the issue is not, that I cannot get proper data. It is just sometimes only one of the Magnetometer is responding after a power down and up. Everything is working just fine: The code for initialization ist the following:

//{0x80, MPUREG_PWR_MGMT_1},     // Reset Device
{0x01, MPUREG_PWR_MGMT_1},     // Clock Source
{0x00, MPUREG_PWR_MGMT_2},     // Enable Acc & Gyro
{low_pass_filter, MPUREG_CONFIG},         // Use DLPF set Gyroscope

bandwidth 184Hz, temperature bandwidth 188Hz {0x18, MPUREG_GYRO_CONFIG}, // +-2000dps {0x08, MPUREG_ACCEL_CONFIG}, // +-4G {0x09, MPUREG_ACCEL_CONFIG_2}, // Set Acc Data Rates, Enable Acc LPF , Bandwidth 184Hz {0x30, MPUREG_INT_PIN_CFG}, // //{0x40, MPUREG_I2C_MST_CTRL}, // I2C Speed 348 kHz //{0x20, MPUREG_USER_CTRL}, // Enable AUX {0x20, MPUREG_USER_CTRL}, // I2C Master mode {0x0D, MPUREG_I2C_MST_CTRL}, // I2C configuration multi-master IIC 400KHz

{AK8963_I2C_ADDR, MPUREG_I2C_SLV0_ADDR},  //Set the I2C slave addres of

AK8963 and set for write. //{0x09, MPUREG_I2C_SLV4_CTRL}, //{0x81, MPUREG_I2C_MST_DELAY_CTRL}, //Enable I2C delay

{AK8963_CNTL2, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from

where to begin data transfer {0x01, MPUREG_I2C_SLV0_DO}, // Reset AK8963 {0x81, MPUREG_I2C_SLV0_CTRL}, //Enable I2C and set 1 byte

{AK8963_CNTL1, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from

where to begin data transfer {0x12, MPUREG_I2C_SLV0_DO}, // Register value to continuous measurement in 16bit {0x81, MPUREG_I2C_SLV0_CTRL} //Enable I2C and set 1 byte

And the reading of the Magnetometer data is done using the following:

//Send I2C command at first i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_ADDR,AK8963_I2C_ADDR|READ_FLAG); //Set the I2C slave addres of AK8963 and set for read. i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_REG, AK8963_HXL); //I2C slave 0 register address from where to begin data transfer i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_CTRL, 0x87); //Read 7 bytes from the magnetometer //must start your read from AK8963A register 0x03 and read seven bytes so that upon read of ST2 register 0x09 the //AK8963A will unlatch the data registers for the next measurement.

usleep(1000); i2c_smbus_read_block_data(MPUREG_ACCEL_XOUT_H, 21, response);

Am I doing something wrong?

Kind regards, Constantin

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143759006 . https://github.com/notifications/beacon/AGY1qjgYAjmsmScuaB90XXik7WotsVgjks5 o2UWngaJpZM4CEl0o.gif

kriswiner commented 8 years ago

Possibly, I am testing the AK8963 against the LIS3MDL and HMC5883L now. I'll publish the results soon. So far the HMC5883 looks pretty good.

Kris

-----Original Message----- From: floflofloflo [mailto:notifications@github.com] Sent: September 28, 2015 8:08 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi,

Was away, maybe I've been missing something, have just read quickly your Email. As I remember pin 1 has to be tied up to VCC (wrong info in the datasheet as I remember, it shows the pin floating on one hand and tied up to Vcc on the other hand in the app note). The pin 1 is the reset of the AK chip, prob it doesn't start properly because of that.

Anyway, I found the AK not very accurate, if you need something stable in the 1 degree resolution, I guess you'll have to move to Honeywell or freescale. I am using my own board, 4 layers ultra low noise, can t get any good accuracy and I am 99% sure it comes from the AK chip.

B.Rgds

florent

From: wiesener [mailto:notifications@github.com] Sent: Monday, September 28, 2015 10:27 PM To: kriswiner/MPU-9250 MPU-9250@noreply.github.com Cc: floflofloflo fantasiopop@gmail.com Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi kris,

but the issue is not, that I cannot get proper data. It is just sometimes only one of the Magnetometer is responding after a power down and up. Everything is working just fine: The code for initialization ist the following:

//{0x80, MPUREG_PWR_MGMT_1}, // Reset Device {0x01, MPUREG_PWR_MGMT_1}, // Clock Source {0x00, MPUREG_PWR_MGMT_2}, // Enable Acc & Gyro {low_pass_filter, MPUREG_CONFIG}, // Use DLPF set Gyroscope bandwidth 184Hz, temperature bandwidth 188Hz {0x18, MPUREG_GYRO_CONFIG}, // +-2000dps {0x08, MPUREG_ACCEL_CONFIG}, // +-4G {0x09, MPUREG_ACCEL_CONFIG_2}, // Set Acc Data Rates, Enable Acc LPF , Bandwidth 184Hz {0x30, MPUREG_INT_PIN_CFG}, // //{0x40, MPUREG_I2C_MST_CTRL}, // I2C Speed 348 kHz //{0x20, MPUREG_USER_CTRL}, // Enable AUX {0x20, MPUREG_USER_CTRL}, // I2C Master mode {0x0D, MPUREG_I2C_MST_CTRL}, // I2C configuration multi-master IIC 400KHz

{AK8963_I2C_ADDR, MPUREG_I2C_SLV0_ADDR}, //Set the I2C slave addres of AK8963 and set for write. //{0x09, MPUREG_I2C_SLV4_CTRL}, //{0x81, MPUREG_I2C_MST_DELAY_CTRL}, //Enable I2C delay

{AK8963_CNTL2, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer {0x01, MPUREG_I2C_SLV0_DO}, // Reset AK8963 {0x81, MPUREG_I2C_SLV0_CTRL}, //Enable I2C and set 1 byte

{AK8963_CNTL1, MPUREG_I2C_SLV0_REG}, //I2C slave 0 register address from where to begin data transfer {0x12, MPUREG_I2C_SLV0_DO}, // Register value to continuous measurement in 16bit {0x81, MPUREG_I2C_SLV0_CTRL} //Enable I2C and set 1 byte

And the reading of the Magnetometer data is done using the following:

//Send I2C command at first i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_ADDR,AK8963_I2C_ADDR|READ_FLAG); //Set the I2C slave addres of AK8963 and set for read. i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_REG, AK8963_HXL); //I2C slave 0 register address from where to begin data transfer i2c_smbus_write_byte_data(MPUREG_I2C_SLV0_CTRL, 0x87); //Read 7 bytes from the magnetometer //must start your read from AK8963A register 0x03 and read seven bytes so that upon read of ST2 register 0x09 the //AK8963A will unlatch the data registers for the next measurement.

usleep(1000); i2c_smbus_read_block_data(MPUREG_ACCEL_XOUT_H, 21, response);

Am I doing something wrong?

Kind regards, Constantin

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143759006 .

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143769788 . https://github.com/notifications/beacon/AGY1qr1iMfqHnFoAHq99BYowj0d-nT-iks5 o2U9QgaJpZM4CEl0o.gif

floflofloflo commented 8 years ago

Hi Kris, While the HMC5883L is already providing the best accuracy among all the sensors I ve been using so far, you may move to the latest HMC5893. Florent

kriswiner commented 8 years ago

Actually looks pretty reasonable, one or two dollars a piece in small quantities. It's a 3 mm x 3 mm package so I will have to design a new mag test board for it. Or maybe I will just design an EM7180+MPU6500+HMC5983 board and use it, assuming it will test well! I'll let you know what I find...

Kris

-----Original Message----- From: floflofloflo [mailto:notifications@github.com] Sent: September 28, 2015 6:15 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi Kris, While the HMC5883L is already providing the best accuracy among all the sensors I ve been using so far, you may move to the latest HMC5893. Florent

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-143916447 . https://github.com/notifications/beacon/AGY1qlXhyn3ZEtGhf1HptmXvs3j0ZLJzks5 o2d2EgaJpZM4CEl0o.gif

Anadimiy commented 8 years ago

Hello! I have a problem with my mpu9250. I am using RTIMULib-Arduino to fuse sensors data and calculate quaternions. It works well, but only on pitch and roll. (yaw is very unstable). I found that magnetometer is guilty. Data ranges on every axis are catastrophically shifted. But this is only half of problem. This can be evaluated by calibration. Another problem is that it detects large magnetic field oriented in vertical axis. This field is bigger than horizontal ones. (maybe this is a kind of flat anomaly, but situation is the same in two different flats far away from each other). This makes magnetometer's work impossible. When i put a weak magnet on 10cm near to sensor, yaw works fine. How can i eliminate this problem? Thanks!

kriswiner commented 8 years ago

I am not sure. Of course, if it is a magnetometer bias problem, then calibration can take care of it as you say. If there is truly a large magnetic field in your vicinity, then you could calibrate out this as well, but if it is variable then I am afraid there might be nothing you could do. What is the magnetic field supposed to be in your area? For me here, the expected components are x = 200, y = 50, and z = 400 mG, and after bias calibration this is more or less what I read depending on where the x and y -axes are pointed. Is it possible the field in your area is very different from these values? Do you have large-current carrying wires nearby? Do you have another (non-MPU9250) mag to check with?

Kris

-----Original Message----- From: Anadimiy [mailto:notifications@github.com] Sent: October 22, 2015 12:37 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hello! I have a problem with my mpu9250. I am using RTIMULib-Arduino to fuse sensors data and calculate quaternions. It works well, but only on pitch and roll. (yaw is very unstable). I found that magnetometer is guilty. Data ranges on every axis are catastrophically shifted. But this is only half of problem. This can be evaluated by calibration. Another problem is that it detects large magnetic field oriented in vertical axis. This field is bigger than horizontal ones. (maybe this is a kind of flat anomaly, but situation is the same in two different flats far away from each other). This makes magnetometer's work impossible. When i put a weak magnet on 10cm near to sensor, yaw works fine. How can i eliminate this problem? Thanks!

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-150332974 . https://github.com/notifications/beacon/AGY1qoyuqOYa0uGuc3LKD7U524dnmXymks5 o-TJkgaJpZM4CEl0o.gif

yk9 commented 8 years ago

Hi Kris, i took the code for mpu6050/9250 and also followed the AN of selftest and bias correction, translated it to microchip pic24. first of all i never pass the self test stage . the values i get never pass the criteria . i cant understand why . second , after reading the offset values from the memory and doing the math formula (with the average vlaues i got) i place the the chip on the table facing up and still i dont get the balanced results for the gyro (0,0,0) and the Acc(0,0,+1G) .i add values manualy (i add what needed to get to 0)to stable the reading. is that ok ??? after running the reading through the - MahonyAHRSupdate(gx, gy,gz,ax,ay,az,mx,my,mz) , i still get an endless drift . how can i fix it ? on a steady state, when the chip is on the table facing up and Y facing north . what reading should i get from the Manometer ?

after many weeks of development(that hasn't been easy) i feel im at the last stages , i would really appreciate the help. thank you

kriswiner commented 8 years ago

I suppose it's possible there is some integer type problem with your pic. Can't you buy a teensy for $17 and verify your setup is working?

Subtracting the bias values manually in the main loop is fine. I still do this for the accelerometer data. Flat and still on a table you should read 0, 0, 0 for the gyro and 0, 0, 1 for the accel to within 1% or better.

The mag values depend on your location. For me near San Francisco, I expect 150, 50, and 400 for x, y, and z.

Are you sure you are passing the sensor data correctly to the Mahony filter? In the right order and with gyro in radians/s?

The github code works for me with any MPU9250 on either a Teensy or an Arduino Pro Mini. I don't know why it wouldn't work on a pic.

Kris

-----Original Message----- From: yk9 [mailto:notifications@github.com] Sent: November 22, 2015 4:50 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Hi Kris, i took the code for mpu6050/9250 and also followed the AN of selftest and bias correction, translated it to microchip pic24. first of all i never pass the self test stage . the values i get never pass the criteria . i cant understand why . second , after reading the offset values from the memory and doing the math formula (with the average vlaues i got) i place the the chip on the table facing up and still i dont get the balanced results for the gyro (0,0,0) and the Acc(0,0,+1G) .i add values manualy (i add what needed to get to 0)to stable the reading. is that ok ??? after running the reading through the - MahonyAHRSupdate(gx, gy,gz,ax,ay,az,mx,my,mz) , i still get an endless drift . how can i fix it ? on a steady state, when the chip is on the table facing up and Y facing north . what reading should i get from the Manometer ?

after many weeks of development(that hasn't been easy) i feel im at the last stages , i would really appreciate the help. thank you

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-158757956 . https://github.com/notifications/beacon/AGY1qs36pFbRuSK1YZzaZaBls7yZeDIdks5 pIbGTgaJpZM4CEl0o.gif

kriswiner commented 8 years ago

Hi Yuval,

The self test only tells you how much the sensitivity has changed from the factory. It should read a percent or so change due to the stresses of being soldered to the pcb. It is not used in the bias calibration. Once is enough. It is FYI only.

I don't use the accel bias register because the last (LS) bit is a temperature compensation bit and it has to be handles in a special way. I found unsatisfactory results when trying to use the accel bias register. The gyro bias register works fine and I do use it. I would recommend manually (in the main loop) subtracting the scaled accel bias from the scaled data. This works well for me, where I usually can zero the accel at rest to ~25 mg or less.

What are you using for a microcontroller and what are you using for your MPU9250 breakout board? They are not all the same.

You can spew scaled accelerometer data to the serial monitor at 2 - 4 Hz and average the output yourself to see what the biases ought to be, and to see and measure what the jitter in the accel measurement is at rest. This will tell you about the quality of your sensor.

Kris

-----Original Message----- From: yk9 [mailto:notifications@github.com] Sent: November 23, 2015 4:06 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

hi kris , thanks for the response. i decided to do it step by step. first get the Acc reading to be stable at 0.00, 0.00 , 1.00 . is the self test related to the bias correction ? do i need to run it after the bias correction? im using the lowest sensing configuration : +-2G , +-250dps. in the bias function , do i need to divide the accel_bias by 8 ? accel_bias_reg[0] = accel_bias_reg[0] - (accel_bias[0]/8) i ran the program several time and i get changing Acc Bias . ax is stable 0.02 but ay is changing from -0.37 to +0.26

az is changing from -0.92 to -0.65. why am i getting unstable results ? i see in the program the you read accel_bias_reg[i] but you never use it. why is that ?

yuval

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-158915909 . https://github.com/notifications/beacon/AGY1qhbL91FYma-uSlqROBP9rSh_g0fTks5 pIvjDgaJpZM4CEl0o.gif

kriswiner commented 8 years ago

The magnetometer calibration function sends these values to the main loop in the array magcal or magbias, I can't remember off the top of my head.

-----Original Message----- From: yk9 [mailto:notifications@github.com] Sent: November 23, 2015 12:20 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

hi kris , thanks for the advice . i went back to your code and found that im missing the initmpu9250(). after doing so the result are better . still not 1% . about the magnetometer, how can i find out the magnetic values i need to subtract ?

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-159052427 . https://github.com/notifications/beacon/AGY1qgzzP_XfBr6kGoXdnMDY-yPQN1hXks5 pI2xwgaJpZM4CEl0o.gif

kriswiner commented 8 years ago

That depends on your location. For me in San Francisco, I expect 150 mG, 50 mG, and 400 mG. The total magnitude should be about 0.5 G.

-----Original Message----- From: yk9 [mailto:notifications@github.com] Sent: November 23, 2015 12:38 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

ok. and what values should i expect from the mag at rest (Y facing north)?

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-159057409 . https://github.com/notifications/beacon/AGY1qkU8vh_u_SdkNh06rgu3TZ1y10X7ks5 pI3CsgaJpZM4CEl0o.gif

yk9 commented 8 years ago

that was what i was asking . how should i know what to expect ? depending on my location ? in you code the values read from the sensor are mG. are those values i need to place in the MahonyAHRSupdate?

kriswiner commented 8 years ago

You can look up the magnetic field in your location with a google search.

Yes, the magnetic fields go into the Mahony algorithm.

-----Original Message----- From: yk9 [mailto:notifications@github.com] Sent: November 23, 2015 12:59 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

that was what i was asking . how should i know what to expect ? depending on my location ? in you code the values read from the sensor are mG. are those values i need to place in the MahonyAHRSupdate?

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-159062295 . https://github.com/notifications/beacon/AGY1qt4AXzolrAvM2-ED9ZqQXbV3wsv5ks5 pI3WHgaJpZM4CEl0o.gif

yk9 commented 8 years ago

the sensitivity of the chip is - 176 ,178 and 167 magCalibration[0] = (float)(176 - 128)/256.0f + 1.0f; = 1.1875 working with 16bit resolution - mRes = 10_4219/32768.0 = 1.28 i think the magnitude around my area is 300 mG, 25 mG and 330 mG. mx = (float)magCount[0]_mRes_magCalibration[0] - magbias[0]; mx = (float)magCount[0]_1.28*1.1875 - 300; after adding that , the results im getting are mx= 279.45 my= 227.68 mz= -135.65

is that what im suppose to get ?

yk9 commented 8 years ago

hi kris , in your code you use the MahonyQuaternionUpdate algorithm. inside there is an integer float deltat = 0.0f; // integration interval for both filter schemes and in the algorithm it zero everything . q1 = q1 + (-q2 * gx - q3 * gy - q4 * gz) * (0.5f * deltat); q2 = pa + (q1 * gx + pb * gz - pc * gy) * (0.5f * deltat); q3 = pb + (q1 * gy - pa * gz + pc * gx) * (0.5f * deltat); q4 = pc + (q1 * gz + pa * gy - pb * gx) * (0.5f * deltat); so im getting pitch roll and yaw = 0 .

kriswiner commented 8 years ago

deltat should come from the main loop, it is an integration time.

kriswiner commented 8 years ago

I am not sure what this means:

"the sensitivity of the chip is - 176 ,178 and 167"

The AK8963 has factory sensitivities loaded into the fuse rom which are read during initialization. These are scale factors that, in addition to the conversion from raw counts to milliGauss must be applied. The sensitivities are typically ~1.1 - 1.2. So

Mx = xrawCounts * factorySensitivity * scaleFactor (Mx result in milliGauss)

where the scaleFactor is, as you say 1.28, and the factorySensitivity is 1.18 in your example,

then the bias should be removed so

Mx = Mx - mxBias(Mx result in milliGauss referenced to Mx =0)

Where does the 300 mag bias come from in your example?

If the orientation of the sensor is x = North, I would expect you would read Mx = +/- 300, My = +/- 25, and Mz = +/-300 milliGauss for a properly calibrated and scaled magnetometer sensor.

Kris

yk9 commented 8 years ago

hi kris . the sensitivity is ~1.1875. im getting good results . regarding the deltat . since im not running the same main , what value should i place instead ? or what kind of timer i could use ?

can you please explain what is the difference between the diffrent algorithm ? Mahony , magic and others ?

yuval

kriswiner commented 8 years ago

You have to calculate deltat; it is the time interval between Madgwick or Mahony function calls.

The difference between these algorithms is discussed and referenced here:

https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion

Kris

xianrecords2015 commented 8 years ago

I have the same issue as Richard and my fusion yaw is always oscillating around 80-89deg wherever I head my board.

With a beta of 3, it stays in that zone very quickly. With a beta of 0.1, it seems to start at the right angle and then drift slowly back to the 80-89 degree

I am using a NRF51 for processor.

Was there any resolution on that issue ?

Thank you

kriswiner commented 8 years ago

Have you calibrated the sensors? How?

-----Original Message----- From: xianrecords2015 [mailto:notifications@github.com] Sent: December 3, 2015 9:36 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

I have the same issue as Richard and my fusion yaw is always oscillating around 89deg wherever I head my board. I have tried with several beta form 0.04 to 3.0f and I always get the same thing.

Was there any resolution on that issue ?

Thank you

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-161881409 . https://github.com/notifications/beacon/AGY1qo7WXmtJ3ObeqBDz6iansiDABzEGks5 pMR3bgaJpZM4CEl0o.gif

xianrecords2015 commented 8 years ago

I have for the acc and gyr. The ACC and the Gyro are calibrated with a level flat.

I have not yet done the Mag but I am not experiencing any jitter on either the ACC, GYR or MAG.

I do believe that I have the axis set correctly (Mag has different axis as acc/gyr) and I am using the following units as inputs to the fusion algorithm: ACC: g GYR: rad/s MAG: uTesla

Even though the Mag is not fully calibrated, I do not believe I should not experience this type of behavior

Any hints on what might be going wrong ?

Thanks

From: Kris Winer notifications@github.com Reply-To: kriswiner/MPU-9250 <reply+00ba33f089fce614d86db43ef0f8ae00577d60366f8b599c92cf000000011278fd9c9 2a169ce02226578@reply.github.com> Date: Thursday, December 3, 2015 at 11:07 PM To: kriswiner/MPU-9250 MPU-9250@noreply.github.com Cc: Christian Joly christian.joly@gmail.com Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Have you calibrated the sensors? How?

-----Original Message----- From: xianrecords2015 [mailto:notifications@github.com] Sent: December 3, 2015 9:36 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

I have the same issue as Richard and my fusion yaw is always oscillating around 89deg wherever I head my board. I have tried with several beta form 0.04 to 3.0f and I always get the same thing.

Was there any resolution on that issue ?

Thank you

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-161881409 . https://github.com/notifications/beacon/AGY1qo7WXmtJ3ObeqBDz6iansiDABzEGks5 pMR3bgaJpZM4CEl0o.gif

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-161895279 .

kriswiner commented 8 years ago

Yes, you must calibrate the mag. See:

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

Kris

-----Original Message----- From: xianrecords2015 [mailto:notifications@github.com] Sent: December 4, 2015 9:10 AM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

I have for the acc and gyr. The ACC and the Gyro are calibrated with a level flat.

I have not yet done the Mag but I am not experiencing any jitter on either the ACC, GYR or MAG.

I do believe that I have the axis set correctly (Mag has different axis as acc/gyr) and I am using the following units as inputs to the fusion algorithm: ACC: g GYR: rad/s MAG: uTesla

Even though the Mag is not fully calibrated, I do not believe I should not experience this type of behavior�

Any hints on what might be going wrong ?

Thanks

From: Kris Winer notifications@github.com Reply-To: kriswiner/MPU-9250 <reply+00ba33f089fce614d86db43ef0f8ae00577d60366f8b599c92cf000000011278fd9c9 2a169ce02226578@reply.github.com> Date: Thursday, December 3, 2015 at 11:07 PM To: kriswiner/MPU-9250 MPU-9250@noreply.github.com Cc: Christian Joly christian.joly@gmail.com Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

Have you calibrated the sensors? How?

-----Original Message----- From: xianrecords2015 [mailto:notifications@github.com] Sent: December 3, 2015 9:36 PM To: kriswiner/MPU-9250 Cc: Kris Winer Subject: Re: [MPU-9250] Doesn't seem to be working (#2)

I have the same issue as Richard and my fusion yaw is always oscillating around 89deg wherever I head my board. I have tried with several beta form 0.04 to 3.0f and I always get the same thing.

Was there any resolution on that issue ?

Thank you

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-161881409 . https://github.com/notifications/beacon/AGY1qo7WXmtJ3ObeqBDz6iansiDABzEGks5 pMR3bgaJpZM4CEl0o.gif

� Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-161895279 .

� Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-162023962 . https://github.com/notifications/beacon/AGY1qpiB8T66GjjposQKECit3_jWGBaJks5 pMcBlgaJpZM4CEl0o.gif

JohnMcC1 commented 8 years ago

Trying to calibrate gyro bias the range is only int8_t -128 to 127 Statically I see 15 deg/sec in Y gyro and using offset = 125; accelgyro.setYGyroOffset(offset); Does not seem to affect the raw output? Do I need to just find the average for acc and gyro and subtract them in my application

kriswiner commented 8 years ago

Accel and gyro should be int16_t.

" Do I need to just find the average for acc and gyro and subtract them in my application"

Yes

-----Original Message----- From: JohnMcC1 [mailto:notifications@github.com] Sent: July 14, 2016 10:50 AM To: kriswiner/MPU-9250 Cc: Kris Winer; State change Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

Trying to calibrate gyro bias the range is only int8_t -128 to 127 Statically I see 15 deg/sec in Y gyro and using offset = 125; accelgyro.setYGyroOffset(offset); Does not seem to affect the raw output? Do I need to just find the average for acc and gyro and subtract them in my application

You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-232740407 , or mute the thread https://github.com/notifications/unsubscribe/AGY1qiV6s639kWR-S577r4GrShQFnq u3ks5qVnbggaJpZM4CEl0o . https://github.com/notifications/beacon/AGY1qk2glP924L6d6P7oI0RTHoDCS0jUks5 qVnbggaJpZM4CEl0o.gif

tim77777 commented 7 years ago

hi, do you have magnetic tilt compensation in your code?

kriswiner commented 7 years ago

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

tim77777 commented 7 years ago

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

tim77777 commented 7 years ago

Hi,

For the magnetometer I was using mx = (float)magne_xmResmagCalibration[0] - magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmResmagCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP-K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

tim77777 commented 7 years ago

I see. Well I guess it’s just a lack of knowledge on my behalf.

So, is the figure 8 supposed to be up and down like this rather than forward and backward like this

Magnetic Tilt compensation refers to the fact that when the e-compass is not held level the readings are off.

Can the accelerometer not give pitch and roll?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmResmagCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP-K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

Well you could start here:

https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion

and this might be of interest too:

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

"Can the accelerometer not give pitch and roll?"

Yes, same answer to "can I go from LA to New York on a unicycle?" Not necessarily the optimum for all applications though...

On Sat, Jan 14, 2017 at 7:11 PM, tim77777 notifications@github.com wrote:

I see. Well I guess it’s just a lack of knowledge on my behalf.

So, is the figure 8 supposed to be up and down like this rather than forward and backward like this

Magnetic Tilt compensation refers to the fact that when the e-compass is not held level the readings are off.

Can the accelerometer not give pitch and roll?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670441, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnlgSGOSqbREvbzpy6LsjtOgs0aAks5rSY56gaJpZM4CEl0o .

tim77777 commented 7 years ago

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmResmagCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP-K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

The axes are not aligned for the MPU9250. Use a NED scheme.

On Sat, Jan 14, 2017 at 7:20 PM, tim77777 notifications@github.com wrote:

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670709, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qi92tasrcHBYZvowbTp63hbOvNv0ks5rSZB0gaJpZM4CEl0o .

tim77777 commented 7 years ago

Ok, well thanks for all that. Bit beyond me I’m afraid.

But I do understand what you mean by “if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense.”

But I cannot get it to work any other way than by spinning in a circle to calibrate it. How exactly is the figure eight supposed to go? I mean which direction or directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:29 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

The axes are not aligned for the MPU9250. Use a NED scheme.

On Sat, Jan 14, 2017 at 7:20 PM, tim77777 notifications@github.com wrote:

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670709, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qi92tasrcHBYZvowbTp63hbOvNv0ks5rSZB0gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670993 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIaKNj5idek2pCRIPt0TtwLt6qV8Uks5rSZJ-gaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

I see you did not read the material at the link.

You have to sample the entire 3D response surface in order to properly recenter it on the origin and respherize it.

On Sat, Jan 14, 2017 at 7:41 PM, tim77777 notifications@github.com wrote:

Ok, well thanks for all that. Bit beyond me I’m afraid.

But I do understand what you mean by “if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense.”

But I cannot get it to work any other way than by spinning in a circle to calibrate it. How exactly is the figure eight supposed to go? I mean which direction or directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:29 PM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

The axes are not aligned for the MPU9250. Use a NED scheme.

On Sat, Jan 14, 2017 at 7:20 PM, tim77777 notifications@github.com wrote:

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670709, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qi92tasrcHBYZvowbTp63hbOvNv0ks5rSZB0gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670993> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIaKNj5idek2pCRIPt0TtwLt6qV8Uks5rSZJ-gaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671412, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhoKDPhWyFXdkLMy4jH92s-0B7Glks5rSZWEgaJpZM4CEl0o .

tim77777 commented 7 years ago

Yes I read it, and I have read it many times before also. But I don’t get the figure 8. Do you move it in a figure 8 in all directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:45 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I see you did not read the material at the link.

You have to sample the entire 3D response surface in order to properly recenter it on the origin and respherize it.

On Sat, Jan 14, 2017 at 7:41 PM, tim77777 notifications@github.com wrote:

Ok, well thanks for all that. Bit beyond me I’m afraid.

But I do understand what you mean by “if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense.”

But I cannot get it to work any other way than by spinning in a circle to calibrate it. How exactly is the figure eight supposed to go? I mean which direction or directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:29 PM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

The axes are not aligned for the MPU9250. Use a NED scheme.

On Sat, Jan 14, 2017 at 7:20 PM, tim77777 notifications@github.com wrote:

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 notifications@github.com wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272668107 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670709, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qi92tasrcHBYZvowbTp63hbOvNv0ks5rSZB0gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670993> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIaKNj5idek2pCRIPt0TtwLt6qV8Uks5rSZJ-gaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671412, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhoKDPhWyFXdkLMy4jH92s-0B7Glks5rSZWEgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671510 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIXaKoSGY2AHZIjd--9dtM51inxgoks5rSZZEgaJpZM4CEl0o .Description: Image removed by sender.

kriswiner commented 7 years ago

The mag response surface is 3D. Move it any way you want as long as you sample all of the quasi-spherical shape of the 3D response surface for the best accuracy.

OK, dumb version:

Imaging the response surface is a flabby beachball and your mag is inside of it. Your job is to move it limited at the origin such that the imaginary vector perpendicular (up or down vector) to the top of the mag sensor sweeps out as much of the inside surface of the beach ball as you can in the time alloted for the calibration. Move the mag such that the imaginary vector sweeps all around, in all possible directions, don't leave anything out.

On Sat, Jan 14, 2017 at 7:47 PM, tim77777 notifications@github.com wrote:

Yes I read it, and I have read it many times before also. But I don’t get the figure 8. Do you move it in a figure 8 in all directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:45 PM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I see you did not read the material at the link.

You have to sample the entire 3D response surface in order to properly recenter it on the origin and respherize it.

On Sat, Jan 14, 2017 at 7:41 PM, tim77777 notifications@github.com wrote:

Ok, well thanks for all that. Bit beyond me I’m afraid.

But I do understand what you mean by “if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense.”

But I cannot get it to work any other way than by spinning in a circle to calibrate it. How exactly is the figure eight supposed to go? I mean which direction or directions?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:29 PM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

The axes are not aligned for the MPU9250. Use a NED scheme.

On Sat, Jan 14, 2017 at 7:20 PM, tim77777 notifications@github.com wrote:

Hi,

Would you be able to help me out with the formula for magnetic e-compass tilt compensation. Assuming that the magnetometer and accelerometer’s axes are aligned ( as with the LSM303D device), the formula is -

Compensated_x = mx cos(pitch) + mz sin(pitch);

Compensated_y = mx sin(roll) sin(pitch) + my cos(roll) - mz sin(roll) * cos(pitch);

However, being that the axes of the magnetometer in the MPU9250 are not aligned with the accelerometer, how would the formula change.

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 2:03 PM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

I don't understand what you are doing here, but if you calibrate the magnetometer only in a plane it is not surprising to me that when you move out of the plane you get nonsense. There is nothing wrong with the datasheet.

I am using either Madgwick or Mahony open-source sensor fusion which with proper calibration can provide absolute 3D orientation estimation using MPU950 data with pitch and roll accurate to a degree or so and heading accurate to 4 degrees or so.

If what you are attempting can do the same or better it might be worth figuring out where it is going wrong. If not, I would switch to something that makes more sense.

I have no idea what you mean by tilt compensation. It looks like you are just depending on the accelerometer for pitch and roll. Why, I cannot understand.

On Sat, Jan 14, 2017 at 6:07 PM, tim77777 notifications@github.com wrote:

Hi,

For the magnetometer I was using mx = (float)magne_xmRes magCalibration[0]

magBias[0]; I rotate the device in a circle. Figure 8 does not work, so I rotate it on a spinning seat. I can then read 0 – 360 degrees in a circle. I am including hard iron offsets, but not soft iron offsets. I am not factoring in magnetic declination because exact north is not relevant to this application, rather I simply need 0 – 360 degrees around a circle. To save time I am now using pre-calculated offsets. E.g. mx = (float)magne_x 1.28785 1.218 - 238;

For the pitch and roll angles I am not using quaternions or using a filter combining the gyro and accelerometer, but rather I am just using the raw accelerometer values

pitch = atan(-accele_x / sqrt(accele_y accele_y + accele_z accele_z));

roll = atan(accele_y / sqrt(accele_x accele_x + accele_z accele_z));

I am not doing any calibration for the accelerometer, but the readings are close to 0 – 2048 from flat to a right angle.

and that’s about it. The pitch and roll are in radians and seem to be about correct reading from 0 – 1.57 when the device is raised from flat to a right angle.

I am having to negate the X axis acceleration which seems wrong compared to the datasheet, but produces the correct positive values when rotating anti-clockwise around the accelerometer axes.

Why that is, is a mystery to me. I mean my read acceleration values are the opposite polarity when compared to the data sheet. Should be positive when rotating anti-clockwise, but my program shows it as negative. I wonder if the data sheet is wrong?

Anyway so the bottom line is that my compensated heading is way off and the values change significantly when tilted.

Have you implemented magnetic tilt compensation for the MPU9250?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Sunday, January 15, 2017 3:43 AM

To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

How do you calibrate your sensors?

On Sat, Jan 14, 2017 at 3:16 AM, tim77777 notifications@github.com wrote:

Hi,

I am using a MPU9250 with a microchip controller and although I have most things working I have been unable to get magnetic e-compass tilt compensation to work. I have been looking at various code examples. However, I cannot find any code specifically for the MPU9250 that implements tilt compensation. And with the magnetometer and accelerometer of the 9250 having their X & Y axes exchanged, and the Z axis having its polarity exchanged, any code out there, such as for the HMC5883L, does not exactly match. Although I should be able to change the code to suit the axes and polarity, I have been unable to make it work.

Most examples use something like the following code for tilt compensation

Compensated_x = mxcos(pitch) + mysin(roll)sin(pitch) + mzcos(roll)*sin(pitch);

Compensated_ y = mycos(roll) - mzsin(roll);

compensated_heading = atan2( (double) Compensated_x, (double) Compensated_y ) * 57.2958;

if(compensated_heading < 0) { compensated_heading += 360;}

if(compensated_heading > 360){ compensated_heading -= 360;}

I thought I could simply swap the mx & my about, and negate mz, but it does not seem to be that simple.

I have derived mx, my & mz from your code

mx = (float)magne_xmResmagCalibration[0] - magBias[0];

my = (float)magne_ymResmagCalibration[1] - magBias[1];

mz = (float)magne_zmResmagCalibration[2] - magBias[2];

and when the device is lying flat the heading is correct. But when tilted it is way off. I have tried every which way of changing this code around to try and match the axes and polarity of the magnetometer versus the accelerometer, but without success. I am beginning to think that perhaps my pitch and roll are incorrect, or something else. And so I am wondering if the MPU9250 code of yours for the Arduino implements e-compass tilt compensation, so that I can compare code. I can’t see that it does, but I am wondering.

Regards

Tim

I have been looking at your code

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, January 14, 2017 10:54 AM To: kriswiner/MPU-9250 Cc: tim77777; Comment Subject: Re: [kriswiner/MPU-9250] Doesn't seem to be working (#2)

What's that?

On Fri, Jan 13, 2017 at 3:46 PM, tim77777 < notifications@github.com> wrote:

hi, do you have magnetic tilt compensation in your code?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272578372 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qlRAD2qGj8AvNp2W0o2uDmfW3UsWks5rSAzbgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272579341> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIVF-wBJhssLWhyLxbvNBE8H6iiJGks5rSA6GgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272617759 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qoKFXNBYrZRJT79DZxUafkr7LNYZks5rSK5_gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272635726> , or mute the thread https://github.com/notifications/unsubscribe- auth/ AXcUIeN8tvlgqqKJ3IQRi1cH1Wkn6cfdks5rSPsBgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2# issuecomment-272668107 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnEfP- K2dwFy8iCs23cI1H-HvtPMks5rSX9LgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670111> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYs_lqAUefBXJx-FXmFEUmqkxT8Fks5rSYxkgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670709 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qi92tasrcHBYZvowbTp63hbOvNv0ks5rSZB0gaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272670993> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIaKNj5idek2pCRIPt0TtwLt6qV8Uks5rSZJ-gaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671412, or mute the thread https://github.com/notifications/unsubscribe-auth/ AGY1qhoKDPhWyFXdkLMy4jH92s-0B7Glks5rSZWEgaJpZM4CEl0o .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671510> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIXaKoSGY2AHZIjd--9dtM51inxgoks5rSZZEgaJpZM4CEl0o .Description: Image removed by sender.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-9250/issues/2#issuecomment-272671585, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qh0DCBv1HzKTjuO82EQcg-hSd5h8ks5rSZbAgaJpZM4CEl0o .

kriswiner / MPU9250

Doesn't seem to be working #2