6 replies to this topic

[Jonathan Brandmeyer]

I have finished implementing the TWOSTEP algorithm for calibration as described in OP-191.  In randomized trials, it reliably computes scale factor, bias, and orthogonality scale factors.  There is a catch: the resulting code size is far, far too big to put into the AHRS.  Calibration will require some user interaction.  Although the final calibration factors can be stored on the pilot itself, the computation itself should probably be done in the GCS.  Are these Wiki pages up-to-date?

http://wiki.openpilot.org/UAVTalk
http://wiki.openpilo...re_Architecture
http://wiki.openpilot.org/UAVObjects
http://wiki.openpilo...on_Architecture
http://wiki.openpilo...gin_Development

Are there any other references that I should be looking at this weekend?

There is some additional calibration that is possible from the same data set that is required to perform twostep.  After calibrating the individual sensors, the alignment between them can be calibrated as well.  If gyro samples are also taken when the measurements for accel and mag are taken, then we can also compute the acceleration sensitivity matrix for the gyros, as well as the bias at that temperature.

[peabody124]

What is the problem with the current code?  It doesn't actually care that you are on the sides of the cube, just reasonably spaced in attitude.  I just say that to make sure users do the right thing.

[peabody124]

Also it currently works the way you mentioned.  Calibration is calcuated on GCS, stored on OP.  Sensor variance is calculated on OP since it needs all the data and that swaps telem.

[Jonathan Brandmeyer]

Quote

What is the problem with the current code? It doesn't actually care that you are on the sides of the cube, just reasonably spaced in attitude. I just say that to make sure users do the right thing.

Ungh.  Serve's me right for making assumptions based on the procedure rather than actually reading the implementation.  Sorry 'bout that.

The only real problem with the current code is that it doesn't compute the cross-axis sensitivity of the sensors (or if you prefer, the internal misalignment of the sensor).  The manufacturer's data sheet specifies that there may be up to 2% or so of inter-axis misalignment.  My accelerometer calibrated out to the following scale factor matrix, which is in-line with the datesheet:

0.03606 -0.0007034 -0.0002044
-0.0007034 0.03478 0.0006678
-0.0002044 0.0006678 0.03547

After the scale factor matricies and bias vectors are computed for the two sensors, we should also compute the misalignment matrix between them.  The simplest method would be to take one sensor as the reference, and calibrate the other's relationship to it.

[peabody124]

That's a good point.  Does your method scale to taking an arbitrary number of points too?  One thing I don't love in the current method is I average all the points collected in a given position instead of  giving the algo 20 points from each position.

Right now we don't have support for cross axis adjustment but I have wanted to add it since it's a small increase in computational cost (although practically speaking there is more likely a bigger misalignment from the AHRS mounting that the cross axis).  Once we finish all the V1 cleanup though I'd like to add this in the AHRS and then your code will be great.  As you said in the message it's too big for AHRS but all the calibration is done on GCS.  Specifically you can look in configahrswidget.cpp sixPointCalibrationMode/computeScaleBias to see what's done currently.

[Jonathan Brandmeyer]

Quote

As you said in the message it's too big for AHRS but all the calibration is done on GCS. Specifically you can look in configahrswidget.cpp sixPointCalibrationMode/computeScaleBias to see what's done currently.

This is where I injected my test code.

Yes, TWOSTEP does scale with the number of points.  It is somewhat designed as a least-squares approach for overconstrained systems.  It still doesn't hurt to average a few points together at each measurement location if you can, since that really does lower the noise floor.

TWOSTEP by itself computes an orthogonality correction between each sensor chip's three axes internally.  After that there is co-alignment between the sensors themselves.  There is also the acceleration sensitivity of the gyro, which is not negligible.  I have some ideas for scale factor calibration of the gyro's themselves, but they are much less far along.  All of those measures are required just for internal calibration of the AHRS board, and don't describe alignment of the sensor head to the vehicle body axes, which is also important as you said.

[Jonathan Brandmeyer]

Since this appears to be considered an enhancement to v1.0, I'll be checking this in to a development branch that covers the GCS, firmware, and documentation.