Razer hydra emulation
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Well the problem is not to get it initialized and sending data, the problem is to get it calibrated. But hes working on it. But its a drifty device compared to the Oculus or even my Android phone
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
-
- Cross Eyed!
- Posts: 140
- Joined: Wed Feb 04, 2009 7:51 am
Re: Razer hydra emulation
Hi Vyber,
I've already rebuilt it for myself but for the benefit of other could you upload the 64bit fixed version too.
I want to try and play around with the PS Move controller next . Should I be able to use my Imu to emulate one hydra while using a PS Move to emulate the second?
Matt.
I've already rebuilt it for myself but for the benefit of other could you upload the 64bit fixed version too.
I want to try and play around with the PS Move controller next . Should I be able to use my Imu to emulate one hydra while using a PS Move to emulate the second?
Matt.
- nateight
- Sharp Eyed Eagle!
- Posts: 404
- Joined: Wed Feb 27, 2013 10:33 pm
- Location: Youngstown, OH
Re: Razer hydra emulation
Oh yeah. Even with the addition of gyros they're all over the place. But that's what the IR system is for? I'm really hoping FreePIE will give us access to all the information from the IR camera; most libraries seem to think tracking four IR dots is enough, and it often isn't.CyberVillain wrote:[Wiimotes are] a drifty device compared to the Oculus or even my Android phone
I'd love to toss the Wii stuff out entirely and just use a Hydra forever, but Wiimotes (not to mention Balance Boards) fill a certain niche that Hydras can't. If I ever get WiiYourself! properly imported into a game engine and/or FreePIE bridges the gap between Wiimotes and a modern game engine, I'll have some very interesting stuff to share.
Back to work!
Shameless plug of the day - Read my witty comments on Reddit, in which I argue with the ignorant, over things that don't matter, for reasons I never fully understood!
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Yupp, I will fix x64 tooCroccy22 wrote:Hi Vyber,
I've already rebuilt it for myself but for the benefit of other could you upload the 64bit fixed version too.
I want to try and play around with the PS Move controller next . Should I be able to use my Imu to emulate one hydra while using a PS Move to emulate the second?
Matt.
Yes but first you have to create a PS Move plugin because FreePIE does not have support for that.
IR might not make it to the first version, but the data is available in the Raw data so its possible to extract it and add support for it.nateight wrote: Oh yeah. Even with the addition of gyros they're all over the place. But that's what the IR system is for? I'm really hoping FreePIE will give us access to all the information from the IR camera; most libraries seem to think tracking four IR dots is enough, and it often isn't.
I'd love to toss the Wii stuff out entirely and just use a Hydra forever, but Wiimotes (not to mention Balance Boards) fill a certain niche that Hydras can't. If I ever get WiiYourself! properly imported into a game engine and/or FreePIE bridges the gap between Wiimotes and a modern game engine, I'll have some very interesting stuff to share.
Back to work!
-
- Cross Eyed!
- Posts: 140
- Joined: Wed Feb 04, 2009 7:51 am
Re: Razer hydra emulation
Wasn't there something you could do to get the psmove working with freetack or something? I thought I read that somewhere.
Matt.
Matt.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Havent heared anything about that sorry, but you can ask for a progress report in this thread
http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15199
http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=15199
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
Yo CyberVillain, I am experimenting with Razer Hydra emulation using FreePIE 1.2.375 and I have a question for you.
It's not clear to me if this version has the code updates you've performed to the FreePIE.Core.Plugins.dll that are available in this thread.
I'm running into the following issue when I try to assign to the hydra object from a script using FreePIE 1.2.375:
I presume this is because this version of the FreePIE.Core.Plugins.dll included with FreePIE 1.2.375 has a read-only form of the Hydra plugin?
Here's what I'm trying to do and these are the lines that cause the error (this is just an excerpt of the script--yaw, pitch and roll are globals):
It's not clear to me if this version has the code updates you've performed to the FreePIE.Core.Plugins.dll that are available in this thread.
I'm running into the following issue when I try to assign to the hydra object from a script using FreePIE 1.2.375:
This would seem to indicate it is a read-only interface.23: can't assign to read-only property trigger of type 'HydraPluginGlobal'
I presume this is because this version of the FreePIE.Core.Plugins.dll included with FreePIE 1.2.375 has a read-only form of the Hydra plugin?
Here's what I'm trying to do and these are the lines that cause the error (this is just an excerpt of the script--yaw, pitch and roll are globals):
Code: Select all
hydra[1].yaw = yaw
hydra[1].pitch = pitch
hydra[1].roll = roll
Last edited by kzoink on Tue Sep 10, 2013 10:20 pm, edited 1 time in total.
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
Well, shoot, looks like I have to get my hands dirty again.
So, digging into the code, I have confirmed that the HydraPluginGlobal in the 1.2.375 release is a read-only interface.
However, the HydraEmulation branch on GitHub contains all the code to make this interface capable of writing to a fake Hydra.
https://github.com/AndersMalmgren/FreeP ... aEmulation
I'm going to do my own little merge since using CyberVillain's provided FreePIE.Core.Plugins.DLL from this thread is not working with 1.2.375--FreePIE fails to start.
So, digging into the code, I have confirmed that the HydraPluginGlobal in the 1.2.375 release is a read-only interface.
However, the HydraEmulation branch on GitHub contains all the code to make this interface capable of writing to a fake Hydra.
https://github.com/AndersMalmgren/FreeP ... aEmulation
I'm going to do my own little merge since using CyberVillain's provided FreePIE.Core.Plugins.DLL from this thread is not working with 1.2.375--FreePIE fails to start.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
I'm super sorry that I wasnt clearer about that this was not out in the installer version.
Cant you just build the Branch and use that until we have a new installer out?
Cant you just build the Branch and use that until we have a new installer out?
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
No worries, Cyber! Digging into the code was educational.
So, I merged the changes into my source and I am up and running with Hydra emulation!
I discovered a bug, however.
Using this simple script to emulate a Hydra through the latest sixense_fake.dll WITH an actual Hydra:
In the Sixense Tuscany demo, if I roll the Hydra controller +/- more than 90 degrees, immediately the orientation of the Hydra hands flips 180 degrees and the rotations are then in the wrong direction, opposite to the actual controller rotation.
I have confirmed that this does not occur when the Hydra is being used directly with the original sixense.dll.
CyberVillain, can you take a look at your code to see what might be going on to cause this?
So, I merged the changes into my source and I am up and running with Hydra emulation!
I discovered a bug, however.
Using this simple script to emulate a Hydra through the latest sixense_fake.dll WITH an actual Hydra:
Code: Select all
hydra[1].x = hydra[1].x
hydra[1].y = hydra[1].y
hydra[1].z = hydra[1].z
hydra[1].yaw = hydra[1].yaw
hydra[1].pitch = hydra[1].pitch
hydra[1].roll = hydra[1].roll
I have confirmed that this does not occur when the Hydra is being used directly with the original sixense.dll.
CyberVillain, can you take a look at your code to see what might be going on to cause this?
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Strange
I must admit that I'm not an expert on eualer/quaternion math
The code of interest is here, let me know if you find anything obvious
https://github.com/AndersMalmgren/FreeP ... ke.cpp#L80
I must admit that I'm not an expert on eualer/quaternion math
The code of interest is here, let me know if you find anything obvious
https://github.com/AndersMalmgren/FreeP ... ke.cpp#L80
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
Hi CyberVillain,
I'm no expert in the maths either, as those memories have long faded, but hopefully between the two of us we can get to the bottom of this.
Question: can you give me an idea of the flow of the pertinent data in FreePIE and any math operations / conversions performed from start to finish when using the simple Hydra->Hydra script I posted above? I have a rough idea but if you could spell it out for me that would be great.
Could this have anything to do with hemisphere tracking?
http://sixense.com/dev/Sixense_SDK_Reference_1026.pdf
Note that I was not passing below the base unit with my Hydra controller when I observed the errant behavior (I was just rotating on the roll axis), but there might be some interaction here with the automatic hemisphere tracking in the SDK which may be causing the flip I described. What do you think?
Thanks for your work on this, by the way! It's great with the exception of this little bug which we can hopefully squash.
I'm no expert in the maths either, as those memories have long faded, but hopefully between the two of us we can get to the bottom of this.
Question: can you give me an idea of the flow of the pertinent data in FreePIE and any math operations / conversions performed from start to finish when using the simple Hydra->Hydra script I posted above? I have a rough idea but if you could spell it out for me that would be great.
Could this have anything to do with hemisphere tracking?
SourceThe current DevKits will only consistently track positions when the controller is held above the base unit. When passing below the base unit, an inconsistency in the positions and rotations will be seen. The inconsistency will be that the X and Y values will flip sign, the Z value will begin increasing instead of decreasing, and the rotation matrix will flip by 180 degrees.
This behavior can be avoided by calling sixenseSetHemisphereTrackingMode. The caveat, however, is that this call must be made when the controller is actively tracking and is in a position above the base unit. If it is called when the controller is below the base unit when the position values are flipped, then the values will remain flipped when the controller passes above the base unit.
The hemisphere behavior will be addressed in future revisions of the DevKit.
http://sixense.com/dev/Sixense_SDK_Reference_1026.pdf
Note that I was not passing below the base unit with my Hydra controller when I observed the errant behavior (I was just rotating on the roll axis), but there might be some interaction here with the automatic hemisphere tracking in the SDK which may be causing the flip I described. What do you think?
Thanks for your work on this, by the way! It's great with the exception of this little bug which we can hopefully squash.
Last edited by kzoink on Thu Sep 12, 2013 1:00 pm, edited 2 times in total.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Your real razer hydras rotation is converted by freepie to euler angles, the euler angels are sent to the fake dll
In the fake dll those euler angles are converted into quaternion rotation and a rotation matrix. The game can choose to use the matrix or the quat.
I would start with observing the the values from the real hydra i.e
diagnostics.watch(hydra[0].yaw) etc
Does that look good?
In the fake dll those euler angles are converted into quaternion rotation and a rotation matrix. The game can choose to use the matrix or the quat.
I would start with observing the the values from the real hydra i.e
diagnostics.watch(hydra[0].yaw) etc
Does that look good?
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
Yeah, the data from the real Hydra shown in the diagnostics appears to be good in my cursory observations. Proper signs and ranges of values are observed for each axis of rotation as I rotate on each axis individually.
Any thoughts on the hemisphere tracking being the culprit?
Any thoughts on the hemisphere tracking being the culprit?
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Well, your real hydra wont receive those calibration commands so maybe thats has something todo with it, have you tried to emulate using a Android or other tracker?
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I have, and the same problem is evident even with the other tracker while using Hydra emulation, so I am pretty sure the problem lies in the sixense_fake.dll.
It may be in the Euler->Quaternion/Matrix math like you suspected, but I'm not sure yet.
One thing that makes me skeptical about the hemisphere tracking being the culprit is that the X,Y,Z position values are not flipped when I observe the errant behavior. Only the rotations are flipped. And I'm not changing hemispheres when I do it--I'm simply rotating the controller on the roll axis while above the Hydra.
I was just looking at the code for sixense_fake.dll and I saw this:
The pointer, *state, is not modified in any way. Perhaps we should provide a value here to indicate to the caller that it is off, since we aren't turning it on.
From SDK documentation:
state - Pointer to variable filled with the current hemisphere tracking mode.
state - The desired state of the tracking mode. 0 is off, 1 is on.
It may be in the Euler->Quaternion/Matrix math like you suspected, but I'm not sure yet.
One thing that makes me skeptical about the hemisphere tracking being the culprit is that the X,Y,Z position values are not flipped when I observe the errant behavior. Only the rotations are flipped. And I'm not changing hemispheres when I do it--I'm simply rotating the controller on the roll axis while above the Hydra.
I was just looking at the code for sixense_fake.dll and I saw this:
Code: Select all
SIXENSE_EXPORT int sixenseGetHemisphereTrackingMode( int which_controller, int *state )
{
return SIXENSE_SUCCESS;
}
From SDK documentation:
state - Pointer to variable filled with the current hemisphere tracking mode.
state - The desired state of the tracking mode. 0 is off, 1 is on.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Could try, dont have time to build the C library tonight. Do you have it up and running? Otherwise maybe I have some time this weekend
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I'm currently trying to get the DLL source into a project with the dependencies setup so I can build it.
Also, I found more info on the hemisphere tracking in the Sixense_SDK_Overview.pdf that comes with the SDK. I still can't rule it out 100%...
Also, I found more info on the hemisphere tracking in the Sixense_SDK_Overview.pdf that comes with the SDK. I still can't rule it out 100%...
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
So I got the sixense_fake.dll library source to build and started playing around with it. I made the changes to the sixenseGetHemisphereTrackingMode function that I proposed earlier and there was no noticeable effect.
However, after reexamining some assumptions I made earlier, I'm now closer to figuring this out.
CyberVillain, I think you were on the right track when you told me to reexamine the original data from the real Hydra as displayed in the FreePIE diagnostics.
I failed to point out that the roll axis is in the range of 0 to +/- 1/2pi radians. In other words, if you roll clockwise from 0 to 90 degrees, it increases to 1/2pi, then it starts decreasing back to 0 as you approach 180 degrees, then the sign flips and it starts decreasing to -1/2pi until it passes 270 degrees when it finally starts increasing back to 0. I thought this was normal since I was seeing this on 2 different devices. On the other device, though, it is the pitch that is in this range, while the other axes are in the 0 to +/- pi radians range. I think this is actually the heart of the problem. The range on the roll axis is only enough to uniquely represent 180 degrees, so the behavior I was seeing with the flipping and reversing of the rotation past +/- 90 degrees rotation is explained by this.
Here's what the ranges look like for the Hydra when monitoring via the FreePIE diagnostics:
Pitch & yaw axes:
0/360 degrees = 0 radians
90 degrees = 1/2pi radians
180 degrees = pi radians
270 degrees = -1/2pi radians
Roll axis:
0/360 degrees = 0 radians
90 degrees = 1/2pi radians
180 degrees = 0 radians
270 degrees = -1/2pi radians
Can you confirm that this should not be happening and/or provide additional insight?
brantlew who worked on the Hydra emulation also notes the same issue and has a demonstration video here.
I actually tried hooking up another device and mapping one of its axes which reports the full range of 0 to pi from 0 to 180 degrees +/-. I mapped its output to the Hydra roll axis and ran the SixenseTuscanyDemo to confirm this is the expected range. I was able to complete a 360 degree roll with this other device mapped to the roll axis while the Hydra itself took care of pitch and yaw.
However, after reexamining some assumptions I made earlier, I'm now closer to figuring this out.
CyberVillain, I think you were on the right track when you told me to reexamine the original data from the real Hydra as displayed in the FreePIE diagnostics.
I failed to point out that the roll axis is in the range of 0 to +/- 1/2pi radians. In other words, if you roll clockwise from 0 to 90 degrees, it increases to 1/2pi, then it starts decreasing back to 0 as you approach 180 degrees, then the sign flips and it starts decreasing to -1/2pi until it passes 270 degrees when it finally starts increasing back to 0. I thought this was normal since I was seeing this on 2 different devices. On the other device, though, it is the pitch that is in this range, while the other axes are in the 0 to +/- pi radians range. I think this is actually the heart of the problem. The range on the roll axis is only enough to uniquely represent 180 degrees, so the behavior I was seeing with the flipping and reversing of the rotation past +/- 90 degrees rotation is explained by this.
Here's what the ranges look like for the Hydra when monitoring via the FreePIE diagnostics:
Pitch & yaw axes:
0/360 degrees = 0 radians
90 degrees = 1/2pi radians
180 degrees = pi radians
270 degrees = -1/2pi radians
Roll axis:
0/360 degrees = 0 radians
90 degrees = 1/2pi radians
180 degrees = 0 radians
270 degrees = -1/2pi radians
Can you confirm that this should not be happening and/or provide additional insight?
brantlew who worked on the Hydra emulation also notes the same issue and has a demonstration video here.
I actually tried hooking up another device and mapping one of its axes which reports the full range of 0 to pi from 0 to 180 degrees +/-. I mapped its output to the Hydra roll axis and ran the SixenseTuscanyDemo to confirm this is the expected range. I was able to complete a 360 degree roll with this other device mapped to the roll axis while the Hydra itself took care of pitch and yaw.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
I have only been involved in the emulation part of the plugin, brantlew did the reading. But in the source he's writing
So maybe there is a problem with his quat > euler code?
Just so I understand, you have confirmed its a read problem and not emulation problem?
Have you checked out brantlew's quat > euler code?
https://github.com/AndersMalmgren/FreeP ... in.cs#L153
edit: hmm, come to think about it this is the exact same problem we had in the fake SDK. We solved it my inverting the rotation matrix
Code: Select all
// !!! Roll seems messed up. At +-90 degree roll it starts to roll back down to 0 and
// pitch simultaneously !!! I don't know if this is a bug with the Hydra or with the
// calculations of my Euler angles
Just so I understand, you have confirmed its a read problem and not emulation problem?
Have you checked out brantlew's quat > euler code?
https://github.com/AndersMalmgren/FreeP ... in.cs#L153
edit: hmm, come to think about it this is the exact same problem we had in the fake SDK. We solved it my inverting the rotation matrix
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I will check out brantlew's quat > Euler code next.CyberVillain wrote:I have only been involved in the emulation part of the plugin, brantlew did the reading. But in the source he's writing
So maybe there is a problem with his quat > euler code?Code: Select all
// !!! Roll seems messed up. At +-90 degree roll it starts to roll back down to 0 and // pitch simultaneously !!! I don't know if this is a bug with the Hydra or with the // calculations of my Euler angles
Just so I understand, you have confirmed its a read problem and not emulation problem?
Have you checked out brantlew's quat > euler code?
https://github.com/AndersMalmgren/FreeP ... in.cs#L153
edit: hmm, come to think about it this is the exact same problem we had in the fake SDK. We solved it my inverting the rotation matrix
That's correct--I no longer think it's a problem with sixense_fake.dll.
I think it is a bug in the quat > Euler code or some part of the chain thereafter and I also think both the plugin for my other device AND the Hydra plugin are suffering from this bug. Which is why I thought it was normal until I started re-examining my assumptions.
I'm almost 100% sure that this is the heart of the problem.
You know why I think this bug has gone mostly unnoticed for a while? Most people are using FreePIE for head orientation tracking, and you never roll your head past +/- 90 degrees.
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
Hmm, I just checked a THIRD device and I observed two axes that were in the range 0 to +/- pi from 0 to +/- 180 degrees while one axis was in the range 0 to +/- 1/2pi from 0 to +/- 90 degrees and returning to 0 after 90 degrees just like above.
Is this normal?
This time I was using FreePIE for Android and watching the orientation values after checking the "Debug" checkbox.
When you say you inverted the rotation matrix to solve a similar issue, when/where in the process do you invert the rotation matrix?
Is this normal?
This time I was using FreePIE for Android and watching the orientation values after checking the "Debug" checkbox.
When you say you inverted the rotation matrix to solve a similar issue, when/where in the process do you invert the rotation matrix?
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Most devices has its own range, so you might have to convert the range into something that the fake dll can use correctlykzoink wrote:Hmm, I just checked a THIRD device and I observed two axes that were in the range 0 to +/- pi from 0 to +/- 180 degrees while one axis was in the range 0 to +/- 1/2pi from 0 to +/- 90 degrees and returning to 0 after 90 degrees just like above.
Is this normal?
This time I was using FreePIE for Android and watching the orientation values after checking the "Debug" checkbox.
When you say you inverted the rotation matrix to solve a similar issue, when/where in the process do you invert the rotation matrix?
edit: there has been talk about fixing so all plugins getter and setters use the same unit and range, but its nothing we have worked on
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I was wondering, though, if the limited range of the Euler angles describing the rotation on that axis is normal or if there is a bug in the FreePIE plugin converting quaternions to Euler angles?
I would think all three axes should be consistent between the same device / same FreePIE plugin.
Also, unless I am missing something, it doesn't make sense to me to have the range limited to 180 degrees on 1 axis, while the other two axes have a full range of 360 degrees, but that is effectively what I have been observing from the outputs of three different devices now through FreePIE, on both desktop and Android.
I would think all three axes should be consistent between the same device / same FreePIE plugin.
Also, unless I am missing something, it doesn't make sense to me to have the range limited to 180 degrees on 1 axis, while the other two axes have a full range of 360 degrees, but that is effectively what I have been observing from the outputs of three different devices now through FreePIE, on both desktop and Android.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
When you say devices do you mean 3 android devices or 3 different plugins / hardware all together?
If 3 android devices, are you using google fusion or custom freepie fusion. If its google fusion its up to the phone to do the fusion ,that might differ from different phones.
I can check my phone tomorrow and see what it outputs, but I havent had any prblems with it, when using hydra or trackir / freetrack emulation
If 3 android devices, are you using google fusion or custom freepie fusion. If its google fusion its up to the phone to do the fusion ,that might differ from different phones.
I can check my phone tomorrow and see what it outputs, but I havent had any prblems with it, when using hydra or trackir / freetrack emulation
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
The three different devices I was referring to were an Android tablet, a YEI 3space and a Razer Hydra. Therefore, 3 different hardware devices and 3 different FreePIE plugins. I was using the Debug mode of FreePIE Android to view the output on the Android device.
I've observed the output of FreePIE diagnostics from the three different devices I mentioned. The Euler angles generated by FreePIE always have 2 axes with a full 360 degree range of unique values from 0 to +/- pi radians, while 1 axis is effectively mirrored because it ranges from 0 to 1/2pi at 90 degrees and heads back to 0 as it approaches 180 degrees, then flips sign and does the same thing but in the opposite direction as you keep rotating to 360 degrees. The result is two quadrants of the circle about this "mirrored" axis are represented by an identical range of values. Therefore, it's impossible to tell the orientation of this axis independently of the other two axes.
By the way, attached is a diagram to clarify what I mean about the range of the axes.
If you start the center orientation, then roll 180 degrees positive, the output from FreePIE will be like so (rounded/ideal numbers):
yaw,pitch,roll
0,0,0 (center position)
0,0,0.785 (45 degrees positive roll)
0,0,1.57 (90 degrees positive roll--notice how we start heading back to 0 after 90 degrees roll)
1.57,1.57,0.785 (135 degrees positive roll--notice how pitch and yaw are now rising steadily)
3.14,3.14,0 (180 degrees positive roll)
Said differently,
0,0,0 (center position)
0,0,1/4pi (45 degrees positive roll)
0,0,1/2pi (90 degrees positive roll)
1/2pi,1/2pi,1/4pi (135 degrees positive roll)
pi,pi,0 (180 degrees positive roll)
Edit: The issue is gimbal lock. Depending on the device you are using, the axis which produces the gimbal lock problem may be different because of the order of operations. Note how the yaw and pitch axes are identical and follow eachother after you reach 90 degrees roll. This is due to the fact that a pair of axes is aligned which creates the gimbal lock condition. The system effectively loses an axis. In other words, yaw and pitch will do the same thing to the orientation.
If you observe the video from brantlew, you can kind of see the effects this is having.
If you recall, one of the tests I performed was to map a full-range axis (0 to pi or 0 to 180 degrees +/-) from another device to the roll axis of the Hydra while driving pitch and yaw from the Hydra itself. I was able to accomplish the full range of rotations in 360 degrees on all axes. This would seem to indicate my end application requires the full range on all axes.
Edit - the best way to do this is with quaternions. I think there might be some ways to do it with Eulers as well but quaternions do not suffer from gimbal lock.
I sort of expected to see each angle for each axis have a full range of values capable of representing a full 360 degrees of rotation. I am going to experiment with more quaternion to Euler angle code and read up more on axis angle representations to see what I can learn. The simplistic way in which I have been looking at the angles for each axis as independent is obviously not the correct way to interpret these angles.
I've observed the output of FreePIE diagnostics from the three different devices I mentioned. The Euler angles generated by FreePIE always have 2 axes with a full 360 degree range of unique values from 0 to +/- pi radians, while 1 axis is effectively mirrored because it ranges from 0 to 1/2pi at 90 degrees and heads back to 0 as it approaches 180 degrees, then flips sign and does the same thing but in the opposite direction as you keep rotating to 360 degrees. The result is two quadrants of the circle about this "mirrored" axis are represented by an identical range of values. Therefore, it's impossible to tell the orientation of this axis independently of the other two axes.
By the way, attached is a diagram to clarify what I mean about the range of the axes.
If you start the center orientation, then roll 180 degrees positive, the output from FreePIE will be like so (rounded/ideal numbers):
yaw,pitch,roll
0,0,0 (center position)
0,0,0.785 (45 degrees positive roll)
0,0,1.57 (90 degrees positive roll--notice how we start heading back to 0 after 90 degrees roll)
1.57,1.57,0.785 (135 degrees positive roll--notice how pitch and yaw are now rising steadily)
3.14,3.14,0 (180 degrees positive roll)
Said differently,
0,0,0 (center position)
0,0,1/4pi (45 degrees positive roll)
0,0,1/2pi (90 degrees positive roll)
1/2pi,1/2pi,1/4pi (135 degrees positive roll)
pi,pi,0 (180 degrees positive roll)
Edit: The issue is gimbal lock. Depending on the device you are using, the axis which produces the gimbal lock problem may be different because of the order of operations. Note how the yaw and pitch axes are identical and follow eachother after you reach 90 degrees roll. This is due to the fact that a pair of axes is aligned which creates the gimbal lock condition. The system effectively loses an axis. In other words, yaw and pitch will do the same thing to the orientation.
If you observe the video from brantlew, you can kind of see the effects this is having.
If you recall, one of the tests I performed was to map a full-range axis (0 to pi or 0 to 180 degrees +/-) from another device to the roll axis of the Hydra while driving pitch and yaw from the Hydra itself. I was able to accomplish the full range of rotations in 360 degrees on all axes. This would seem to indicate my end application requires the full range on all axes.
Edit - the best way to do this is with quaternions. I think there might be some ways to do it with Eulers as well but quaternions do not suffer from gimbal lock.
I sort of expected to see each angle for each axis have a full range of values capable of representing a full 360 degrees of rotation. I am going to experiment with more quaternion to Euler angle code and read up more on axis angle representations to see what I can learn. The simplistic way in which I have been looking at the angles for each axis as independent is obviously not the correct way to interpret these angles.
You do not have the required permissions to view the files attached to this post.
Last edited by kzoink on Sun Sep 15, 2013 12:32 pm, edited 3 times in total.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Good observations. Come to think about it, if you use the custom FreePIE fusion and not google fusion it uses the same Quat > euler conversion as the two other plugins. I based the Queternion > Euler class on brantlews code from the Hydra plugin, so that makes sense that those three output same. Here is the code.
https://github.com/AndersMalmgren/FreeP ... ternion.cs
So its possible there is something wrong with the logic there, strange that it hasn't been observerd by anyone earlier.
I'm super busy this weekend, I might have some time to investigate the quat > euler code tomorrow.
Please let me know if you find anything while reading up!
https://github.com/AndersMalmgren/FreeP ... ternion.cs
So its possible there is something wrong with the logic there, strange that it hasn't been observerd by anyone earlier.
I'm super busy this weekend, I might have some time to investigate the quat > euler code tomorrow.
Please let me know if you find anything while reading up!
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
The only additional observation I have to share at the moment is that this issue / phenomenon might be gimbal lock. I've had the sneaking suspicion since the start as I am well aware of gimbal lock but I'm trying to achieve a full understanding of this problem and see if there's any solution to it except moving to quaternions and avoiding the conversion and therefore the problem altogether.
If you happen to have an iPhone, download the app "Euler Angles" for a great visualization of Euler angles in their many forms.
Also, another app available on Android is "Euler Compass" and it suffers from gimbal lock, while giving you a nice 3D real-time visualization of the phenomenon. You'll note the yaw, pitch and roll ranges and values are identical to what is shown in FreePIE.
The Wikipedia article on Euler angles is a pretty good resource explaining the different conventions used. Not all Euler angles are equal and the term is used ambiguously in most cases.
I've been experimenting with different quaternion to Euler code but so far the code I have used all suffers from this phenomenon.
If I have to, I will expose quaternions in the interface so that they can be used in the FreePIE scripts...
If you happen to have an iPhone, download the app "Euler Angles" for a great visualization of Euler angles in their many forms.
Also, another app available on Android is "Euler Compass" and it suffers from gimbal lock, while giving you a nice 3D real-time visualization of the phenomenon. You'll note the yaw, pitch and roll ranges and values are identical to what is shown in FreePIE.
The Wikipedia article on Euler angles is a pretty good resource explaining the different conventions used. Not all Euler angles are equal and the term is used ambiguously in most cases.
I've been experimenting with different quaternion to Euler code but so far the code I have used all suffers from this phenomenon.
If I have to, I will expose quaternions in the interface so that they can be used in the FreePIE scripts...
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I can now confirm that the problem is in fact gimbal lock.
Gimbal lock occurs at 90 degrees on one of the axes when using Euler angles to represent rotation in an AHRS. Exactly which one depends on the order of operations. This is why it was happening on pitch on two of my other devices and roll with the Hydra.
When in the gimbal lock condition, two of the axes are aligned (in the case of the Hydra, roll and yaw). At that point, because of the gimbal lock condition, yaw and pitch will both indicate the same rotation until the gimbal lock condition no longer exists.
The reason no one is really noticing this in FreePIE is most people are using it for head tracking. You're unlikely to experience gimbal lock while head tracking because you won't pitch or roll your head more than 90 degrees very often if at all.
Often times axis order is deliberately chosen/arranged to make it unlikely that a user will experience gimbal lock under normal circumstances. In the head tracking application, it would make perfect sense for it to be the roll axis. Pitch would also work although some users may pitch beyond 90 degrees occasionally. I would think rolling beyond 90 degrees would be more rare.
Gimbal lock occurs at 90 degrees on one of the axes when using Euler angles to represent rotation in an AHRS. Exactly which one depends on the order of operations. This is why it was happening on pitch on two of my other devices and roll with the Hydra.
When in the gimbal lock condition, two of the axes are aligned (in the case of the Hydra, roll and yaw). At that point, because of the gimbal lock condition, yaw and pitch will both indicate the same rotation until the gimbal lock condition no longer exists.
The reason no one is really noticing this in FreePIE is most people are using it for head tracking. You're unlikely to experience gimbal lock while head tracking because you won't pitch or roll your head more than 90 degrees very often if at all.
Often times axis order is deliberately chosen/arranged to make it unlikely that a user will experience gimbal lock under normal circumstances. In the head tracking application, it would make perfect sense for it to be the roll axis. Pitch would also work although some users may pitch beyond 90 degrees occasionally. I would think rolling beyond 90 degrees would be more rare.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Nice findings!
So you have exposed the quaternions on the Hydra plugin and confirmed that its working?
Sadly alot of hardware SDK's only expose the Euler angels
So you have exposed the quaternions on the Hydra plugin and confirmed that its working?
Sadly alot of hardware SDK's only expose the Euler angels
-
- One Eyed Hopeful
- Posts: 28
- Joined: Thu Apr 11, 2013 6:59 am
Re: Razer hydra emulation
I haven't yet exposed the quaternions but I think that's the only real option here to get full 360 rotation on all axes without singularities.
There might be some trickery you can do with the Euler angles to avoid or correct for singularities as I've seen references to those kinds of approaches but most just go straight for quaternions.
There might be some trickery you can do with the Euler angles to avoid or correct for singularities as I've seen references to those kinds of approaches but most just go straight for quaternions.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
ok, a shame that we cant use Euler. Only 3 SDK's I know from top of my head that exposes quat. Hydra, Android (only when using raw data) and Yei.
-
- One Eyed Hopeful
- Posts: 3
- Joined: Wed Sep 25, 2013 2:16 am
Re: Razer hydra emulation
Sorry to revive a somewhat old post, however I'm trying to emulate the Razer Hydra (along side a real hydra - combining the motion-control from the hydra with keyboard presses that emulate the trigger being pressed).
I've tried using the sixense(_fake).dll to no avail, and I've tried compiling the Razer Hydra Emulation branch from github and testing that.
The game I'm trying to test it on is Surgeon Simulator 2013, which has a Hydra setting and I've also tried it on the Tuscany demo from Sixense. Is there something I'm missing?
I've tried this simple code
and all examples from this post.
Thanks,
Chris
I've tried using the sixense(_fake).dll to no avail, and I've tried compiling the Razer Hydra Emulation branch from github and testing that.
The game I'm trying to test it on is Surgeon Simulator 2013, which has a Hydra setting and I've also tried it on the Tuscany demo from Sixense. Is there something I'm missing?
I've tried this simple code
Code: Select all
keyboard.getKeyDown(Key.Q):
hydra[0].trigger = 1
Thanks,
Chris
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
Have you replaced the sixense.dll with the fake dll in tuscany demo?
Also you cant just set the trigger, the fake dll needs to know the real hydras yaw, pitch, roll. The fake dll cant get them from the real hydra otherwise
Also you cant just set the trigger, the fake dll needs to know the real hydras yaw, pitch, roll. The fake dll cant get them from the real hydra otherwise
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
This script works for me
Code: Select all
def update():
hydra[0].yaw = android.googleYaw
hydra[0].pitch = android.googlePitch
hydra[0].roll = android.googleRoll
hydra[0].trigger = mouse.leftButton
hydra[1].trigger = mouse.rightButton
if starting:
android.update += update
-
- One Eyed Hopeful
- Posts: 3
- Joined: Wed Sep 25, 2013 2:16 am
Re: Razer hydra emulation
Thanks! I'll test it out tomorrow and report back
-
- One Eyed Hopeful
- Posts: 3
- Joined: Wed Sep 25, 2013 2:16 am
Re: Razer hydra emulation
Quick update! I got it to work, I'll parse the real hydras yaw/pitch/roll through FreePie Thanks for the quick help!CyberVillain wrote:This script works for me
Code: Select all
def update(): hydra[0].yaw = android.googleYaw hydra[0].pitch = android.googlePitch hydra[0].roll = android.googleRoll hydra[0].trigger = mouse.leftButton hydra[1].trigger = mouse.rightButton if starting: android.update += update
Seems like I was unaware that I had to replace the sixense.dll in the surgeon simulator folder
-
- Petrif-Eyed
- Posts: 2708
- Joined: Sat Sep 01, 2012 10:47 pm
Re: Razer hydra emulation
I am reading Hydra USB HID packets with the signal 11 hidapi library, and I experienced the same roll gimbal lock. I used this quaternion to euler conversion formula from wikipedia:kzoink wrote:... Edit: The issue is gimbal lock. Depending on the device you are using, the axis which produces the gimbal lock problem may be different because of the order of operations. Note how the yaw and pitch axes are identical and follow each other after you reach 90 degrees roll. This is due to the fact that a pair of axes is aligned which creates the gimbal lock condition. The system effectively loses an axis. In other words, yaw and pitch will do the same thing to the orientation. ...
http://en.wikipedia.org/wiki/Conversion ... Conversion
However, to make yaw and pitch work I had to rotate coordinates from (X,Y,Z,W) to (-Z,X,Y,W). I also had to rotate the pitch output by 180 degrees. Roll showed the same gimbal lock as described.
I did not like the hack of -Z for yaw and pitch but +Z for roll, so I found how Ryan Pavlik did it in his VRPN hydra fork. He negated X while extracting it from the HID packet. That effectively makes the rotation from (X,Y,Z,W) to (Z,-X,Y,W), contrary to desriptions of how to rotate coordinate systems. However, this fixed the hack in my quat2euler code. A side effect is that now the gimbal lock moved to pitch, and now I had to rotate pitch 180 degrees instead of roll. With gimbal lock on pitch like it is now in my code, I cannot look point beyond straight up, or beyond straight down (such as when swinging a sword).
I rather prefer roll to gimbal lock, because my wrist really only rotates 180-degrees anyway, so I suppose I will undo the X-axis Pavlick hack and go back to the roll hack in quat2euler.
Anyway, that shows that we can select which axis we want to gimbal lock in software. Or we could just not use Euler angles and stick with quats all the way, eh?
EDIT: I just tested my code again, and yes, the roll does go from -180 to 180. Pitch climbs up to 90 and then falls back down again, or goes down to -90 and then starts climbing again. And it messes up pitch beyond there, as described in the quote above. Gimbal lock indeed. The joys of Euler angles, eh?
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
-
- Petrif-Eyed
- Posts: 2166
- Joined: Mon Jun 22, 2009 8:36 am
- Location: Stockholm, Sweden
Re: Razer hydra emulation
hmm, thanks for input, but I do not understand if you want changes in FreePIE?
One way would be to expose the quaternion but there are not many API's that have these, Android Raw mode and Hydra are the only two that I can think of from top of my head
edit: Yei exposes them aswell
One way would be to expose the quaternion but there are not many API's that have these, Android Raw mode and Hydra are the only two that I can think of from top of my head
edit: Yei exposes them aswell