Emulating Hydra/Stem through psmove and navigation controller

[David G. Miguel]

Hi guys!

I'm currently working on a personal open source project trying to emulate the razer hydra and stem controllers through the psmove and the navigation controller. This could be huge to play VR games for a "low" pricepoint.

I'll be using FreePIE to emulate the Razer Hydra / STEM and I'll be creating a pugin to support the psmove within FreePIE using this awesome library.

I'll build 2 attachments for the navigation controllers and psmoves in order to have joysticks and tracking in both hands.

http://www.mtbs3d.com/phpBB/viewtopic.php?f=139&t=19998

But I need some advices with a couple of issues.

Currently I've got 3 pitfalls with this approach:

1.- You need to build a custom case or attachment for the psmove and navigation controller :S.

2.- I don't know about any library which supports the navigation controllers. I guess I'll have to use motioninjoy to get these working.

3.- The biggest one, obviously the damn windows bt. It has been a while since I've checked this but I guess there is no change here. Maybe you have suceed or make any progress with the motioninjoy connection? I have been able to connect moves to win 7 without any problems but I have tried it for several hours (literally) with win 8 without success.

[Alexander Nitsch]

> I'm currently working on a personal open source project trying to emulate
> the razer hydra and stem controllers through the psmove and the navigation
> controller. This could be huge to play VR games for a "low" pricepoint.

Very cool. I first saw this project quite some time ago. Nice to see you
are still pursuing this.

> 2.- I don't know about any library which supports the navigation
> controllers. I guess I'll have to use motioninjoy to get these working.

Adding support for the Navigation controller to the psmoveapi is
actually not that big a deal. Most of the required infrastructure is
already in place. I started working on it a couple of months ago. But I
got stuck at the point where I tried to make the Nav reliably connect to
the host. Something similar to the issue we all know from connecting the
Move on Windows. Only that I develop on Linux and did not yet get this
to work in a similar way that the Move connection works there. The Nav
seems to behave quite differently from the Move in this respect.

> 3.- The biggest one, obviously the damn windows bt. It has been a while
> since I've checked this but I guess there is no change here. Maybe you have
> suceed or make any progress with the motioninjoy connection? I have been
> able to connect moves to win 7 without any problems but I have tried it for
> several hours (literally) with win 8 without success.

No, unfortunately no breakthrough on Windows yet. You might have noticed
Jonathan's postings on this list just a couple of days ago. I guess he
is looking into this and I just decided to pick up where I left with
some old experiments that try to solve the issue by way of directly
hacking the Registry. So, who knows. Maybe this will finally get us
somewhere on Windows. ;)

BTW, the old psm...@lists.ims.tuwien.ac.at is defunct. Use only list
here at Google Groups, please.


Alex

[Kieran Coulter]

I'd like to work with you on this. Much like my work on the PS Move project itself, I'd be happy to purchase the Stem/Hydra tools so we can work backwards from them as well. I learned a lot working with the Move.me system last year even though needing a PS3 was ridiculous.

Let's follow up on this!

--
You received this message because you are subscribed to the Google Groups "psmove" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psmove+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/psmove.
For more options, visit https://groups.google.com/d/optout.

[Alexander Nitsch]

> I'd like to work with you on this.

Not really sure if you were talking to me or to David.

Which part exactly would you like to work on?


Alex

[NoxWings]

Hi guys,

Sorry for taking my time to answer you but my gfx card crashed last friday and that was my only win7 machine so I haven't done almost anything yet.

 

Very cool. I first saw this project quite some time ago. Nice to see you
are still pursuing this.

Humm I have just started this project, never knew someone tried it before. I have only found the dualPlay campaing but unfortunately too late to support it.

 

Adding support for the Navigation controller to the psmoveapi is
actually not that big a deal. Most of the required infrastructure is
already in place. I started working on it a couple of months ago. But I
got stuck at the point where I tried to make the Nav reliably connect to
the host. Something similar to the issue we all know from connecting the
Move on Windows. Only that I develop on Linux and did not yet get this
to work in a similar way that the Move connection works there. The Nav
seems to behave quite differently from the Move in this respect.

 That sound nice. Btw I don't think this is the biggest priority but would be really nice to handle psmove and the nav through the same open-source software instead of having to use 3rd party proprietary one.

 

No, unfortunately no breakthrough on Windows yet. You might have noticed
Jonathan's postings on this list just a couple of days ago. I guess he
is looking into this and I just decided to pick up where I left with
some old experiments that try to solve the issue by way of directly
hacking the Registry. So, who knows. Maybe this will finally get us
somewhere on Windows. ;)

Yeah, It's awesome that someone is still keeping an eye on it. I thought most people would have lost interest. I honestly don't have the knowledge to really help there :( but I love to see they are getting down that rabbit hole ^^

I'd like to work with you on this. Much like my work on the PS Move project itself, I'd be happy to purchase the Stem/Hydra tools so we can work backwards from them as well. I learned a lot working with the Move.me system last year even though needing a PS3 was ridiculous.
Let's follow up on this!

Would be nice, but actually it shouldn't be that hard to achieve. Basically the main task is writing a plugin for FreePIE that uses the psmove API. As soon as I get my pc back I'll commit and update the github fork. I've also made a simple script to test the FreePIE hydra emulation and it works pretty well so hopefully we won't need a real hydra.

[Alexander Nitsch]

>> Very cool. I first saw this project quite some time ago. Nice to see you
>> are still pursuing this.
>>
> Humm I have just started this project, never knew someone tried it before.
> I have only found the dualPlay campaing but unfortunately too late to
> support it.

Whoops, my bad. Looks like I confused this with the Dual Play.


Alex

[Kieran Coulter]

Hi again,

I will be more able to assess where I will be most able to contribute once my Sixense STEM controllers arrive in October. I want to compare/contrast the two before I decide.

[NoxWings]

I think STEM will have way way higher precision than this "cheap" solution. In fact, STEM won't be constrainted with oclusion like an optical tracking solution...

[NoxWings]

I'm almost done but I need your help a little bit. The positional tracking right now can give us X, Y and R (distance). I haven't tested it yet but I'm assuming X and Y are the pixels where the bulb center is located. I need to translate this prespective projection into a more consistent orthogonal reference system independent of the camera view fustrum.

1.- Currently if you translate the move a couple of cm when it is close to the camera it changes the X and Y values way faster than when you are far from the camera. 

(Actual movement ilustrated with green lines and X, X' being the current reading values)

2.- Furthermore if you have the move right in the center of the image it will be a lilttle bit closer to the camera than if it is located in the peripheral vision of the fustrum.

(Ilustrated with the blue lines)

I'm not really into this 3D math thing, projection or space coordinates systems but I think in the end I need an algorith to translate a perspective projection and the distance value (like a Z buffer value?) into an orthogonal projection. Is it right? Am I completely lost?

[NoxWings]

I'm almost done but I need your help a little bit. The positional tracking right now can give us X, Y and R (distance). I haven't tested it yet but I'm assuming X and Y are the pixels where the bulb center is located. I need to translate this prespective projection into a more consistent orthogonal reference system independent of the camera view frustum.

1.- Currently if you translate the move a couple of cm when it is close to the camera it changes the X and Y values way faster than when you are far from the camera. 

(Actual movement ilustrated with green lines and X, X' being the current reading values)

2.- Furthermore if you have the move right in the center of the image it will be a lilttle bit closer to the camera than if it is located in the peripheral vision of the frustum.

(Ilustrated with the blue lines)

I'm not really into this 3D math thing, projection or space coordinates systems but I think in the end I need an algorith to translate a perspective projection and the distance value (like a Z buffer value?) into an orthogonal projection. Is it right? Am I completely lost?

2014-09-04 12:03 GMT+02:00 NoxWings <noxw...@gmail.com>:

[NoxWings]

Ouch I'm sorry, don't even bother to read my last msg, it doesn't matter. I've just tested Fredz unity plugin and looks like X,Y and R are already in some kind of orthographic projection. 

[NoxWings]

Hi again guys, I've been on vacation so I haven't worked that much on this topic, but I managed to get both psmoves and nav controllers emulating the razer hydra and in fact it works pretty well. 

About the navigation controller I'm going to try to get rid of motioninjoy using the open source SCP driver[1]. An oculus forum member pointed me towards this "solution".

On the other hand I've experience some drift orientation issues. I've tested psmove in a ps3 and the orientation looks much more solid with almost no noticeable drift. Especially when I shake the controllers the orientation goes crazy and then starts to get back in track but with some drift. I'm using the built-in fusion algorithm, is this a known "issue" and the expected behaviour or I am doing something completely wrong?

http://emulation-general.wikia.com/wiki/SCP_Driver_Package

2014-09-04 12:03 GMT+02:00 NoxWings <noxw...@gmail.com>: