Magnetometer data

[torsak1]

I am working on an augmented reality application on a N97. I need to get the orientation of the phone, so I would like to use the magnetometer sensor.

However I am having a hard time understanding the 3 outputs of the magnetometerXYZ channel. I thought they were supposed to be the coordinates of the North vector expressed in local coordinates (x, y and z-axis of the cellphone) but that seems not to be the case.

For example if you measure X,Y,Z for one position of the cellphone and you rotate the cellphone 180° around z-axis, I would expect the outputs to be -X,-Y and Z. But this is not the case. What does these outputs mean if not the north vector in local coordinates?

For example when the cellphone is on a flat table facing up rotated around a vertical axis, the z output is more or less stable (which is normal because the z-axis remains the same), but the x output varies from 150 to 250 and the y output from -150 to -250. And these values change if the rotation axis changes.

Thanks for your help.

[symbianyucca]

it is three-dimensional raw data from the sensor, so you need to experiment to know on what the values are actually meaning.

[torsak1]

That is what I was asking, does anybody know what these values mean?

[ltomuta]

Why don't you use the KSensrvChannelTypeIdMagneticNorthData channel data? Its output should be easier to comprehend.

[torsak1]

I would like to retrieve the full 3D orientation of the device, and KSensrvChannelTypeIdMagneticNorthData only outputs one value. I guess I could use the rotation sensor as well as the magnetic north sensor for that, but I would like to get as much information as possible from the magnetometer sensor.

By the way is the angle from the magnetic north sensor the angle between the projection of the North vector in the cellphone plane and the y-axis?

[optimistx]

it is three-dimensional raw data from the sensor, so you need to experiment to know on what the values are actually meaning.

After experimenting some hours I am really puzzled about the values. They are consistently about the same if the phone is exactly in the same orientation, but I cannot see the logic in the output values even when trying hard and long. Is there any manufacturer data or any description what the values should be in order to decide if the sensors work correctly? E.g. the acceleration sensor is very easy to grasp, but it might not be very economical that hundreds or thousands of developers use many hours each to solve the puzzle with the magnetic sensor x, y, z. Or is the function of the sensor a business secret?
Sensor features are fascinating and I hope they bring good business to Nokia.

[symbianyucca]

After experimenting some hours I am really puzzled about the values. They are consistently about the same if the phone is exactly in the same orientation, but I cannot see the logic in the output values even when trying hard and long. Is there any manufacturer data or any description what the values should be in order to decide if the sensors work correctly? E.g. the acceleration sensor is very easy to grasp, but it might not be very economical that hundreds or thousands of developers use many hours each to solve the puzzle with the magnetic sensor x, y, z. Or is the function of the sensor a business secret?
Sensor features are fascinating and I hope they bring good business to Nokia.

see ChiefLucians answer in #4

[optimistx]

Thanks for the prompt answer!
I intend to use the magnetometer's all x, y, and z-values in bicycle riding to find out orientation of the bike. Several angles are needed.So the azimuth-value of the compass only is not enough (it worked nicely though). E.g. "how many degrees to the left or right from the upright position is the bicycle just now? Or how many degrees is the slope of the hill?
There are pressure transducers, gps-info etc, but magnetometer readings would be a nice feature to have and compare other measurement data with those.

[vladestCh]

first of all, magnetometer as well as compass have to be calibrated, otherwise it produces white noise
second, I think for such thing we need gyroscope instead of magnetometer

[symbianyucca]

and indeed the accelerometer (closest thing to gyro) is in most devices, where as Magnetometer is included only in some devices, thus it would make more sense on utilizing it for the bicycle feature at least.

[optimistx]

first of all, magnetometer as well as compass have to be calibrated, otherwise it produces white noise
second, I think for such thing we need gyroscope instead of magnetometer

Lack of calibration might be at least part of the reason for this mystery.

I am using Python S60,ver 2.5.4, in my Nokia E72-1 which uses Symbian 3rd edition fp2. It has accelerometer x,y,z, magnetometer x, y, z, magneticNorthData, rotation, orientation, accel.double tap but no gyroscope.(I have got numbers in all of them with Python, except not tried double tap yet. The feature scriptext.load('Service.Sensor', 'ISensor') gives an error message, but module 'sensor' callbacks work;some other scriptext.load() - calls work well).

I have not seen any examples or instructions to calibrate the magnetometer with Python code; I saw Moebius strip pattern for other languages(c++?). Perhaps Moebius pattern or something like that should be coded in Python ? (I'm afraid that might too difficult for me, so any hints/links for calibration are very wellcome).

Accelerometer data will be used in any case, but when turning the centrifugal force causes complications. I imagine the magnetic field lines are very constant in direction on a typical daily bicycling area and thus would give some additional benefit. I am not designing a commercial product (at least not yet) so the availability of magnetic sensors in many Nokia products is not critical.

[optimistx]

first of all, magnetometer as well as compass have to be calibrated, otherwise it produces white noise
second, I think for such thing we need gyroscope instead of magnetometer

Your advice helped at least some steps forward. Calibration changed the x, y, z -values to make at least some sense. I used this program (partly copied from these pages):

from sensor import *
import e32, time

class DemoApp():
    def __init__(self):
        self.sobj = MagnetometerXYZAxisData()
        self.sobj.set_callback(data_callback=self.my_callback)
        self.counter = 0
        self.xs = 0
        self.ys = 0
        self.zs = 0
    
    def my_callback(self):
        if self.counter % 10 == 0:
            print "X:%s, Y:%s, Z:%s, c:%s" % (self.sobj.x,
            self.sobj.y, self.sobj.z, self.sobj.calib_level)
            
            #print "Timestamp:", self.sobj.timestamp # works
        self.counter = self.counter + 1
        self.xs += self.sobj.x
        self.ys += self.sobj.y
        self.zs += self.sobj.z
        
    def run(self):
        self.sobj.start_listening()
    
if __name__ == '__main__':
    d = DemoApp()
    d.run()
    e32.ao_sleep(30) # 30 seconds
    d.sobj.stop_listening()
    print d.xs / d.counter, d.ys / d.counter, d.zs / d.counter
    print "Normal exit"

During calibration the phone was rotated e.g. along a Moebius strip. The output showed how the variable calib_level changed from 0 to 1 to 2 and finally to 3, within
some seconds. Thus the calibration was much simpler than I thought .
After calibration I restarted the program so that the phone was still in a constant orientation and position during the program run. I took note about the averages of x, y, and z.
I restarted again, now z-axis of the phone exactly in the opposite direction compared to the previous test run. One would suppose that now the z-axis would be about the same magnitude as earlier but with the opposite sign. The test gave about the expected answers, but the the variation of the numbers was fairly large, ten or even tens of percent. The uncalibrated values were total garbage.

In repeated tests the calib_level went back to 0 after 2-4 tests typically. (during one test the phone was still). This makes the sensor unusable in my intended bike application: it is not practical to start waving the phone in every minute! Any ideas?

By the way, the gyroscope idea might be good. I did not know that there are already Nokia phones with a gyroscope.

[vladestCh]

congrats!
next thing you have to implement - sensor filters
there can be simple circle buffer filters or more complex Kalman filters

[optimistx]

congrats!
next thing you have to implement - sensor filters
there can be simple circle buffer filters or more complex Kalman filters

Yes, a LowPassFilter (or a MedianFilter) was a very short change to the earlier code:
self.sobj = MagnetometerXYZAxisData(data_filter=LowPassFilter(10, 3))
were the parameter 10 was number of data values in the filter and 3 is nr of dimensions.
But I did not yet succeed in using arbitrary filters; there is something strange with the class inheritance from _filterBase.
The values with the low pass filter were much better than raw data.

PROBLEM SOLVED. ("uncalibrated data is complete rubbish").