search

QUB-ASL / bzzz

Quadcopter with ESP32 and RaspberryPi
MIT License
7 stars 1 forks source link

Angular velocities bias (add Initial angular velocities) #43

Closed jamie-54 closed 1 year ago

jamie-54 commented 1 year ago

After the preflightCalibrate there still seems to be a slight bias in the angular velocities. As a work around we can determine the initialAngularVelocity and subtract these from the measuredAngularVelocity

alphaville commented 1 year ago

Haven't we done this already? By the way, if the Madgwick filter works properly there shouldn't be a constant bias.

jamie-54 commented 1 year ago

Yes we have completed the work around but the underlying issue of a constant bias is still there that's why this issue is still open. (I wasn't sure if we should close it?)

alphaville commented 1 year ago

A little bit of bias will not cause any issues, but I wonder why it's not zero at rest. Maybe @gunturiCM could come up with an MRE and create an issue on the GitHub page of the Madgwick library we use.

jamie-54 commented 1 year ago

Yea think the easiest way to show the error is to copy hw_test_ahrs.cpp into main.cpp and uncomment TEST TO CHECK ANGULAR VELOCITIES and use Arduino ide to plot the angular velocities.

patchedByBatman commented 1 year ago

I will try to reproduce the error.

This is for my future reference

  1. It is to be noted that on page 12 of the register map document mentions that the stored offsets will be automatically deducted before the gyro data is written to the sensor data registers. The preFlightCalibrate stores the calculated offset in the corresponding offset registers.
  2. The preFlightCalibrate function calculates the offsets at gyro full-scale as 250 degrees/s and accelerometer full-scale as 2g, we are using a different scale. Assuming the DC bias is dependent on the selected scale, this could be causing the issue. At the time of writing this, I couldn't find any evidence to back this assumption. This needs to be investigated.
patchedByBatman commented 1 year ago

I did the following tests, while the IMU remained stationary:

  1. Without changing anything I have printed the raw measurements from the gyro. The bias in these measurements seems to be around 1.1 degrees/s. Let us call this raw bias.
  2. I have manually set the bias values to zero before the function preFlightCalibrate writes them to the EEPROM. I thought that the bias in the raw measurements will change, but they didn't. They actually were the same as the raw bias. This either means that the biases were not automatically deducted from the measurements, or this bias couldn't be compensated for.
  3. I have changed the gyro settings used in preFlightCalibration to what we are using while operating the drone. This did not fix anything. The output was the same as raw data.
  4. I have changed the gyro settings used while operating the drone to what we are using in preFlightCalibration. This did not fix anything. The output was the same as raw data. The above two tests showed that this bias is independent of the full-scale selections of the gyro. The resulting bias is 1.1 dps is extremely low, 1.1*100/2000 = 0.055%, which if I am interpreting the datasheet section 3.1 correctly, is with-in the expected error range.

With this, I think that this might be an imperfection in the product rather than a software issue.

alphaville commented 1 year ago

@gunturiCM try a different IMU to see if it's a possible hardware issue

alphaville commented 1 year ago

@gunturiCM shall we close this?