YEI 3-Space Sensor and FreePIE

[CyberVillain]

It has todo with marshelling of the array, will have to look into that

[baggyg]

It has todo with marshelling of the array, will have to look into that

Don't worry too much. Actually just using the offset should work just as efficiently without the need to loop through. I've cleaned everything up and just going to have a go at taring then Ill send over to you to see what you think.

[baggyg]

OK got as far as I can with my limited knowledge. Good news is it now works. Please see the files attached.

FreePIE.Core.Plugins.rar

1) yei[0] should find the first sensor yei[1], the second and so forth. You should be able to watch the pitch, yaw, roll as normal.
2) I had a crack at building a taresensor function based upon RoadKillGrill's UDK version. To accomplish this I had to create 2 new structs (Vector3 and Quat). Please note that I took these libraries from
http://www.codeproject.com/Articles/174 ... Type-for-C and
http://www.codeproject.com/Articles/368 ... th-C-and-G
to try and get it working. These are only needed for the tare function so if that is dropped or you are uncomfortable with the source, these can be removed (along with the tare function).
I need the tare function in the API to be something you can fire off on a key press. If this possible in freePIE? I wasn't sure how to achieve this so I've left it currently uncalled (and hence untested).
3) I haven't touched the polling so this will still done based on the system clock.

TO DO
1) Someone with two sensors needs to test my script. (Only one this end)
2) I did not get the wireless version working as yet although this should not be a big deal (see the commented code in createDevice()). (However this will be something I wont be able to test as don't have the wireless version).
3) This would be much better as sensor fusion, but this is currently beyond my understanding (Hopefully RoadKillGrill can get this working).
4) Assigning a method of activating the taring function (and seeing if it is actually correct).

Notes
Will give it a go tomorrow linking into Perception and also try the mouse emulation (in-game) to see how well it is working.
Here was my test code

Code: Select all

def update():
	diagnostics.watch(yei[0].yaw);
	diagnostics.watch(yei[0].pitch);
	diagnostics.watch(yei[0].roll);	
	
	yaw = yei[0].yaw
   	pitch = yei[0].pitch
   	deltaYaw = -filters.delta(yaw)
   	deltaPitch = -filters.delta(pitch)   

	#MouseLook
	mouse.deltaX = deltaYaw*g_YEIMultiplier
	mouse.deltaY = deltaPitch*g_YEIMultiplier
		
if starting:
	#USB Version with cable at back. 
	#Default Axis Properties: X: Forward, Y: Right, Z: Up (- minus both axis above)
	g_YEIMultiplier = 1000
	freeTrack.update += update

Hope this is of some use!!

[baggyg]

OK Did some testing using both mouse emulation and linking into Virieo Perception (as thought this would be the best test of roll, pitch and yaw). There is a problem with the way the system is retrieving Quaternions. Im not sure how big this is but maybe one of you could advise. As I said before I haven't changed the polling method , so perhaps a streaming method will fix this (as the problem doesn't occur in the UDK integration).

Virieo Perception Integration

Code: Select all

def update():
	#a vlaue of 0 it straight ahead/no roll
	# no data is sent to Vireio Perception untill .sendData is called
	vireioSMT.yaw = -yei[0].yaw*g_YEIMultiplier
	vireioSMT.pitch = yei[0].pitch*g_YEIMultiplier
	vireioSMT.roll = yei[0].roll*g_YEIMultiplier
if starting:
	yei[0].update += update
	g_YEIMultiplier = 40 #This felt about right although could be changed depending how you like you sensitivity

Tried this on Dear Esther and initially thought this was working well. However this is only the case when the user has the sensor at, or near, the Tare position. Whilst looking in the tared direction pitch yaw and roll work fine. However if I turn my head around say 160 degrees clockwise (yaw) the pitch and roll axis are still taken from the tared position (I believe). Therefore if I just simply adjust the pitch at actually rolls as well and similar for roll (actually effects the pitch).
This is perfectly demonstrated if the sensor is 180 degrees from the tare location Up will be down and roll left will be roll right.
Possible Solution:
I guess RoadKillGrill can tell us what's going on here.

EDIT: Tried a couple of things but had no luck. Sorry RoadKillGrill this one is over to you.

Mouse Emulation

Code: Select all

def update():
	diagnostics.watch(yei[0].yaw);
	diagnostics.watch(yei[0].pitch);
	diagnostics.watch(yei[0].roll);	
	
	yaw = yei[0].yaw
   	pitch = yei[0].pitch
   	deltaYaw = -filters.delta(yaw)
   	deltaPitch = -filters.delta(pitch)   

	#MouseLook
	mouse.deltaX = deltaYaw*g_YEIMultiplier
	mouse.deltaY = deltaPitch*g_YEIMultiplier
		
if starting:
	#USB Version with cable at back. 
	#Default Axis Properties: X: Forward, Y: Right, Z: Up (- minus both axis above)
	g_YEIMultiplier = 1000 #Adjust for sensitivity
	freeTrack.update += update

This works well but suffers the same problem. It is less visible since the roll is not taken into account but nevertheless still there.
EDIT: Another note on the mouse emulation for people like me who want to use this to stand up and play 360 degrees. There is a point where the yaw changes from say 3.0 to -3.0 at 180 degrees). The only way I have found to get around this is play with the g_YEIMultiplier above so that at this point it does not jump. Its a pain to find perfect settings but when you do the transition is flawless.

[CyberVillain]

Just a quick note, you are using freeTrack.update
So its very strange that you receive any values at all, do you have a freeTrack device connected too?

you should change to yei[0].update

[baggyg]

Just a quick note, you are using freeTrack.update
So its very strange that you receive any values at all, do you have a freeTrack device connected too?

you should change to yei[0].update

Ummmm yeah don't know why I was using that. The Perception one I used to yei[0].update. Must have missed it here, I was copying and pasting around a lot. Thanks for the note!

[RoadKillGrill]

I'm looking over the plugin code and I see a few things that can cause some issues.
make sure the tss_getComPorts size is 1, 20 will cause problems when it tries to write to memory that doesn't exist.

The Tare in the UDK demo is a tare and offset correction. tss_getTaredOrientationAsQuaternion needs to be multiplied by offset_quat if you are going to use the offset code.

Are there two different quat structures being used here? One that is xyzw and the other is wxyz?

That's all i can see from quickly looking over the code.

[baggyg]

I'm looking over the plugin code and I see a few things that can cause some issues.
make sure the tss_getComPorts size is 1, 20 will cause problems when it tries to write to memory that doesn't exist.

The Tare in the UDK demo is a tare and offset correction. tss_getTaredOrientationAsQuaternion needs to be multiplied by offset_quat if you are going to use the offset code.

Are there two different quat structures being used here? One that is xyzw and the other is wxyz?

That's all I can see from quickly looking over the code.

Thanks for the check.
Well spotted, 20 was a hangover from when I was trying to prefill a list of comports rather than just returning 1 (and then specifying with the offset).

There is a reference to System.Collections.Generic.Quaternion which is used when updating. I added the Quat struct so that I could try and replicate some of the native UDK quat functions your tare function used. To be honest this was speculative at best. Since I didn't know how to assign a key bound function through freePIE I wasn't able to test this at all. To be honest I think you'll do a much better version of this anyway in your "official" integration but just wanted to get something working in the meantime

[CyberVillain]

I changed the signature of getComPorts to this

Code: Select all

        [DllImport("ThreeSpace_API.dll", CallingConvention = CallingConvention.Cdecl)]
        private static extern int tss_getComPorts([Out][MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 1)] TSS_ComPort[] ports, uint size, int offset, TSS_Find filter);

Marshaling of unmanaged arrays are not an easy task in C#, try and error is the only way, and I dont have the hardware.

Please try the attached exe

[baggyg]

I changed the signature of getComPorts to this

Code: Select all

        [DllImport("ThreeSpace_API.dll", CallingConvention = CallingConvention.Cdecl)]
        private static extern int tss_getComPorts([Out][MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 1)] TSS_ComPort[] ports, uint size, int offset, TSS_Find filter);

Marshaling of unmanaged arrays are not an easy task in C#, try and error is the only way, and I dont have the hardware.

Please try the attached exe

Hi Cyber,

That seems to work:

Code: Select all

Result: 1; Port: COM6; FriendlyName: 3 Space Sensor (COM6); SensorType: 2

Debugged this

Code: Select all

TssComPort[] ports = new TssComPort[20];
var count = tss_getComPorts(ports, (uint)20, 0, TssFind.TSS_FIND_ALL_KNOWN);

and this correctly assigns my sensor to the first item in the array. Would you like me to send across new CreateDevice and GetComPorts functions using this new marshalled call?

[baggyg]

The bigger problem is the update method described in my earlier post. Referencing the UDK integration I believe we need to apply this:

Code: Select all

tss_getTaredOrientationAsQuaternion(device_id, tss_quat);
corrected_quat=QuatProduct(tss_quat, offset_quat);

offset_quat gets set during the TareSensor function that is called when initially creating a device in the UDK integration. Therefore to get this to work we will have to get the tare function working. Could you please let me know how I can assign a function to a keybind in the python script so I can debug this please?

[CyberVillain]

You want to call a method on the plugin global?
just do yei[0].method()

I think we should let RoadKillGrill look at the github code and he can take the correct actions...

[baggyg]

You want to call a method on the plugin global?
just do yei[0].method()

I think we should let RoadKillGrill look at the github code and he can take the correct actions...

Thanks I was being dumb again and using

Code: Select all

keyboard.setKey(Key.Q,yei[0].tareSensor())

instead of

Code: Select all

if keyboard.getKeyDown(Key.Q) and keyboard.getPressed(Key.LeftShift):
    yei[0].tareSensor()

Yes hopefully RoadKillGrill can now pick this up and fix the issues.

[RoadKillGrill]

It might be at least 2 weeks until I get a chance to work on this, sorry for all the delays. I will at Sensors Expo in Chicago next week.

[baggyg]

It might be at least 2 weeks until I get a chance to work on this, sorry for all the delays. I will at Sensors Expo in Chicago next week.

Damn, OK. Is there anything you can briefly advise or direction I should be looking to try and get the update method working correctly (I.e pitch not reversed when 180 degrees from start / tare point)?

Currently the tss_getTaredOrientationAsQuaternion((uint)deviceId, quat, out timestamp); without using the tareSensor function at all (so no offsetQuat) is put through this method to return the yaw, pitch and roll.

Code: Select all

        public void Udate(double w, double x, double y, double z)
        {
            // normalize the vector
            double len = Math.Sqrt((w * w) + (x * x) + (y * y) + (z * z));
            w /= len;
            x /= len;
            y /= len;
            z /= len;

            // The Freespace quaternion gives the rotation in terms of
            // rotating the world around the object. We take the conjugate to
            // get the rotation in the object's reference frame.
            w = w;
            x = -x;
            y = -y;
            z = -z;

            // Convert to angles in radians
            double m11 = (2.0f * w * w) + (2.0f * x * x) - 1.0f;
            double m12 = (2.0f * x * y) + (2.0f * w * z);
            double m13 = (2.0f * x * z) - (2.0f * w * y);
            double m23 = (2.0f * y * z) + (2.0f * w * x);
            double m33 = (2.0f * w * w) + (2.0f * z * z) - 1.0f;

            Roll = Math.Atan2(m23, m33);
            Pitch = Math.Asin(-m13);
            Yaw = Math.Atan2(m12, m11);
        }

[baggyg]

Dont Worry @RoadKillGrill,

Figured it out. Cyber on the FreePIE.Core.Plugins.SensorFusion.Quaternion Udate() function you do not need take the conjugate (as you were doing with Freespace).

If you remove the following lines

Code: Select all

// The Freespace quaternion gives the rotation in terms of
// rotating the world around the object. We take the conjugate to
// get the rotation in the object's reference frame.
w = w;
x = -x;
y = -y;
z = -z;

Everything is now working perfectly!!!!!!

How would you prefer to branch this? Shall I do a overload function for when the YEI API is calling it (see below) or would you prefer a totally different class. Let me know and Ill send you my latest version including wireless sensor, updated comports array, new Udate method (when you tell me what to do with the above) and I am pretty close to getting the streaming working.

Code: Select all

        public void Udate(double w, double x, double y, double z, bool conjugate)
        {
            // normalize the vector
            double len = Math.Sqrt((w * w) + (x * x) + (y * y) + (z * z));
            w /= len;
            x /= len;
            y /= len;
            z /= len;

            // The Freespace quaternion gives the rotation in terms of
            // rotating the world around the object. We take the conjugate to
            // get the rotation in the object's reference frame.
            if (conjugate)
            {
                w = w;
                x = -x;
                y = -y;
                z = -z;
            }

            // Convert to angles in radians
            double m11 = (2.0f * w * w) + (2.0f * x * x) - 1.0f;
            double m12 = (2.0f * x * y) + (2.0f * w * z);
            double m13 = (2.0f * x * z) - (2.0f * w * y);
            double m23 = (2.0f * y * z) + (2.0f * w * x);
            double m33 = (2.0f * w * w) + (2.0f * z * z) - 1.0f;

            Roll = Math.Atan2(m23, m33);
            Pitch = Math.Asin(-m13);
            Yaw = Math.Atan2(m12, m11);
        }
        
        public void Udate(double w, double x, double y, double z)
        {
            Udate(w, x, y, z, true);
        }

[baggyg]

P.s.
You can use the following to have a nice smooth 360 movement (without the jump)

Code: Select all

        yaw = yei[0].yaw
   	pitch = yei[0].pitch
   	deltaYaw = filters.delta(yaw)
   	deltaPitch = -filters.delta(pitch)   
   	if math.fabs(deltaYaw) >= math.pi:
   		deltaYaw = 0
   	#MouseLook
	mouse.deltaX = deltaYaw*g_YEIMultiplier
	mouse.deltaY = deltaPitch*g_YEIMultiplier

[baggyg]

Update: Streaming method done and tested!
Removed tare method completely as it wasn't right and also removed those Quat and Vector classes - Ill leave this for when RoadKillGrill is back or I have a flash of inspiration.
Just tidying up and ill send over complete clean version later tonight.

[CyberVillain]

I that was just some cut and paste error when I stole that quaternion code from the freespace code.
I removed it, all that will happen is that people using the Android plugin will have to change the sign of their scripts

[baggyg]

I that was just some cut and paste error when I stole that quaternion code from the freespace code.
I removed it, all that will happen is that people using the Android plugin will have to change the sign of their scripts

Someone will have to check but I don't think this is the case. If it was then presumably I would just have to reverse the signs for the YEI pitch, yaw and that is definitely not the case.

Sending over scripts in about 15 mins

[CyberVillain]

I just removed that code and android works fine

[baggyg]

FreePIE.Core.Plugins.rar

OK, sorry for delay, had another marshalling issue (I think) with the streaming that was causing VS debugger to crash. Figured this out and streaming works through VS2012 but every time I run through a built version it crashes.

Check out the new Update function is combination with getLastStreamData and the new TssStreamPacket struct. Any thoughts on why its crashing as a binary would be greatly appreciated.

I have therefore set it so that upon initially connecting streaming is not turned on (and added two functions for starting and stopping it). The polling method works great though. I have also added the code for wireless sensors but have not been able to test this.

I have overloaded the Udate method in Quaternon as it was easy to do and wont then break everyones android scripts.

Test Script

Code: Select all

def update():
	diagnostics.watch(yei[0].yaw);
	diagnostics.watch(yei[0].pitch);
	diagnostics.watch(yei[0].roll);	
	
	yaw = yei[0].yaw
   	pitch = yei[0].pitch
   	deltaYaw = filters.delta(yaw)
   	deltaPitch = -filters.delta(pitch)   
   	if math.fabs(deltaYaw) >= math.pi:
   		deltaYaw = 0
   	
   	#MouseLook
	mouse.deltaX = deltaYaw*g_YEIMultiplier
	mouse.deltaY = deltaPitch*g_YEIMultiplier
		
if starting:
	#USB Version with cable at back. 
	#Default Axis Properties: X: Forward, Y: Right, Z: Up
	g_YEIMultiplier = 500
	yei[0].update += update
	
if keyboard.getKeyDown(Key.Q):
	yei[0].stopStreaming()
if keyboard.getKeyDown(Key.W):
	yei[0].startStreaming()

[CyberVillain]

Udate was a misspelling of Update
Fixed that in my branch

Will look at your code to see if I can figure out whats wrong

edit: can you please use Github instead? way easier for me to track whats changed between updates etc

[baggyg]

Udate was a misspelling of Update
Fixed that in my branch

Will look at your code to see if I can figure out whats wrong

edit: can you please use Github instead? way easier for me to track whats changed between updates etc

OK, not had much experience with Github but ill sign up and post there. Do you want me to put my work in a separate branch or update the existing YEI one?
EDIT:
OK forked your repo and added my changes to the YEI3-Space here:
https://github.com/baggyg/FreePIE/tree/YEI3-Space
Can you compare, do a pull request from there or do I need to do a pull request?

[CyberVillain]

Udate was a misspelling of Update
Fixed that in my branch

Will look at your code to see if I can figure out whats wrong

edit: can you please use Github instead? way easier for me to track whats changed between updates etc

OK, not had much experience with Github but ill sign up and post there. Do you want me to put my work in a separate branch or update the existing YEI one?
EDIT:
OK forked your repo and added my changes to the YEI3-Space here:
https://github.com/baggyg/FreePIE/tree/YEI3-Space
Can you compare, do a pull request from there or do I need to do a pull request?

Nice work!
I'm super busy today at work and an after work tonight, so might not have time to look at it and pull it to my branch.
I looked at it superfast and there are some naming standars that looks more like C than C#. No biggies.
Another thing that that should be fixed is to move the stop and start streaming into the plugin, we want to keep the globals as simple as possible so that none programmers can use FreePIE, stop and start can be called from start and stop on the plugin for example.

[baggyg]

Nice work!
I'm super busy today at work and an after work tonight, so might not have time to look at it and pull it to my branch.
I looked at it superfast and there are some naming standars that looks more like C than C#. No biggies.
Another thing that that should be fixed is to move the stop and start streaming into the plugin, we want to keep the globals as simple as possible so that none programmers can use FreePIE, stop and start can be called from start and stop on the plugin for example.

Thanks did a couple of commits to things I missed when porting my code across. Now runs through VS2012 debugger fine (with streaming as well). Forgot to send you the error message when it crashes from the built version when turning on streaming

Problem signature:
Problem Event Name: APPCRASH
Application Name: FreePIE.exe
Application Version: 0.6.324.0
Application Timestamp: 51a77a18
Fault Module Name: ThreeSpace_API.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 51953785
Exception Code: c0000005
Exception Offset: 000025b0
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057

By the coding standards I presume you mean sensor_type as opposed to sensorType?

To be honest I'll let you have a look when you have time and pull across anything you think is right before I make any more changes and then ill see where you have put things. Let me know if I can be of any assistance.

I'm now having a hugely annoying problem in that when I now build a version it works fine on my development machine but when I pull it across to my gaming machine to test it crashes when trying to run any script (not just YEI related) with the following error:

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: freepie.exe
Problem Signature 02: 0.6.324.0
Problem Signature 03: 51a77a18
Problem Signature 04: FreePIE.Core
Problem Signature 05: 0.6.324.0
Problem Signature 06: 51a72854
Problem Signature 07: 136
Problem Signature 08: e
Problem Signature 09: System.IO.FileNotFoundException
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 2057

Annoying as I thought I at least had a version I could try out on a few games. If you have an incline what I am doing wrong it would be hugely appreciated! Perhaps I'm just not building it right.

[CyberVillain]

Can you please check the windows event viewer if you have any details on the error?

[baggyg]

Can you please check the windows event viewer if you have any details on the error?

Good advice.
Regarding the issue of streaming when built it has the following go wrong:

Application: FreePIE.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
at FreePIE.Core.Plugins.Yei3Space.Api.tss_getLastStreamData(Int32, FreePIE.Core.Plugins.Yei3Space.TssStreamPacket ByRef, Int32)
at FreePIE.Core.Plugins.Yei3Space.Api.UpdateQuaternion(Int32, FreePIE.Core.Plugins.SensorFusion.Quaternion)
at FreePIE.Core.Plugins.Yei3SpaceGlobalHolder.Update()

Odd one. To be clear I test the binary in the following way:
From the build menu, I click "Rebuild". I then run the program from the bin/debug folder (or drag the contents somewhere else) and then run FreePie.exe.

I am not sure why this occurs when I run it as a binary but not when I run it through CS debugger.

I will repeat with my other problem (on a different machine and report back).

[baggyg]

Don't worry about the other issue...
I was getting this

Application: FreePIE.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
Stack:
at FreePIE.Core.ScriptEngine.Python.PythonScriptEngine.TriggerErrorEventNotOnPythonThread(System.Exception)
at FreePIE.Core.ScriptEngine.Python.PythonScriptEngine.ExecuteSafe(System.Action)
at FreePIE.Core.ScriptEngine.Python.PythonScriptEngine+<>c__DisplayClass6.<Start>b__1(System.Object)

I installed IronPython on my other machine and now working again. Presume this was just the way I was distributing rather than building an install that would have put in this dependency (or similar).

Good News is I can now test on a few games using the regular method. regarding streaming I think this is probably a marshalling issue. Let me know if there is anything I can try this end.

[CyberVillain]

Yes, its probably something unmanaged thats overwriting memory in CLR land (.NET). We had a smilar problem with lua thats why we changed to python. It too worked better when the debubger was attached for some reason.
Im super busy this weekend ill try to find time to look at it

Strange with python, im copying all dependencies when you build (similar to what the installer does).

[baggyg]

Yes, its probably something unmanaged thats overwriting memory in CLR land (.NET). We had a smilar problem with lua thats why we changed to python. It too worked better when the debubger was attached for some reason.
Im super busy this weekend ill try to find time to look at it

Strange with python, im copying all dependencies when you build (similar to what the installer does).

yeah odd with the dependencies but dont worry about it - all sorted.

Managed to spend a weekend with a working version to do some testing. All in all things are shaping up nicely, thanks for support during this process!

First thing I noticed is that the axis for yaw, pitch and roll are in the scale of -pi to pi. Although this doesn't hugely matter it made more sense to have these in the same range as trackIR or similar in degrees. Therefore in the python I used

Code: Select all

yaw = ((yei[0].yaw / math.pi) * 180);
pitch = ((yei[0].pitch / math.pi) * 180);
roll = ((yei[0].roll / math.pi) * 180);

to get a -180 to 180 degree reading represent a complete circle. It may be worth doing this in the Api for consistency sake.

Tests:
Linking with Vireio Perception

Code: Select all

def update():
	yaw = ((yei[0].yaw / math.pi) * 180);
	pitch = ((yei[0].pitch / math.pi) * 180);
	roll = ((yei[0].roll / math.pi) * 180);
	vireioSMT.yaw = yaw
	vireioSMT.pitch = pitch
	vireioSMT.roll = roll
if starting:
	yei[0].update += update

This works pretty much perfectly

TrackIR

Code: Select all

def update():
	yaw = ((yei[0].yaw / math.pi) * 180)
	pitch = ((yei[0].pitch / math.pi) * 180)
	roll = ((yei[0].roll / math.pi) * 180)
	trackIR.yaw = yaw*g_YEIMultiplier
	trackIR.pitch = pitch*g_YEIMultiplier
	trackIR.roll = roll*g_YEIMultiplier
if starting:
	yei[0].update += update
	g_YEIMultiplier = 1

Again working great!

Mouse Emulation
This one is giving me some problems

Code: Select all

def update():
	
	yaw = ((yei[0].yaw / math.pi) * 180);
	pitch = ((yei[0].pitch / math.pi) * 180);
   	deltaYaw = filters.delta(yaw)
   	deltaPitch = filters.delta(pitch)   
   	if math.fabs(deltaYaw) >= math.pi:
   		deltaYaw = 0   	
   	#MouseLook
	mouse.deltaX = deltaYaw*g_YEIMultiplier
	mouse.deltaY = deltaPitch*g_YEIMultiplier
		
if starting:
	g_YEIMultiplier = 1
	game = "bioshock"
	if game == "bioshock":
		g_YEIMultiplier = 14
	if game == "halflifevr":
		g_YEIMultiplier = 10
	if game == "zombiehd":
		g_YEIMultiplier = 5		
	yei[0].update += update

The actually tracking works fine but I found that there is an apparent deadzone which becomes quite annoying. Once you stop moving your head the mouse stops dead. Then to get it moving again requires you move the sensor quite a bit. Using the diagnostics I was able to see the sensor was giving changes to the yaw but these never resulted in a delta change. (In fact a one point the yaw was drifting due to the compass reading. It went through around 5 degrees of movement but no change in deltax at all).

I tried a few things to stop this... such as increasing the yaw by several multitudes and although this reduced the amount of movement necessary to move the mouse again but the deadzone effect was still apparent 9and the games became unplayable due to the sensitivity). I presume since I don't get this effect using the perception or trackIR scripts it must be the way I am achieving the mouse movement using the delta filters. At the moment this is my primary focus and will try some different things this week (maybe trying mapping yaw ptich directly to mouse.x and mouse.y to get an absolute mapping). Any hints or ideas you may have about this please let me know, they will be most appreciated.

General Notes:
> We will definitely need to get the tare function working as it becomes a pain to do this through the suite (I.e. stop script / connect through suite / tare / disconnect / start script again). I will have another look at this this week. Even without the offset it would be useful.
> Mounting on a Hmz-t1 I found I had to put this at the point of rotation (I.e. the top of my head). Mounting on the front gave a strange offset meaning looking left / right actually dipped and rolled the view as well. Not too much of an issue - I perverted one of the missus hair bands to mount the sensor on so I look like a pretty girl wearing at as well

[CyberVillain]

hehe, yeah we do not look pretty wearing our nerd hats

Currently we do not have a standard in FreePIE, we use the sensors default output, so radians in some cases and degrees in others. This can make sense, but in most cases It does not Most sensors output in degrees, Android, Yei and now Carl zeiss outputs in radians. Problem with changing now is that we break people scipts.

Anyway, you can use pythons mathlib to convert, math.degrees

Strange with the mouse emu, maybe you experience what others have experienced, when they go from -180 to +180 you get a huge delta (360 degrees) this will make the mouse emulation go crazy and send away the viewport way off

[baggyg]

hehe, yeah we do not look pretty wearing our nerd hats

Currently we do not have a standard in FreePIE, we use the sensors default output, so radians in some cases and degrees in others. This can make sense, but in most cases It does not Most sensors output in degrees, Android, Yei and now Carl zeiss outputs in radians. Problem with changing now is that we break people scipts.

Anyway, you can use pythons mathlib to convert, math.degrees

Strange with the mouse emu, maybe you experience what others have experienced, when they go from -180 to +180 you get a huge delta (360 degrees) this will make the mouse emulation go crazy and send away the viewport way off

OK re the standard. I wasn't suggest we change all existing. Not a big issue anyway as long as people are aware. Thanks for math.degrees - thats a bit cleaner than mine.

RE: The mouse emu - no unfortunately its not as simple as that - as you can see I am already handling that with

Code: Select all

if math.fabs(deltaYaw) >= math.pi:
         deltaYaw = 0     

which gets rid of the jump.

The best way I can describe it is a a quite large dead zone. You move your head and the mouse moves exactly as expected. When you stop it stops dead. Small changes in axis directions are not picked up until quite a pronounced movement when it starts moving again. I had a look at the filters and it is doing what I thought; comparing to the last position and returning the change.

Just had a little play and its definitely to do with the speed of the movement. If I move very slowly I can actually move through 90 degrees without making the mouse move at all. FreePIE is correctly reporting the yaw so I guess what is happening is that the change is just too small through the delta filter and being ignored. Perhaps the YEI sensor is just too damn fast!

Ill have a think and let you know what I come up with...

EDIT: Watching all the values I can see that deltaX for example is mostly around 0.001xxxxxx during these small changes. Therefore always gets ignored. If I increase the multiple enough I can remove the deadzone completely but then the mouse is too sensitive. So from here I guess I need to either do some sort of smoothing algorithm to pick up the small changes but decrease the overall sensitivity. Alternatively I guess I could save these small changes in delta and clear when it results in a change of mouse position.

[CyberVillain]

I see that the Update method in Api.cs uses a float array, doubles have higher precision, you can try to change that to a double, dont know if that will marshal correctly or if it will help if the C code uses a 4 byte float

what happens if you do the delta after your multiply with your g_YEIMultiplier?

[baggyg]

I see that the Update method in Api.cs uses a float array, doubles have higher precision, you can try to change that to a double, dont know if that will marshal correctly or if it will help if the C code uses a 4 byte float

I presume this is to try and fix the streaming? Changing any of the calls to doubles do not return the correct values.
Even the non streaming version:

Code: Select all

[DllImport("ThreeSpace_API.dll", CallingConvention = CallingConvention.Cdecl)]
private static extern TssError tss_getTaredOrientationAsQuaternion(uint deviceId, double[] quat,out uint timestamp);

returns some data but it is not correct.

what happens if you do the delta after your multiply with your g_YEIMultiplier?

It does not matter since the precision is kept right up until the point when you call

Code: Select all

mouse.deltaX = deltaYaw
mouse.deltaY = deltaPitch

Where it then takes the integer value of deltaYaw / deltaPitch so anything in the range -0.5 < r < 0.5 is discarded. If I do something like

Code: Select all

if deltaYaw > 0.2 and deltaYaw < 0.5:
	deltaYaw = 1
if deltaPitch > 0.2 and deltaPitch < 0.5:
	deltaPitch = 1
if deltaYaw < -0.2 and deltaYaw > -0.5:
	deltaYaw = -1
if deltaPitch < -0.2 and deltaPitch > -0.5:
	deltaPitch = -1

where these smaller movements are taken into account without affecting the overall sensitivity. I can almost balance it to when it feels "right" but its not ideal. I think keeping these values until later is a better method (I.e. 3 movements of 0.2 = 1 pixel move in the mouse). I'm just trying to get this working at the moment.

[baggyg]

EDIT: Updated script below - fixed couple of small issues and now allows for consistent sensitivity (multiplier).

Deadzone Problem solved!

Storing delta until they were big enough worked great.

Code: Select all

def update():
	global offsetYaw, offsetPitch, multiplier
	yaw = math.degrees(yei[0].yaw)
	pitch = math.degrees(yei[0].pitch)
	deltaYaw = filters.delta(yaw)
	deltaPitch = filters.delta(pitch)
	#This is just saying if it suddenly jumps ignore it. 
	if math.fabs(deltaYaw) >= math.pi:
		deltaYaw = 0
	#If the yaw movement is too small to move the mouse save the value
	if (deltaYaw * multiplier) < 0.5 and (deltaYaw * multiplier) > -0.5:
		offsetYaw = (deltaYaw*multiplier) + offsetYaw
	else: 
		#otherwise the movement is gonna register anyway so just add on whatever we were saving
		deltaYaw = deltaYaw + (offsetYaw/multiplier)
		offsetYaw = 0 
	
	#If the pitch movement is too small to move the mouse save the value
	if (deltaPitch * multiplier) < 0.5 and (deltaPitch * multiplier) > -0.5:
		offsetPitch = (deltaPitch*multiplier) + offsetPitch
	else:
		#otherwise the movement is gonna register anyway so just add on whatever we were saving
		deltaPitch = deltaPitch + (offsetPitch/multiplier)
		offsetPitch = 0	
				
	#If the saved movement is now big enough apply it (note we can replace delta value since this was already added above)
	if (offsetPitch > 0.5 or offsetPitch < -0.5):
		deltaPitch = offsetPitch
		offsetPitch = 0
	else: 
		deltaPitch = deltaPitch*multiplier
	
	if (offsetYaw > 0.5 or offsetYaw < -0.5):
		deltaYaw = offsetYaw
		offsetYaw = 0		
	else:
		deltaYaw = deltaYaw*multiplier	
		
	mouse.deltaX = deltaYaw
	mouse.deltaY = deltaPitch
	
if starting:
	#USB Version with cable at back. 
	#Default Axis Properties: X: Forward, Y: Right, Z: Up (- minus both axis above)	
	offsetYaw = 0
	offsetPitch = 0	
	multiplier = 4
	game = "none"
	if game == "bioshock":
		multiplier = 2
	if game == "halflifevr":
		multiplier = 2
	if game == "zombiehd":
		multiplier = 1.5		
	yei[0].update += update	

[CyberVillain]

So what you in reality do is slowing down the output from FreePIE, sounds not ideal. Must be a problem somewhere.
I haven't written the mouse plugin so need to look in to that, but I have used it with the android plugin, Ardiono plugin etc without problem

[baggyg]

So what you in reality do is slowing down the output from FreePIE, sounds not ideal. Must be a problem somewhere.
I haven't written the mouse plugin so need to look in to that, but I have used it with the android plugin, Ardiono plugin etc without problem

Hi Cyber,
I don't quite agree with what you are saying. I am not slowing down the output from freePIE. The mouse.deltas are updated every cycle as per normal. What is currently happening is that the minimum value that can be passed to mouse.deltaX/Y is > 0.5 which gets converted to 1 (I believe). I.e. a 1 pixel movement in any direction.

Currently a slow small movement is under this threshold. The old script had it so that these small changes were lost. You could argue that I should multiply these values so that they show but this results in a hugely sensitive mouse, certainly too high for a one-to-one movement in a game.

With the new script what I am doing is saving the values (which would have been ignored) until which point they become significant and then applying the result. However none of this affects the "speed" at which freePIE is running and regular movement is treated normally.

NOTE: I am improving the script at the moment as it had a few little quirks so will edit my post when finished.

You are correct that this is far from ideal. The underlying issue is that the values passed to mouse.deltaX/Y are integers and not precise. It would be better if you could pass a float / double and for the system to know that the mouse position is at 1065.456119 pixels from the top for example (of course it cant draw this but could still render to the nearest pixel) at which point a small change would force it to move to the next. This may well be very possible, I have also not investigated into improving the mouse plugin.

[baggyg]

Hi, me again
Updated the script I posted earlier. This one has comments etc.

Think this is now 100%.

All I am really doing is what should be handled in the mouse plugin. If you like you can test this using any other input (I.e. android, trackIR) and I contend that the only thing that will be affected is it will make the tracking slightly more accurate . I am of course ready to be proved wrong but just had a go on BioShock and this has turned an unplayable experience (with previous script) into something close to the smoothness of the Perception / trackIR plugin.

[CyberVillain]

Well you are buffering the delta which does slow down the output from FreePIE, but maybe thats the only way, I will see if the lower level apis used can use doubles or if buffering is the only way.