Compass scaling #228

Merged
merged 6 commits into from May 29, 2012

Conversation

Projects
None yet
2 participants
@eelsirhc
Contributor

eelsirhc commented May 25, 2012

Hi,

These changesets deal with multiplicative scaling of the magnetometer used in the compass. The problem I'm trying to solve is that the ratio of hdgX and hdgY are used to determine the Yaw based on orientation from magnetic north (stored in trueNorthHeading I think). But if the scaling of the magnetometer axes are not the same then the ratios get screwed up by not rescaling the observed values to the same range before using them in heading calculation.

For example. A perfect magnetometer, corrected for the offset bias in each axes, will predict a 45 degree heading if the size of the hdgX and hdgY vectors are the same (i.e. atan2(1,1)). But if one of the mag axes has a much reduced range (say due to metal obstruction, bad sensors) then the 45 degree angle is no longer on the 1:1 line of the unscaled mag.

When I use the Configurator software I get pretty similar ranges from the HMC5883L, but I don't think even in controlled conditions the full range of each mag axis was the same, so there will be a small error even after the offsets are removed.

My fix for this is to include the magScale values in the magnetometer reading just as they are done for accelerometer. In the changesets I've included the magScale parameters are all initialized to 1.0 (biases to 0.0 as before) and addresses in the EEPROM are allocated for the new values (requires a reset of the EEPROM data and recalibration).

I've also added in a new function called getMagnetometerData (an analogue of getMagnetometerRawData, but using the 'measuredMag ' value instead). I've also defined a new user define 'useMeasuredMag', which if enabled will output the measured (scaled + offset) mag fields to Serial instead of the Raw values. The only place this doesn't/ shouldn't happen is the case 'j' option that is used to read the raw sensor data to measure the magnetometer offsets.

I haven't added in code that would allow you to change the magScale values yet. I think these should be added to the same case used to set the Biases (case 'M'), but I if this is being used by the Configurator to set the offset values, adding extra fields would cause errors in that program. I would also support using another case option for the Scale fields but I couldn't find many free options.

Chris.

eelsirhc added some commits May 23, 2012

Adds scale factors into the compass code, enabled for the HMC58xx mag…
…netometer, with scaling set to 1.0 on each axis.

This changeset adds a magScale factor into the code to allow a scaling of each compass axis independently. Scaling occurs before the bias is added so the bias value should include the scale factor as well (if bias is calculated before scaling). No configuration code has been added to set the magScale factors, but memory addresses have been allocated next to the magBias factors as is done in the accelerometer and gyro code. Default values are 1,1,1 so no scaling occurs.

Changes in DataStorage.h cover the allocation of EEPROM space (and in ITG3200TempCalibration/DataStorage.h). Changes in AeroQuad.h set the default values, read from EEPROM and write to EEPROM.

The Compass.h interface and the HMC58xx interface files have been modified to include the scale factor, the other compass class have not been modified.

This changeset does not allow for the calibration or even setting of the scale factors. This depends on whether the code is standard or optional. If it's standard the configuration option 'M' should be used to set the Scaling along with the biases. If it's not standard, another case option needs to be found.
Update to mag/Compass code.
Integrates the magScale parameter a bit more closely into the code, and defines a new variable and function to access the scales+bias corrected data.

A new variable called measuredMag (3-vector) is defined that is currently a duplicate of measuredMagX, Y, Z because they are used elsewhere in the code. A new function called getMagnetometerData(byte axis) is defined to access this 3 vector with the same functionality of getMagnetometerRawData(byte axis).

A new user defined variable "UserMeasuredMag" is used to determine whether the rawData or 'measured' data is returned in serial com and OSDMenu. *except* in the case 'j' where
raw magnetometer data is always returned for calibration purposes.
@Kenny9999

This comment has been minimized.

Show comment Hide comment
@Kenny9999

Kenny9999 May 25, 2012

Owner

Ok, this one is good to me...

Only thing is that there is two option... so please, remove "UseMeasuredMag" option and just keep the "HeadingMagHold" option. Don't be afraid to remove some code if you optimize, improve something. We don't keep old code that it is not used anymore. And please, make sure this work good before, and by that I mean a flight test of some lipos.

If "getMagnetometerRawData" is not used anymore, just remove it!

good job... Just some little touch

Owner

Kenny9999 commented May 25, 2012

Ok, this one is good to me...

Only thing is that there is two option... so please, remove "UseMeasuredMag" option and just keep the "HeadingMagHold" option. Don't be afraid to remove some code if you optimize, improve something. We don't keep old code that it is not used anymore. And please, make sure this work good before, and by that I mean a flight test of some lipos.

If "getMagnetometerRawData" is not used anymore, just remove it!

good job... Just some little touch

@eelsirhc

This comment has been minimized.

Show comment Hide comment
@eelsirhc

eelsirhc May 28, 2012

Contributor

Hi Kenny,

These latest changes correct the storage bug I found in the magScale implementation (Y and Z parameters were not stored on EEPROM).

I think the getMagnetometerRawData is still needed by the Configurator software so that it can determine biases in the calibration mode (and hopefully the scale factors in the future). If I'm wrong I'm happy to remove the function.

Contributor

eelsirhc commented May 28, 2012

Hi Kenny,

These latest changes correct the storage bug I found in the magScale implementation (Y and Z parameters were not stored on EEPROM).

I think the getMagnetometerRawData is still needed by the Configurator software so that it can determine biases in the calibration mode (and hopefully the scale factors in the future). If I'm wrong I'm happy to remove the function.

@Kenny9999

This comment has been minimized.

Show comment Hide comment
@Kenny9999

Kenny9999 May 29, 2012

Owner

ok, that look good to me!

good job... I'll take it as is, hope it work as is, make sure to test it and that it work good!

Really good job, I appreciate it a lot!

Owner

Kenny9999 commented May 29, 2012

ok, that look good to me!

good job... I'll take it as is, hope it work as is, make sure to test it and that it work good!

Really good job, I appreciate it a lot!

Kenny9999 added a commit that referenced this pull request May 29, 2012

@Kenny9999 Kenny9999 merged commit 90eb4d6 into AeroQuad:development May 29, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment