kriswiner / EM7180_SENtral_sensor_hub

(Affordable) Ultimate Sensor Fusion Solution
https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/
96 stars 37 forks source link

esp32 VS Teensy Drift and errors #52

Open carbonadam opened 5 years ago

carbonadam commented 5 years ago

Anyone who has used the ESP32 along with the sensor fusion would have had some issues with I2C and im expecting that my problem is going to be something related.

Apparently since Wire 1.0.1 Wire for arduino should be stable for esp32. I am still however not able to run the sketches from the examples and get good results. It starts stable enough most of the time but quite quickly it will just start to drift along YAW constantly trying to rest to a about 325 degrees.

IF I take the same sensor fusion board and run the same sketch on the Teensy 3.6 and no errors and no drift ever.

So same USF board but different results on the esp32

My Wire library I just got from the developer branch today and is up to date and I can see on the oscilloscope that the I2C looks good and very little noise(less than the teensy). I've tried this on more than one esp32 wroom module both one on a board I made and an official board that Espressif sent me.

I verified that the intpin is correct

This is the sketch we use EM7180_MPU9250_BMP280

Any Ideas whats going on Kris can you possibly help to reproduce this?

seems to all start ok

EM7180 ROM Version: 0xE69 Should be: 0xE609 EM7180 RAM Version: 0x17435 EM7180 ProductID: 0x80 Should be: 0x80 EM7180 RevisionID: 0x2 Should be: 0x02 A barometer is installed A temperature sensor is installed EEPROM detected on the sensor bus! EEPROM uploaded config file! EEPROM upload successful! Beginning Parameter Adjustments Magnetometer Default Full Scale Range: +/-1000uT Accelerometer Default Full Scale Range: +/-8g Gyroscope Default Full Scale Range: +/-2000dps Magnetometer New Full Scale Range: +/-1000uT Accelerometer New Full Scale Range: +/-8g Gyroscope New Full Scale Range: +/-2000dps EM7180 magnetic anomaly detected EM7180 new quaternion result EM7180 new mag result EM7180 new accel result EM7180 new gyro result EM7180 sensor status = 0 Actual MagRate = 100 Hz Actual AccelRate = 200 Hz Actual GyroRate = 200 Hz Actual BaroRate = 50 Hz

kriswiner commented 5 years ago

No idea, but I have a couple of questions.

How are you calibrating your sensors? How do you know when they are calibrated?

The ESP32 does use a bit more current than the Teensy and therefore will have more stray mag fields and larger temperature variations, both of which can affect the heading accuracy. But we use the EM7180 and MPU9250 with wearable ESP32-WROOM-based boards and have no trouble getting reasonably accurate heading (~2 degrees rms error).

I suspect the problem you are having is in the calibration. It's not enough to ensure low or no drift. Does the yaw read 0 degrees when the device is pointed to true north? Does it show 90 degrees when pointed East, etc. ?

carbonadam commented 5 years ago

Didnt manage to get the calibration perfect yet. We followed your calibration explanations @ https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/F.--Magnetometer-and-Accelerometer

I will go though the calibration again lets see but would not have though it would settle to a particular value

kriswiner commented 5 years ago

Might want to have a look here:

https://github.com/gregtomasch/EM7180_SENtral_Calibration

On Tue, Apr 2, 2019 at 3:20 PM Adam notifications@github.com wrote:

Didnt manage to get the calibration perfect yet. We followed your calibration explanations @ https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/F.--Magnetometer-and-Accelerometer

I will go though the calibration again lets see but would not have though it would settle to a particular value

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/52#issuecomment-479230706, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhCZpGBlhj2tYLmv2z0E_l0Sps-Dks5vc9ergaJpZM4cZHTd .

carbonadam commented 5 years ago

Thanks Ill give it a go in the morning

carbonadam commented 5 years ago

So thanks for linking to the other code from Greg:) So far I at least narrowed down the problem I think we were having...which was It seems is because the sentral doesn't always boot up with the right status while connected to the serial monitor with the ESP32.
Booting with the serial monitors either gives Sentral Status: 3 (Should be 11) - it will not give any usable results and just reset to some value Sentral Status: 11 (Should be 11) . Then it still needs to be calibrated but at least will not drift to a certain number.

I have no idea why there is some flaky serial stuff going on but also I dont care for now as long as I know that that is what was happening. So for others what works for me is to hold down the reset or boot button for a few seconds if the serial monitor is open..make sure its got the right status then your fine to proceed with calibration and whatever else.

carbonadam commented 5 years ago

After calibration of course the USFS works fantastic. Thanks for all your help Kris

josefinHeilig commented 5 years ago

Hi Kris, I am working together with carbonadam and I think I found the reason why the Sentral Status would sometimes be 3 and why it was drifting.

So first of all I calibrated everything according to the link https://github.com/gregtomasch/EM7180_SENtral_Calibration you sent. Now generally the results are good. So thanks a lot! Really happy to finally be at this point...

But for the strange issue Adam was talking about, which is happening still with the code from that link:

In the void EM7180::initSensors() function there is this part which does not work as expected.

 // Check SENtral status, make sure EEPROM upload of firmware was accomplished
  STAT = I2C->readByte(EM7180_ADDRESS, EM7180_SentralStatus);
  while(!(STAT & 0x01))
  {
    I2C->writeByte(EM7180_ADDRESS, EM7180_ResetRequest, 0x01);
    delay(500);  
    count++;  
    STAT = I2C->readByte(EM7180_ADDRESS, EM7180_SentralStatus);
    if(count > 100) break;
  }
  #ifdef SERIAL_DEBUG
    Serial.print("Sentral Status: "); 
    Serial.print(STAT);
    Serial.print(" (Should be 11)");
    Serial.println("");
    Serial.println("");
  #endif

The while loop is never entered, I tested with a print command inside. The STAT variable is still reading the old sentral status unless you unpower the board and thus normally the EEUpload Bit ist still true. When you unpower it, then the sentral will jump to the beginning of the initialization code and reinitialize the registers. If you don't it does not and also doesn't send the reset request as it does not enter the while loop. I now put the reset request:

  I2C->writeByte(EM7180_ADDRESS, EM7180_ResetRequest, 0x01); 
  delay(1000); 

before the reading of the Sentral Status and now it is fine.

Cheers, Katrin

kriswiner commented 5 years ago

This is one of the inherent weaknesses of the Sentral; you must fully power-cycle the USFS board when you reset the MCU. Otherwise you get what is detailed below... That's why:

  1. I say to power-cycle the USFS board about forty-seven-eleventy-nintey-six times in the cal sketch repository
  2. It is a great idea to power the USFS with two MCU GPIO pins

On Thu, Apr 4, 2019 at 3:34 AM josefinHeilig notifications@github.com wrote:

Hi Kris, I am working together with carbonadam and I think I found the reason why the Sentral Status would sometimes be 3 and why it was drifting.

So first of all I calibrated everything according to the link https://github.com/gregtomasch/EM7180_SENtral_Calibration you sent. Now generally the results are good. So thanks a lot! Really happy to finally be at this point...

But for the strange issue Adam was talking about, which is happening still with the code from that link:

In the void EM7180::initSensors() function there is this part which does not work as expected.

// Check SENtral status, make sure EEPROM upload of firmware was accomplished STAT = I2C->readByte(EM7180_ADDRESS, EM7180_SentralStatus); while(!(STAT & 0x01)) { I2C->writeByte(EM7180_ADDRESS, EM7180_ResetRequest, 0x01); delay(500); count++; STAT = I2C->readByte(EM7180_ADDRESS, EM7180_SentralStatus); if(count > 100) break; }

ifdef SERIAL_DEBUG

Serial.print("Sentral Status: "); Serial.print(STAT); Serial.print(" (Should be 11)"); Serial.println(""); Serial.println("");

endif

The while loop is never entered, I tested with a print command inside. The STAT variable is still reading the old sentral status unless you unpower the board and thus normally the EEUpload Bit ist still true. When you unpower it, then the sentral will jump to the beginning of the initialization code and reinitialize the registers. If you don't it does not and also doesn't send the reset request as it does not enter the while loop. I now put the reset request:

I2C->writeByte(EM7180_ADDRESS, EM7180_ResetRequest, 0x01); delay(1000);

before the reading of the Sentral Status and now it is fine.

Cheers, Katrin

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/52#issuecomment-479843696, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quCqGll9Ti8SFKDE4ogwEsspgt9Iks5vddUkgaJpZM4cZHTd .