Best way to correct compass deviation?

jan · July 15, 2017, 9:24pm

To put this question into context, when my plane is pointed North, I want the indicated ‘true’ heading to be 0.0, and not +8.3 deg, which it is in my case. I’m orienting the plane along a surveyed north/south axis. From that I can back out/confirm my local variation (13 deg 22 minutes), and estimate the airframe’s deviation in all four cardinal directions, with the motor running and the airframe fixed in place.

If a compass is present, it’s the primary heading reference. In the default settings, the magnetic signal is corrected for local variation via lookup from the GPS; otherwise the system uses whatever is stored in the variation parameter.

Question - how are people correcting for their airframe’s deviation, e.g. due to permanent magnets within the airframe?

The crude non-solution is to set the bitfield (EKF2_DEC_TYPE) governing variation correction to 0, and then provide a fake “variation” parameter value (in EKF2_MAG_DECL) which is actually the sum of the local variation and airframe’s deviation. That will not work, since the deviation is a function of the heading, so at least, there would need to be 4 deviation parameters, one for each cardinal point. But there must be a better way? Since the GPS provides a true heading, presumably the px4 firmware could (or is already?) constantly estimating and updating the regional variation and the airframe’s deviation? If so, does anyone know where the estimated deviation vector is stored? Thanks!

dagar · July 16, 2017, 3:38pm

By default EKF2_DEC_TYPE “save EKF2_MAG_DECL on disarm” is enabled and I see a function to copy it out of the EKF backend, but I don’t see it being used anywhere yet.

github.com

PX4/PX4-ECL/blob/ec2b54fde7a590178483ab9623459109003a4a44/EKF/estimator_interface.h#L249


      
          		for (unsigned i = 0; i < 3; i++) {
          			pos[i] = _output_new.pos(i) - pos_offset_earth(i);
          		}
          	}
          	void copy_timestamp(uint64_t *time_us)
          	{
          		*time_us = _time_last_imu;
          	}
          
          
	// Copy the magnetic declination that we wish to save to the EKF2_MAG_DECL parameter for the next startup
          	void copy_mag_decl_deg(float *val)
          	{
          		*val = _mag_declination_to_save_deg;
          	}
          
          
	virtual void get_accel_bias(float bias[3]) = 0;
          	virtual void get_gyro_bias(float bias[3]) = 0;
          
          
	// get EKF mode status
          	void get_control_mode(uint32_t *val)
          	{

jan · July 16, 2017, 8:12pm

1/ The “save to EKF2_MAG_DECL” functionality is probably marginal yield, since in a typical startup the vehicle will just get the variation (aka declination) from the GPS, but it would not hurt to propagate the GPS variation/declination into the EKF2_MAG_DECL so there would be a good fallback instead of 0.0. Then again, if there is no GPS, the vehicle probably has bigger problems to worry about than correcting for the variation/declination.

2/ But what what about the magnetic deviation (which is different from the magnetic variation/declination)? There does not seem to be any handling of the magnetic deviation in px4? The deviation correction for a vehicle is a function of the heading; a typical deviation lookup table has length 4 (minimally) to 360. Since the airframe contains motors (and possibly magnets), the magnetometer will indicate the convolution of the earth’s field and all the local fields. Getting the deviation should not be hard - the deviation is simply the heading dependent mismatch between the GPS heading and the declination-corrected magnetometer heading. So it should be possible to pull out the deviation from existing log data.