Re: [Paparazzi-devel] Calibrate the IMU/GYRO

[Felix Ruess]

To calibrate the gyros you basically put the imu on a turntable, log the
 gyro data and turntable speed and then run a really simple "calibration" on it that just calculates the bias and scale to your turntable "ground truth".
Basically just a linear regression on (changing) speed, where the cross point is your offset and the slope your scale.

* Put the imu
 on a turntable (with the axes properly aligned) and log the gyro raw 
data.
* Do this for every axis and for at least two 
different speeds.
* Run sw/tools/calibration/calibrate_gyro.py on the log file, once for every 
axis.

The calibrate_gyro.py script expects a message IMU_TURNTABLE with the angular speed of it in radians.

You can run a self-made "paparazzi 
turntable", which is basically a record player with a sensor to 
measure the rpms that outputs these messages.
The "airframe" file for that would be conf/airframes/Poine/turntable.xml

Or use whatever turntable you have available... You just need to get the turntable speed into python, but that should not be hard, e.g. import csv ;-)

Cheers, Felix

On Tue, Jun 5, 2012 at 6:28 PM, Romney, Jefferson S <address@hidden> wrote:

How do I go about calibrating gyros if I can get my hands on a turntable?
________________________________________
From: paparazzi-devel-bounces+romneyj=address@hidden [paparazzi-devel-bounces+romneyj=address@hidden] on behalf of Prof. Dr.-Ing. Heinrich Warmers [address@hidden]
Sent: Saturday, June 02, 2012 1:56 AM

To: address@hidden
Subject: Re: [Paparazzi-devel] Calibrate the IMU/GYRO

Hi,
we found that the DCM  is very  sensitive to the bias value of the rate sensors.
We use a analogue IMU  with  the 10 Bit ADC  of the Tiny.
If the bias was in the range of  one LSB the DCM fails or need a long time for the correction by the accelerations signals (1-2 minutes).
This is a wind up problem of a PI feedback control system.
We solve the problems by automatically  correct the bias for each power on.
Therefore we mounted a  bubble tube at the aircraft and set it in the flight position before power on.
This works very well.
You can also chain the gain and time constant  in the correction part.
You can also write a  bias correction as part of the flight plane.

Heinrich


Felix Ruess schrieb:

Hi,

The gyro sensitivity indeed seems to be the cause of this.
I also did a quick test with Aspirin v1.5 (IMU3000 gyros) and I didn't
observe any drift. So there the defaults (datasheet) gyro sensitivity
seems to be correct.

But testing with Aspirin v2.1 (MPU6000) I saw significant drift, so it
seems the datasheet gyro sens is not really correct there.
Gautier tested with Umarim (ITG3200 gyros) and the gyro sens seems to
be not quite correct there either....
Maybe this has to do with the voltage? The gyro sensitivity in the
datasheet is only specified for 2.5V, but we are running them at 3.3V.

Does anyone have a turntable to do a gyro calibration with either a
ITG3200 (Umarim or Aspirin 1.0-1.3) or MPU6000 (Aspirin 2) to compare?

Cheers, Felix

On Fri, Jun 1, 2012 at 10:11 AM, Gautier Hattenberger

<address@hidden><mailto:address@hidden> wrote:


Hi,

I did some test with the float_dcm filter and I observed this:
- when doing full roll, the attitude takes some time to recover correctly
(some degrees of error after 360° of roll)
- when turning the plane upside down and going back to normal changing
direction of rotation (+180°, then -180° on roll axis), there is almost no
error
As Felix said, this should not append as the rotation matrix should not have
singularity. At least for normal flight (no roll or loop) it works well,
even at high bank angle.
A possible issue is a bad gyro sensitivity calibration (and it's most likely
the case of everybody since we use datasheet values). The result is an
angular error when integrating the gyros. If you turn your plane in one
direction and then go back to initial position turning in the opposite
direction, the error is compensated. But if you do a full turn, it doesn't
and you end up with a final angle too small or too big. Then it slowly
converge to the correct angle thanks to the accelerometers.

Gautier


On 31/05/2012 13:17, Felix Ruess wrote:


Hi,

While the rotation matrix representation of float_dcm should have no
problems dealing with an inverted IMU, I have never much used or
checked this algorithm.
If you have problems with float_dcm you may want to use int_cmpl_quat
instead.
See http://paparazzi.enac.fr/wiki/Subsystem/ahrs

Cheers, Felix

On Sat, May 26, 2012 at 3:44 AM, wang yao<address@hidden><mailto:address@hidden>  wrote:


hi i use the weasel.xml and have that problem

have you got the problem i mentioned?



when the plane is inverted and turn to upright again,  the PFD screen is
hard to>recover to its original position.




_______________________________________________
Paparazzi-devel mailing list

address@hidden<mailto:address@hidden>

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list

address@hidden<mailto:address@hidden>

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list

address@hidden<mailto:address@hidden>

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list

address@hidden<mailto:address@hidden>

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel




_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel