Feature Request: Add NullDriver-like HMD support using 3rd tracked controller

[HipsterSloth]

Some have requested the ability to use PSMoveService in SteamVR without having to use VRidge. See google group discussion "Is it possible to send HMD position to SteamVR without VRidge software?" .

There are two flavors of this request: 1) Use a 3rd psmove controller for head tracking and render the HMD view to a window like the NullDriver Sample that Valve includes with their OpenVR sdk. This is useful for mobile phone users that want to use Moonlight Game Streaming 2) Use a 3rd psmove controller or bulb for head tracking on HMDs that don't support head tracking (like the Deepoon E2 HMD). I assume this approach also would have an approach similar to the NullDriver sample. What is less clear is how the orientation data should work in this approach since you'll have better orientation state from the HMD then you would from a PSMoveController attached to the head.

In either case, we're going to want to implement something similar to the CSampleDeviceDriver class from the NullDriver sample.

[r57zone]

It seems to me that in first request it is necessary to create a separate project for mobile devices and hdmi headsets, since it is not connected with PlayStationVR.

As a head tracking, can might the data from OpenTrack (Output - UDP receiver). It supports Android (FreeTrack IMU) and other trackers (Oculus, Razer Hydra, or etc, will also expand input trackers).

The second request it will not be necessary to decide, since in Deepoon E2 has a clone of the tracker DK2, which means it will be perfectly recognized by OpenTrack, and therefore will good work in this project.

Also, eventually, someday in the future, it will be possible to extend this project and add the possibility of native alternative controllers (XInput controller like this [1] [2], Google DayDream VR controller, maybe mouse, or etc).

Therefore it seems to me appropriate to single out this to a separate project.

Thanks.

[r57zone]

I added code to the sample null driver, a set the test values sensors (accelerometer, gyroscope and magnetometer) and also quaterion calculate. If the HMD is changed position in SteamVR apps by default, then it will remain only remains to add read from the UDP.

driver_sample.zip

[ghost]

hello there i m folowing this tickets

sorry i don't understand how do install this drivers in steamVR and using it with a third psmove ?,

thanks

[HipsterSloth]

I added support for VirtualHMD tracking in: https://github.com/HipsterSloth/PSMoveSteamVRBridge/releases/tag/v1.2.0

You'll then use PSMoveFreePIEBridge to get the VirtualHMD tracking data to FreePIE: https://bitbucket.org/hawkinse/psmovefreepiebridge/downloads/PSMoveFreepieBridge-Release13.zip

Finally you can use FreePIEConnector to get the data from FreePIE into SteamVR http://www.driver4vr.com/

[r57zone]

The driver is written, but have is input lag so need to put WinSock reading in self thread, if someone can help, then here is the repository. Config & binary.

[HipsterSloth]

@r57zone Thanks for working on this!

I think you might be able to reduce the input lag you are experiencing if you switched the UDP socket you were creating over to a non-blocking socket. I use non-blocking UDP sockets in PSMoveService (via the boost::asio library).

Since you are just using the WinSock library, I think you can just do this after you bind the socket:

u_long nonblocking_enabled = TRUE;
ioctlsocket( fd, FIONBIO, &nonblocking_enabled );

See example from here: http://www.csee.usf.edu/~kchriste/tools/udpClientNonblock.c

If the recvfrom call returns WSAEWOULDBLOCK, that means that there is no more data to read and if this was a blocking socket it would block.

You also want to try and keep reading data in a loop to get the most recent udp packet (since you could have gotten multiple packets). So I think you want your update code to look something like this:

        //Read UDP socket with OpenTrack data
        if (SocketActivated == true) {
            bool bKeepReading= true;
            while(bKeepReading) {
                memset(&OpenTrackPacket, 0, sizeof(OpenTrackPacket));
                bytes_read= recvfrom(
                    socketS, 
                    (char*)(&OpenTrackPacket), 
                    sizeof(OpenTrackPacket), 
                    0, 
                    (sockaddr*)&from, 
                    &fromlen);

                if (bytes_read > 0) {
                    Yaw = DegToRad(OpenTrackPacket.yaw);
                    Pitch = DegToRad(OpenTrackPacket.pitch);
                    Roll = DegToRad(OpenTrackPacket.roll);
                } else {
                    bKeepReading= false;
                }
            }
        }

Finally it should be noted that UDP packets can be received out of order. Not sure if OpenTrack can put an incrementing sequence number on each packet so that you can tell if you got an old packet by keeping track of the largest sequence number received so far.

[r57zone]

@HipsterSloth Thanks, it helped, driver ready.

UPD: Plugin for OSVR.

[zelmon64]

@r57zone really awesome work!

[HipsterSloth]

I think I'm going to close this issue for a few reasons: 1) We now have virtual HMD tracking support 2) There are now Greg's "FreePIEConnector" and r57zone's "OpenVR-OpenTrack" steamvr bridge tools for getting this tracking data to an HMD driver in steam 3) I don't really have the time to create a new SteamVR nulldriver for the display portion