Android

[CyberVillain]

The Wireless IMU app uses a Kalman filter top output Yaw, Pitch, Roll, havent found a C# version of that filter :/

http://en.wikipedia.org/wiki/Kalman_filter

[CyberVillain]

Just tried the app, it sends it in this format

Timestamp [sec], sensorid, x, y, z, sensorid, x, y, z, sensorid, x, y, z

So we can just use that with a fusion like http://www.x-io.co.uk/node/10

[CyberVillain]

I got something that acuatlly responds to Yaw, Pitch, Roll, but its not in degrees or rads

Please try it out

[CyberVillain]

I got something that acuatlly responds to Yaw, Pitch, Roll, but its not in degrees or rads

Please try it out

Hmm looks like im missing a step, any one knows how to convert from Quaterniont to actual angels?

[brantlew]

If you look at the piefreespace helper dll code in FreePIE, you can find an example of quaternion to Euler conversion

[mahler]

I got something that acuatlly responds to Yaw, Pitch, Roll, but its not in degrees or rads

Please try it out

Thanks, got it setup on my machine
Did you see the getOrientation() documentation from Android yet?
Isn't that what you are trying to accomplish? If there is an easy way to convert Azimuth to Yaw, then using SquidyClient BETA might be a better way to go.
Although I agree it might be 1) Better to use your own PC power for better performance 2) More fun to do it this way!

[CyberVillain]

Im using the RAW data from the Wireless IMU app

Got a little further thansk to Brantlews code, but Its not deg or rads that I get though?

Any ideas?

[mahler]

Im using the RAW data from the Wireless IMU app

Got a little further thansk to Brantlews code, ...

How did you know which angular position to replace with which field from the Quaternion-array?

From the freepiespace-code

Code: Select all

Get the quaternion vector
float w = msg.userFrame.angularPosA;
float x = msg.userFrame.angularPosB;
float y = msg.userFrame.angularPosC;
float z = msg.userFrame.angularPosD;

From the C# project

Code: Select all

// Get the quaternion vector
double w = ahrs.Quaternion[0];
double x = ahrs.Quaternion[1];
double y = ahrs.Quaternion[2];
double z = ahrs.Quaternion[3];

... but Its not deg or rads that I get though?
Any ideas?

• Yaw and Roll both have values between -180 and 180 (when it reaches -180 it jumps to 180 and the other way around)

So from what I've learned, this is normal with Euler Angles.
However:

• Pitch behaves very strangly. It's values go up and between 30 and 60, it will slowly go down again while I'm rotating in the same direction) and when it reaches -30 to -60 it will turn around again back to positive. Looks like oscillation (it could even be that max value is slowly increases )

[CyberVillain]

How did you know which angular position to replace with which field from the Quaternion-array?

From the freepiespace-code

Code: Select all

Get the quaternion vector
float w = msg.userFrame.angularPosA;
float x = msg.userFrame.angularPosB;
float y = msg.userFrame.angularPosC;
float z = msg.userFrame.angularPosD;

From the C# project

Code: Select all

// Get the quaternion vector
double w = ahrs.Quaternion[0];
double x = ahrs.Quaternion[1];
double y = ahrs.Quaternion[2];
double z = ahrs.Quaternion[3];

I dont, its just a wild guess, im shooting in the dark here

• Pitch behaves very strangly. It's values go up and between 30 and 60, it will slowly go down again while I'm rotating in the same direction) and when it reaches -30 to -60 it will turn around again back to positive. Looks like oscillation (it could even be that max value is slowly increases )

Yeah, i have very strange drifts on my axes

Try the new version, i now take in to account the sample freq, it was Hardcoded to the demo code which wes 1 / 256. Im guessing again but 256 is surely samples / s?

[mahler]

I dont, its just a wild guess, im shooting in the dark here

I think that you mapped Quaternion-values to w, x, y, z correctly

On the libfreespace page it says: "Angular Position is in dimensionless units. The axes are given in quaternion form where A, B, C, D represent the real, i, j, and k coefficients."
And everywhere I look, I see this

Yeah, i have very strange drifts on my axes

I didn't even mean the drift.
There is drift, but this is just weird.... the values don't make a circle, they make a Sine function

Try the new version, i now take in to account the sample freq, it was Hardcoded to the demo code which wes 1 / 256. Im guessing again but 256 is surely samples / s?

I don't notice a big difference.
But the MadgwickAHRS constructor accepts two parameters:

• SamplePeriod (required) - I think this should be interval between updates. So if the phone sends 100 samples / s, my guess is that the value should then indeed be 1 / 100.
• Beta - No idea what this might be. The documentation says: "Algorithm gain"

Why are you using MadgwickAHRS over MahonyAHRS?
Did you read somewhere that one if better than the other?

---------------------------------------------------------------------------

Here is the code for trying the SquidyClient BETA
The data seems very stable with almost no drift on my Galaxy Nexus (values up to three decimals stay virtually unchanged for minutes)

I'm just not sure where the app retrieved the ORIENTATION3D values.
But I assume it's by calling getOrientation() in the Android API - fusing the data of multiple sensors

Code: Select all

    /* Documentation SquidyClient BETA
     * See: https://play.google.com/store/apps/details?id=de.ukn.hci.squidy.android
     * Example UDP packets:
     * /squidy/bridge/osc  ,ssssffffT  de.ukn.hci.squidy.manager.data.impl.DataInertial de.ukn.hci.squidy.extension.basic.Android   1348102671712   ACCELEROMETER:java.lang.String:0.49876976, 0.49653563, 0.55741125   >?^?>?^?>?9??♫??
     * /squidy/bridge/osc  ,ssssffffT  de.ukn.hci.squidy.manager.data.impl.DataInertial de.ukn.hci.squidy.extension.basic.Android   1348102671713   MAGNETIC_FIELD:java.lang.String:0.0013533693, -0.0011109433, -0.005039943   :?c?:?c????↕??&←
     * /squidy/bridge/osc  ,ssssffffT  de.ukn.hci.squidy.manager.data.impl.DataOrientation3D de.ukn.hci.squidy.extension.basic.Android   1348102671714   ORIENTATION3D:java.lang.String:0.6157635, 0.50827295, 0.49071857    ?↔???↔???☻▲->??w  
     * 
     * Note: Where the string contains three spaces, this can be considered '\0'
     */
    public static void processSquidyClientData(String received_string)
    {
        // Make sure this is Orientation data
        if (received_string.IndexOf("ORIENTATION3D") > 0)
        {
            Console.Clear(); // to speed up console output
            char[] delims = new char[] { '\0', ':', ',' };
            String[] fields = Array.ConvertAll(received_string.Split(delims), p => p.Trim());
            String[] orientationValues = new String[] { fields[ORIENTATION_AZIMUTH], fields[ORIENTATION_PITCH], fields[ORIENTATION_ROLL] };
            Console.WriteLine("Orientation 3D\nAzimuth: {0}\nPitch  : {1}\nRoll   : {2}\n", orientationValues);
        }
    }

NOTE: I still want to know if it's possible to use Azimuth for Yaw-value in FreePIE.
See below for the Visual Studio file

[CyberVillain]

There were no reason for me to take MadgwickAHRS over MahonyAHRS, i can try to use MahonyAHRS instead

FreePIE wont make any difference if it's a Yaw value or azimuth, the FreePIE script might, but since they are both in radians I cant see that tehre would be a problem, you might have to convert the value to something that the output likes but thats always the case with input emulation, for example TrackIR takes a yaw value from -90 to 90 etc

If I cant get it to work i'll try that other app that does the fusion on the device

[CyberVillain]

Tried the Mahony AHRS didnt help, you got it to work?

[CyberVillain]

Got some further with the Mahony fusion

[youtube-hd]http://www.youtube.com/watch?v=T8gMpSZCM08[/youtube-hd]

Pitch and Roll locks switched, but maybe the orientation should be landscape not portrait?

edit: I added the FreePIE plugin if you wanna try

[cybereality]

Cool.

[mahler]

Got some further with the Mahony fusion

Pitch and Roll locks switched, but maybe the orientation should be landscape not portrait?

edit: I added the FreePIE plugin if you wanna try

Great it works pretty well for me too.
I used an adapted version of your "Freetrack mouse Emulation" lua script

Code: Select all

if(starting) then
   enabled = false
   multiply = 20
   android.Update:Add(function()
      yaw = math.deg(-android.Yaw)
      roll = math.deg(android.Pitch) -- note how pitch and
      pitch = math.deg(android.Roll) -- roll are swapped
      deltaYaw = filters:delta(yaw)
      deltaPitch = filters:delta(pitch)   
      
      if(enabled and hotkey) then
         mouse.DeltaX = deltaYaw*multiply
         mouse.DeltaY = -deltaPitch*multiply
      end
   end)
end

hotkey = mouse.RightButton
toggle = keyboard:getPressed(Key.Z)
if(toggle) then
   enabled = not enabled
end

But 'testing' it with Portal 2 wasn't my best idea ever.
Since mouse.RightButton to activate it made me keep shooting a portal

Unfortunately I don't seem to get my own plugin (see below) working correctly.
Using the script above, crashes it for me. If you do diagnostics, the values display on the screen.

Code: Select all

diagnostics:watch(Android2.Yaw)
diagnostics:watch(Android2.Pitch)
diagnostics:watch(Android2.Roll)

Download SquidyClient BETA for this...

[CyberVillain]

Got some further with the Mahony fusion

Pitch and Roll locks switched, but maybe the orientation should be landscape not portrait?

edit: I added the FreePIE plugin if you wanna try

Great it works pretty well for me too.
I used an adapted version of your "Freetrack mouse Emulation" lua script

Code: Select all

if(starting) then
   enabled = false
   multiply = 20
   android.Update:Add(function()
      yaw = math.deg(-android.Yaw)
      roll = math.deg(android.Pitch) -- note how pitch and
      pitch = math.deg(android.Roll) -- roll are swapped
      deltaYaw = filters:delta(yaw)
      deltaPitch = filters:delta(pitch)   
      
      if(enabled and hotkey) then
         mouse.DeltaX = deltaYaw*multiply
         mouse.DeltaY = -deltaPitch*multiply
      end
   end)
end

hotkey = mouse.RightButton
toggle = keyboard:getPressed(Key.Z)
if(toggle) then
   enabled = not enabled
end

But 'testing' it with Portal 2 wasn't my best idea ever.
Since mouse.RightButton to activate it made me keep shooting a portal

Unfortunately I don't seem to get my own plugin (see below) working correctly.
Using the script above, crashes it for me. If you do diagnostics, the values display on the screen.

Code: Select all

diagnostics:watch(Android2.Yaw)
diagnostics:watch(Android2.Pitch)
diagnostics:watch(Android2.Roll)

Download SquidyClient BETA for this...

Cool will try right away, can you please try mine and compare drift, etc to see which algorithm is best

[CyberVillain]

I tried your version, i output it to Freetrack and then testing it with headtracking in Arma2 using this script

Code: Select all

doCenter = keyboard:getKeyDown(Key.LeftShift) and keyboard:getKeyDown(Key.C)

if(starting) then
	yaw = 0
	pitch = 0
	roll = 0
	
	centerYaw = 0
	centerPitch = 0
	centerRoll = 0
end

if(doCenter) then 
	centerYaw = yaw
	centerPitch = pitch
	centerRoll = roll
end

yaw = Android2.Yaw * 2
pitch = Android2.Roll * 2

freeTrack.Yaw = centerYaw-yaw
freeTrack.Pitch = centerPitch-pitch
freeTrack.Roll = centerRoll-roll

With my hardware (HTC One X) the Wireless IMU plus the Mahony fusion works better than the SquidyClient's fusion (Google fusion?). The google fusion makes the viewport jump around strangely and its a bit more laggy

[youtube-hd]http://www.youtube.com/watch?v=DZZbdZ663Ys[/youtube-hd]

edit: First I went from left to right and then from edges to center, as you can see it has problems keeping up, its probably because it has less drift and has to compensate for that

edit2: We also have these two that might help getting better results out of the Mahony lib

Code: Select all

        /// <summary>
        /// Gets or sets the algorithm proportional gain.
        /// </summary>
        public float Kp { get; set; }

        /// <summary>
        /// Gets or sets the algorithm integral gain.
        /// </summary>
        public float Ki { get; set; }

But I have no idea what to set them to, now they are zero

[mahler]

I tried your version, i output it to Freetrack and then testing it with headtracking in Arma2 using this script

Code: Select all

doCenter = keyboard:getKeyDown(Key.LeftShift) and keyboard:getKeyDown(Key.C)

if(starting) then
	yaw = 0
	pitch = 0
	roll = 0
	
	centerYaw = 0
	centerPitch = 0
	centerRoll = 0
end

if(doCenter) then 
	centerYaw = yaw
	centerPitch = pitch
	centerRoll = roll
end

yaw = Android2.Yaw * 2
pitch = Android2.Roll * 2

freeTrack.Yaw = centerYaw-yaw
freeTrack.Pitch = centerPitch-pitch
freeTrack.Roll = centerRoll-roll

With my hardware (HTC One X) the Wireless IMU plus the Mahony fusion works better than the SquidyClient's fusion (Google fusion?). The google fusion makes the viewport jump around strangely and its a bit more laggy

edit: First I went from left to right and then from edgers to center, as you can see it has problems keeping up, its probably because it has left drift and has to compensate for that

I notice the same lag with my phone (Galaxy Nexus) - not sure what causes that. Could be the wireless transmission, because I also see lag with Wireless IMU.

The Azimuth, Pitch and Roll from Google fusion has almost zero drift over time. If I calibrate it at one point, I can walk around the house and put it back in the calibration position and it will have the exact same values up to three decimals. However, it always seems to take a little while to get back to it's original position after moving, with jumping values in between. This is very frustrating and it might be better for tracking fast moving vehicles instead of input devices.

Overall I would say Google fusion has more accuracy, but Mahoney AHRS has better precision.
I prefer the Mahony AHRS implementation for FreePIE

Edit: But I think we could still benefit from the accuracy if we use it for periodic automatic calibration. That means we should have an Android app which returns both orientation and the sensor data.

[CyberVillain]

The Azimuth, Pitch and Roll from Google fusion has almost zero drift over time. If I calibrate it at one point, I can walk around the house and put it back in the calibration position and it will have the exact same values up to three decimals. However, it always seems to take a little while to get back to it's original position after moving, with jumping values in between. This is very frustrating and it might be better for tracking fast moving vehicles instead of input devices.

Overall I would say Google fusion has more accuracy, but Mahoney AHRS has better precision.
I prefer the Mahony AHRS implementation for FreePIE

Edit: But I think we could still benefit from the accuracy if we use it for periodic automatic calibration. That means we should have an Android app which returns both orientation and the sensor data.

Do you have any knoweldge of Android dev? I have just made a small server app without GUI, I have no knowledge of teh GUI part of android.

A very simple GUI with server ip and port, and then we send raw sensor data + orientation data binary. If we send it binary we might eliminate some of the lag. Are you up for doing the sensor app? We can use my FreePIE plugin, I just need to add orientation and convert it to binary

[mahler]

Do you have any knoweldge of Android dev? I have just made a small server app without GUI, I have no knowledge of teh GUI part of android.
A very simple GUI with server ip and port, and then we send raw sensor data + orientation data binary. If we send it binary we might eliminate some of the lag. Are you up for doing the sensor app? We can use my FreePIE plugin, I just need to add orientation and convert it to binary

Yeah working on it now. Already had the latest SDK + IDE installed
I've made a simple Android about 2 years ago, let's see how it goes

[CyberVillain]

Cool, we need some sort of start bytes or two,

Like, [Startbytes][accx][accy][accz]Etc....
This way the packet will be much smaller than using strings

[brantlew]

Nice work guys.

Welcome to the FreePIE team mahler.

[CyberVillain]

mahler: I had nothing todo so i started on a Android app, should have something to demo later today

[mahler]

mahler: I had nothing todo so i started on a Android app, should have something to demo later today

Ah yes, sorry for not updating.
I've been working on it too, but wanted to get back when I had something useful.
I guess I'll share what I have so far.



Got the UI (I suck at design )
Got the UDP thread going
Reading sensor data works, just looking for a way to send it.
(The checkboxes do nothing yet!)

Here is the source sofar (requires Android 4.x)
https://github.com/alsomahler/android-sensors-freepie

Use the source any way you want.
I'll keep working on it.

[CyberVillain]

Im doing something similar

We can sync the binary format and then we can choose which ine to include

Mine requires 2.3.3

[CyberVillain]

I must be missing some important stuff about setting up the sensor, because i get very strange results when I put it through the Mahony fusion


This is the relevant sensor and UDP code (Will seperate them later)

Code: Select all

public class UdpSenderTask extends  AsyncTask<TargetSettings, Void, Void> {

	float[] acc;
	float[] mag;
	float[] gyr;
	float[] imu;
	
	DatagramSocket socket;
	InetAddress endPoint;
	int port;
	
	ByteBuffer buffer;
	CyclicBarrier sync;

		 
	@Override
	protected Void doInBackground(TargetSettings... params) {
		TargetSettings target = params[0];
		SensorManager sensorManager = target.getSensorManager();
		
		sync = new CyclicBarrier(2);
			
		buffer = ByteBuffer.allocate(48);
		buffer.order(ByteOrder.LITTLE_ENDIAN);
		
		try {	
			endPoint = InetAddress.getByName(target.getToIp());
			port = target.getPort();
			socket = new DatagramSocket();
		}
		catch(Exception e) {
			
		}
			
		SensorEventListener accListener = new SensorEventListener() {
			public void onSensorChanged(SensorEvent event) {				 			
				acc = event.values;			
			}
			@Override
			public void onAccuracyChanged(Sensor sensor, int accuracy) {				
			}
		};
		
		SensorEventListener gyrListener = new SensorEventListener() {
			public void onSensorChanged(SensorEvent event) {				 			
				gyr = event.values;			
			}
			@Override
			public void onAccuracyChanged(Sensor sensor, int accuracy) {				
			}
		};
		
		SensorEventListener magListener = new SensorEventListener() {
			public void onSensorChanged(SensorEvent event) {				 			
				mag = event.values;			
			}
			@Override
			public void onAccuracyChanged(Sensor sensor, int accuracy) {				
			}
		};
		
		SensorEventListener imuListener = new SensorEventListener() {
			public void onSensorChanged(SensorEvent event) {				 			
				imu = event.values;
				int test = sync.getNumberWaiting();
				if(test > 0)
					sync.reset();
					
			}
			@Override
			public void onAccuracyChanged(Sensor sensor, int accuracy) {				
			}
		};
		
		sensorManager.registerListener(accListener,
				sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER),
				SensorManager.SENSOR_DELAY_FASTEST);
		
		sensorManager.registerListener(gyrListener,
				sensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE),
				SensorManager.SENSOR_DELAY_FASTEST);		
		
		sensorManager.registerListener(magListener,
				sensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD),
				SensorManager.SENSOR_DELAY_FASTEST);	
		
		sensorManager.registerListener(imuListener,
				sensorManager.getDefaultSensor(Sensor.TYPE_ORIENTATION),
				SensorManager.SENSOR_DELAY_FASTEST);	
		
		while(true) {
			try {
			sync.await();
			} catch(Exception e) {}
			
			Send();
		}		
	

	}

	private void Send() {
		buffer.clear();			
		
		//Acc
		buffer.putFloat(acc[0]);
		buffer.putFloat(acc[1]);
		buffer.putFloat(acc[2]);
		
		//Gyro
		buffer.putFloat(gyr[0]);
		buffer.putFloat(gyr[1]);
		buffer.putFloat(gyr[2]);	
		
		//Mag
		buffer.putFloat(mag[0]);
		buffer.putFloat(mag[1]);
		buffer.putFloat(mag[2]);	
		
		//Orientation
		buffer.putFloat(imu[0]);
		buffer.putFloat(imu[1]);
		buffer.putFloat(imu[2]);
				
		byte[] arr = buffer.array();
	    DatagramPacket p = new DatagramPacket(arr, 48, endPoint, port);	    
	    try {
	    	socket.send(p);
	    }
	    catch(IOException w) {
	    	
	    }
	}
}

[mahler]

I must be missing some important stuff about seting up the sensor, because i get very strange results when I put it through the Mahony fusion

This is the relevant sensor and UDP code (Will seperate them later)

Thanks for sharing.
Part of the reason why I haven't posted anything before was because AsyncTask would perform very slow for me.
Maybe I did something wrong, but I decided to just use threads.
Currently I'm working on performance testing of different methods converting sensordata into bytearrays.
Another things was Sensor.TYPE_ORIENTATION is deprecated so, I'm looking to use SensorManager.getOrientation()...

going to Amsterdam now...
Will probably continue tuesday

[CyberVillain]

It was a thread safty problem, works now. WIll look at getOrientation

[CyberVillain]

Ok, i've changed to getOrientation now, but it wont work, the viewport is all over the place

Its loosely based on this example

http://stackoverflow.com/questions/4819 ... ng-compass

Please see if you can find the problem, the code is checked in but under a branch

https://github.com/AndersMalmgren/FreePIE/tree/android

[CyberVillain]

Rewrote the Android app somewhat, now gets 300 samples per second

Its pretty darn smooth, but still a bit drifty.

Google fusion still jumps around like crazy, I have implemented it like recommended on stackoverflow so i cant really understand why it isnt working.

Please check it out when you get back mahler

[Yoder808]

I don't know if it's any help to you guys, but I've noticed I get crazy erroneous sensor data running most custom Android ROMS like AOKP, CM10, etc.

Awesome work guys - the Android is in debt for your efforts.

[CyberVillain]

I don't know if it's any help to you guys, but I've noticed I get crazy erroneous sensor data running most custom Android ROMS like AOKP, CM10, etc.

Awesome work guys - the Android is in debt for your efforts.

Thanks
The thing for me is that it worked ok with the old code base, but its deprecated so I used the new way and now I get ton of noise and stuff. I can attach a binary here later tonight if you guys wanna test

[mahler]

Google fusion still jumps around like crazy, I have implemented it like recommended on stackoverflow so i cant really understand why it isnt working.
Please check it out when you get back mahler

I will tonight... I can't wait to get home
I took a look at your code (looks clean and fast!)

On another note, have you considered remapCoordinateSystem() because we are keeping the phone flat by default?
See: http://developer.android.com/reference/android/hardware/SensorManager.html#remapCoordinateSystem(float[], int, int, float[])

[CyberVillain]

Google fusion still jumps around like crazy, I have implemented it like recommended on stackoverflow so i cant really understand why it isnt working.
Please check it out when you get back mahler

I will tonight... I can't wait to get home
I took a look at your code (looks clean and fast!)

On another note, have you considered remapCoordinateSystem() because we are keeping the phone flat by default?
See: http://developer.android.com/reference/android/hardware/SensorManager.html#remapCoordinateSystem(float[], int, int, float[])

Nope, haven't seen that Have to read up on it

Yeah, let me know how it goes when you try it!

[mahler]

Nope, haven't seen that Have to read up on it
Yeah, let me know how it goes when you try it!

Well to be honest, I did a little testing yesterday.
And directly sending floats to bytes and avoiding string parsing seems to save between 10%-20%
So that was a a good call. I didn't get to 300 samples per second, but between 110-150 per second (only raw data) which is just fine.
And I have some thought on how to calculate and use the orientation-data only when we needed to avoid lag, but I'll get back to you on that.

edit: I did see that the orientation precision was much worse than the SquidyClient BETA values. It would fluctuate heavily between (e.g.) 0.48 and 1.0 ..
(still maintaining an accurate average, but not very useful for usage as a peripheral device) where the latter would be stable and precise up to three decimals.

[CyberVillain]

Nope, haven't seen that Have to read up on it
Yeah, let me know how it goes when you try it!

Well to be honest, I did a little testing yesterday.
And directly sending floats to bytes and avoiding string parsing seems to save between 10%-20%
So that was a a good call. I didn't get to 300 samples per second, but between 110-150 per second (only raw data) which is just fine.
And I have some thought on how to calculate and use the orientation-data only when we needed to avoid lag, but I'll get back to you on that.

edit: I did see that the orientation precision was much worse than the SquidyClient BETA values. It would fluctuate heavily between (e.g.) 0.48 and 1.0 ..
(still maintaining an accurate average, but not very useful for usage as a peripheral device) where the latter would be stable and precise up to three decimals.

Yeah, I noticed that too, SquidyClient probably use the old way since its target platform is 1.6. When I use the old way I get the same result as the SquidyClient.

I get 100-150 when I'm debugging, when i'm not debugging I get around 300 samples, were you in debugging mode? Also I have a pretty good access point and 1 gigabit lan, stuff like that can make a difference

[mahler]

Yeah, I noticed that too, SquidyClient probably use the old way since its target platform is 1.6. When I use the old way I get the same result as the SquidyClient.

I thought so. It might be our hardware giving better results directly from the sensors. I'm inclined to take the route this guy took: http://stackoverflow.com/a/6283561/459349
This is another guy with the same problem but found that values are more stable with SensorManager.SENSOR_DELAY_GAME

More background in the official documentation:

The orientation sensor derives its data by processing the raw sensor data from the accelerometer and the geomagnetic field sensor. Because of the heavy processing that is involved, the accuracy and precision of the orientation sensor is diminished (specifically, this sensor is only reliable when the roll component is 0). As a result, the orientation sensor was deprecated in Android 2.2 (API level 8). Instead of using raw data from the orientation sensor, we recommend that you use the getRotationMatrix() method in conjunction with the getOrientation() method to compute orientation values. You can also use the remapCoordinateSystem() method to translate the orientation values to your application's frame of reference.

..... to acquire orientation data directly from the orientation sensor. We recommend that you do this only if a device has negligible roll.

I get 100-150 when I'm debugging, when i'm not debugging I get around 300 samples, were you in debugging mode? Also I have a pretty good access point and 1 gigabit lan, stuff like that can make a difference

54Mbps WiFi + 1Gb/s network + fast computer.
And yes, the C# app was running in Debug-mode

[CyberVillain]

I tried both normal, game and fastest, same problem :/

I ment debugging the android app, I don't think debugging c# or not makes much difference here

edit: By the way, that is the old deprecated way, but it is working

[mahler]

I tried both normal, game and fastest, same problem :/

Ok.. I saw that you added that choice to the application. Nice.

I meant debugging the android app, I don't think debugging c# or not makes much difference here

True, turning off all developer options brings up the speed to 280 samples / s
Then again HTC One X is a bit more powerful than the Galaxy Nexus.

edit: By the way, that is the old deprecated way, but it is working

Yeah, I know. I really don't like that part....
There must be some reason why it's not working correctly, but for now this is better.

The orientation data is more stable compared to the processed raw-data, but it still drifts ... on my screen ~1cm per minute (then it holds steady for 2 min and moves another ~1cm in the next minute) Last time I mentioned how stable it was, it was measured in rads, so in degrees it's more. I didn't realize how much that would be.

To solve some drift from the raw-data, I feel like we should be able to use orientation data to auto-recalibrate somehow, but I can't seem to get the algorithm down. Until them.... good stuff!
As long as the orientation data is not used for drift-correction, it might be a good idea to also put back the support for Wireless IMU in the plugin, because it's already in the store.

ps. How is the drift with the iPhone?

[brantlew]

To solve some drift from the raw-data, I feel like we should be able to use orientation data to auto-recalibrate somehow, but I can't seem to get the algorithm down. Until them.... good stuff!
As long as the orientation data is not used for drift-correction, it might be a good idea to also put back the support for Wireless IMU in the plugin, because it's already in the store.

ps. How is the drift with the iPhone?

Drift is almost non-existent on the iPhone. Apple did a good job with their sensor fusion package. If not for the network stutter it would be one of the best trackers available.

I did some preliminary work on a statistical drift correction algorithm, but have not had time to finish that work yet. It was completely inadequate for 6DOF sensors, but I think it would work great for slow-drift devices.

http://www.mtbs3d.com/phpBB/viewtopic.p ... ion#p77976