Freetrack support for 3rd PS Move

[Remlas]

Hi It'd be awesome to add support for Freetrack. The new version of Vridge, the program which allow us to play SteamVR or Oculus games with a Google cardboard, can convert positional or/and rotational moves from Freetrack to Vive/Oculus moves. With three PlayStation Move controllers and the Cardboard we will be able to emulate Vive wands and HMD. Another way'd be plugin for FreePie wchich will redirect all 6 axes for all PS Moves. Then we can write script to emulate hydra and Freetrack. Thank you in advance and nice work :)

[HipsterSloth]

The library supports up to 6 tracked controllers at once so nothing special would be needed to have a third controller connected. So it would just be a matter of writing either the FreePie or FreeTrack plugin that connects to the service in the same way that the openvr plugin does. It'll be a while before I could get to this task so I'm going to throw a "help wanted" label up on this task. I'm going to be working on documentation over the next week so hopefully anyone that wanted to make a FreePIE or FreeTrack plugin could look at the openvr plugin + documentation as a starting point.

[zelmon64]

@Remlas How did you get on with the current FreePIE plugin? I tried to use a third PSMove for the head tracking for VRidge but couldn't get the orientation to line up correctly (the position was fine). I think there may be something wrong with the VRidge FreeTrack interface but I can't be certain.

Now that I have some experiance with the FreePIE plugin I was planning to alter it to use PSMoveService. I can get started on it (I'll change the tag). [edit: I couldn't figure out how to change the tags and I probably don't have access anyway. Could someone please change it from help wanted to in progress? Thank you :).]

@HipsterSloth I assume the service has some magical property so that multiple clients can run simultaneous and use different PSMoves (ie. so that two PSMoves could be used by SteamVR and a third is tracked by FreePIE)? If that's the case (which I assume it probably is since you guys are awsome at this), then it should be relitavely easy for me to work on this.

[cboulay]

Yes, multiple clients can run simultaneously. All clients have access to all devices; it's up to each client to figure out what it wants to get data on. I haven't looked at FreePIE in a while and I don't remember anything about it, so I don't know what would be the best way to tell it to only register for the 3rd-enumerated controller. Maybe that can be a command-line option, or have a little GUI? As you are the FreePIE client implementer, I'll trust your decision on this ;)

[HipsterSloth]

@zelmon64 It occurs to me that test_console_client.cpp might be a good reference for connecting a client application to the service and getting the controller data since it doesn't have all of the extra details of the steamvr plugin. It's been a while since I tested it, but it looks like it's still doing the right thing.

[zelmon64]

Unfortunately I'm having a hard time getting this to work. FreePIE plugins are written in cs so I can't seem to figure out how to create the ClientControllerView class. Then on top of that I don't think I'll be able to use it as a pointer. The last time I tried pointers was to get the EXT data with PSMoveAPI but that wouldn't work. I had to instead add some code to PSMoveAPI that gave the EXT data directly so that I could avoid the pointers.

@cboulay I'll continue to think about it and try stuff but I doubt I'll actually get anywhere. Could you please remove the in progress tag so that someone else who might actually know what they're doing can have a shot at it? I was hoping I could directly transfer what I learnt from MoveFramework and PSMoveAPI but this seems just a bit too dissimilar for that to work.

[HipsterSloth]

@zelmon64 For what it's worth I need to write a CS wrapper of the ClientAPI for PSMove-Unity5 anway. Once I do that I you could leverage that for FreePIE.

[zelmon64]

@HipsterSloth That sounds perfect thanks! It will be very nice for me to see how you make the wrapper because I don't know much / anything about how it's done. I tried to do it when I had that problem with PSMoveAPI but I just couldn't figure out where to start.

[HipsterSloth]

@zelmon64 In case you're curious, it involves using managed C++ and writing an between class that marshalls the data. It's kind of gross. There are apparently tools that can auto generate the marshaling code. I've been meaning to look into how that's done. Here's an example of marshalling by hand: http://www.codeproject.com/Articles/18032/How-to-Marshal-a-C-Class

[hawkinse]

I've put together a simple client that passes position and rotation information to FreePIE, it's available here. I had some difficulty getting FreePIE to play nice with C++, so there's some redundancy in how it's used (C# talks to FreePIE through DLL, managed C++ wrapper acts as bridge to unmanaged C++ client). When that C# wrapper for Unity gets written it would probably be simpler to redo this all in C#.

I'm using this with VRidge and a third controller for head tracking, and location works fine in Steam VR. Rotation only works up to 180 degrees, I'm not entirely sure where the breakdown is. Could be in my freepie python script, could be a limitation of freetrack, or it could be a problem in VRidge's implementation of freetrack. Regardless, for now VRidge users can use rotation from their phones and deal with the constant need to reset orientation.

[HipsterSloth]

@hawkinse that's super rad! Cboulay is actually working on a C99 wrapper for the client interface which should make it easier to make client wrappers in C# and python. I don't know what the timeline is for that, but i'll let you know when it's in place.

[zelmon64]

@hawkinse That's awesome work, thanks for sharing it! Only yesterday someone asked me for an ETA on this.

I've had a similar problem with sending the orientation to VRidge. I feel like it's a problem on their end since FreePIE can send the orientation to the Hydra fine. When dealing with orientation there seems to be a lot of options (quaternion / Euler angles / Tait–Bryan angles) so something may have accidentally been swapped or done in the wrong order in VRidge. The annoying thing is that the normal OpenTrack methods as I understand can only do front-facing tracking so I'm not sure how to verify where the problem is.

[cboulay]

I'm going through the issues and closing everything that has to do with using external applications (like freepiebridge, riftcat, kinect whatever, vrridge whatever), simply because we don't have the means or the bandwidth to debug them now and we can't verify that the problem is due to PSMoveService. Please post in the google group. We'll open an issue here when we can confirm that it is something that can be fixed in PSMoveService.

https://groups.google.com/forum/#!forum/psmoveservice