Prior draft here

This outlines at a high level the set of work to do to get PSMoveService to a 1.0 release.

The device management and processing framework is basically in place on the service. We just need the respective device views to actually do the tracking computation.

• Network Request Set tracker camera control parameters (exposure, brightness, etc)
• Network Request Turn on/off tracking for a controller
  • Flags a controller as tracked
• For each tracker:
  • Find the blobs for each active controller
  • Compute 2D blob positions for each active controller
  • Blob State:
    • x/y pixel position
    • pixel radius
    • controller id

• Network Request Assign tracking color to a controller
• Compute Raw position
  • Compute 3D tracked position position
    • Port over multicam Position triangulation from my fork of psmoveapi. See implementation discussion here.
    • Fallback to blob radius -> Z-distrance method for one camera
• Position Filter (currently exists as a pass-thru filter only)

• Implement missing filter types (LowPass, Kalman)
• Apply prediction using position filter state space model

The public facing client API should remaining largely the same. The one major change I want to make is to get rid of the callback functions for the async requests and instead switch to a result polling model similar to how OpenVR.

• COMPELTED- Remove callbacks from client API, Issue #20

  • Switch all async event callback functions over to poll_next_event() style
  • This is more thread safe for clients and is easier to Marshal into C#

         // Process OpenVR events
         vr::VREvent_t event;
         while (m_pVRSystem->PollNextEvent(&event, sizeof(event)))
         {
             processVREvent(event);
         }

• Add any additional functionality needed by OpenVR interface

The config tool needs several calibration and setup tools ported over from psmoveapi. The most complicated ones are the old and new camera pose calibration tools that determine the location ofthe PS3EYE tracking cameras. All of the existing parts of the config tool will need some love too.

• Intrinsic Matrix
  • Port over the tracker_camera_calibration tool from psmoveapi
  • Save the intrinsic matrix to a config file
• Extrinsic Matrix (HMD coregistration)
  • Port over the visual_coregistration_tool from psmoveapi
  • Save the extrinsic matrix to a config file
• Extrinsic Matrix (Calibration Mat)
  • Port over the visual_tracker_setup from psmoveapi (see https://youtu.be/33cWRaCC9hU)
  • Save the extrinsic matrix to a config file
• Controller Color Selection
  • Add a config panel in the controller settings to select a tracking color
  • Requests a list of available colors from the server
  • Updates selected color of the controller on the server
  • Server saved tracked color to the controller config
• Exposure Setting
  • Add as a config tool for a selected tracker in the config tool
  • Select through a set of exposure presets

In order to make the PSMoveService broadly usable I think it makes the most sense to create an OpenVR plugin. This will expose the psmove controllers and the ps3eye trackers to SteamVR. Fortunately Valve has already provided a reference driver for the Razer Hydra so it should be pretty straight forward to adapt a plugin that connects to PSMoveService instead.

• Implement vr::IServerTrackedDeviceProvider
  • Owner if the ClientPSMoveAPI instance
• Implement vr::IClientTrackedDeviceProvider
  • Mostly no-ops on stuff, related to HMD operation
  • See vr::ITrackedDeviceServerDriver-Overview
• Implement vr::IServerTrackedDeviceProvider
  • Does the bulk of the work updating and posting data about the controllers
  • See vr::ITrackedDeviceServerDriver-Overview
• Tracked with Issue #23