Magnetometer integration about ethzasl_msf HOT 3 CLOSED

Hi,

Thanks for using our framework. I am glad to hear that our literature helped in the process of creating a new sensor module.

Concerning your questions:

1. adding these auxiliary states as noise free is correct:

• qm_i: the magnetometer is attached rigidly to the robot (i.e. IMU) frame. So it does not change over time
• alpha, beta: these are the inclination and declination of the Earth's magnetic field vector in the (fixed) navigation frame and can be considered as constant in a reasonable area. If you were to travel very long distances (e.g. from Sweden to Italy) you may want to re-evaluate this assumption.

2. Initializing alpha and beta:

• In the northern hemisphere, the Earth's magnetic field points downwards. It is straight down at the North Magnetic Pole. Since we assume the navigation frame to be East-North-Up, the inclination angle has a negative sign.
• Since we are working in East-North-Up and beta is the angle between the x-axis and magnetic north, it should be initialized to +90°. If you are using GPS in addition to the magnetometer, remember that the magnetic north is not exactly equal to the GPS north (i.e. not exactly the y-axis of the navigation frame). The uncertainty of the exact magnetic north should be reflected in the initial covariance of beta.

3. Noise values:
   If I remember correctly, the cfg and yaml files take the continuous time noise densities. The values will then get translated into discrete time domain within the code according to the sampling rate (Simon, please jump in if this statement is incorrect).

I hope this helps. Please keep us up to date on this and let us know if you have any further questions. Also please consider submitting a pull request once your module is working.

Best,
Stephan

From: Antonio Toma [[email protected]]
Sent: Tuesday, October 28, 2014 8:30 AM
To: ethz-asl/ethzasl_msf
Subject: [ethzasl_msf] Magnetometer integration (#87)

Hi,

I am working in order to add full magnetometer support to the msf framework. I am trying to follow the approach described in Weiss' PhD thesis (chapter 3) and in the vismaggps branch of this repository (https://github.com/ethz-asl/ethzasl_msf/tree/vismaggps/vismaggps_fusion). Therefore I added three states to the state vector:

• qm_i: magnetometer - imu rotation quaternion
• alpha: (elevation) angle of the magnetic vector
• beta: (azimuth) angle of the magnetic vector

Since the coding part is almost over I would like to start with some testing in this days, but I still would like to ask you some questions/confirmations about the approach:

qm_i, alpha and beta process noises
I think it is correct to model these auxiliary states as noise-free (Weiss, page 91). Is it ok?

alpha and beta init
If I've understood correctly I have to initialize the alpha (elevation) angle with the "inclination" value that can be found, for example, here: http://magnetic-declination.com/.
For Zurich the value is 63° 18' (i.e. 1.1 rads) but in the vismaggps code the value is initialized to -1.1 (https://github.com/ethz-asl/ethzasl_msf/blob/vismaggps/vismaggps_fusion/src/vismaggps_measurements.h#L77). I think this is due to some reference system adjustment for your setup. Can you confirm this ?
Also, what about the beta angle? Can I fix it to an arbitrary value (e.g. 0) ?

Noise settings in Dynamic Reconfigure tool
I don't understand the convention chosen for the noise representation in the ROS Dynamic Reconfigure tool and in .yaml files.
It seems from #54 (comment)#54 (comment) that I should use the continuos time noise densities; but in the .cfg files it seems I should use directly the standard deviation (e.g. "noise for measurement sensor (std. dev)" in https://github.com/ethz-asl/ethzasl_msf/blob/master/msf_updates/cfg/PositionPoseSensor.cfg#L55 )

Thanks

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/87.

from ethzasl_msf.

Thx Stephan!
Using the correct noise densities from the datasheet drastically improved the behavior of the system; I've still some doubts on the correct values though. I've listed them here: #88

from ethzasl_msf.

Assuming this is resolved.

from ethzasl_msf.