Razer hydra emulation

Official forum for open source FreePIE discussion and development.
Post Reply
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

Euler > Quaternion matrix now corrected.

https://github.com/AndersMalmgren/FreeP ... l?raw=true
Croccy22
Cross Eyed!
Posts: 140
Joined: Wed Feb 04, 2009 7:51 am

Re: Razer hydra emulation

Post by Croccy22 »

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 :P. Should I be able to use my Imu to emulate one hydra while using a PS Move to emulate the second?

Matt.
User avatar
nateight
Sharp Eyed Eagle!
Posts: 404
Joined: Wed Feb 27, 2013 10:33 pm
Location: Youngstown, OH

Re: Razer hydra emulation

Post by nateight »

CyberVillain wrote:[Wiimotes are] a drifty device compared to the Oculus or even my Android phone
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! :lol:
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!
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

Croccy22 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 :P. Should I be able to use my Imu to emulate one hydra while using a PS Move to emulate the second?

Matt.
Yupp, I will fix x64 too
Yes but first you have to create a PS Move plugin because FreePIE does not have support for that.
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! :lol:
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.
Croccy22
Cross Eyed!
Posts: 140
Joined: Wed Feb 04, 2009 7:51 am

Re: Razer hydra emulation

Post by Croccy22 »

Wasn't there something you could do to get the psmove working with freetack or something? I thought I read that somewhere.

Matt.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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:
23: can't assign to read-only property trigger of type 'HydraPluginGlobal'
This would seem to indicate it is a read-only interface.

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.
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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?
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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:

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
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?
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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?
The 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.
Source
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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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?
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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?
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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?
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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:

Code: Select all

SIXENSE_EXPORT int sixenseGetHemisphereTrackingMode( int which_controller, int *state )
{
  return SIXENSE_SUCCESS;
}
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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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%...
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

I have only been involved in the emulation part of the plugin, brantlew did the reading. But in the source he's writing

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
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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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

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
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
I will check out brantlew's quat > Euler code next.

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.
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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?
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

kzoink 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?
Most devices has its own range, so you might have to convert the range into something that the fake dll can use correctly

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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!
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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...
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
kzoink
One Eyed Hopeful
Posts: 28
Joined: Thu Apr 11, 2013 6:59 am

Re: Razer hydra emulation

Post by kzoink »

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.
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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.
CaptainMack
One Eyed Hopeful
Posts: 3
Joined: Wed Sep 25, 2013 2:16 am

Re: Razer hydra emulation

Post by CaptainMack »

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

Code: Select all

keyboard.getKeyDown(Key.Q):
	hydra[0].trigger = 1
and all examples from this post.

Thanks,

Chris
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

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
CaptainMack
One Eyed Hopeful
Posts: 3
Joined: Wed Sep 25, 2013 2:16 am

Re: Razer hydra emulation

Post by CaptainMack »

Thanks! I'll test it out tomorrow and report back :-)
CaptainMack
One Eyed Hopeful
Posts: 3
Joined: Wed Sep 25, 2013 2:16 am

Re: Razer hydra emulation

Post by CaptainMack »

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
Quick update! I got it to work, I'll parse the real hydras yaw/pitch/roll through FreePie :-) Thanks for the quick help!
Seems like I was unaware that I had to replace the sixense.dll in the surgeon simulator folder
geekmaster
Petrif-Eyed
Posts: 2708
Joined: Sat Sep 01, 2012 10:47 pm

Re: Razer hydra emulation

Post by geekmaster »

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. ...
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:
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?
CyberVillain
Petrif-Eyed
Posts: 2166
Joined: Mon Jun 22, 2009 8:36 am
Location: Stockholm, Sweden

Re: Razer hydra emulation

Post by CyberVillain »

hmm, thanks for input, but I do not understand if you want changes in FreePIE? :D

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
Post Reply

Return to “FreePIE”