Alpha Release #6.0.6

This release contains a ton of new code, some of which has been in progress since mid July. Several parts aren't completely done yet, but it was becoming painful to maintain many separate branches with so much churn in the master branch. So we decided to merge everything in its current state together now we are at a better merge point.

Multiple Controllers and Tracker PoV in tracking test tool

When testing tracking you can now see all connected controllers at once with the their associated bulb color and tracking id displayed:

You can also see the tracker point of view (PoV) for each tracker. This is useful for testing at a glance why tracking might be failing for a given tracker.

"Region-of-Interest" or ROI optimization

The most expensive part of the service by far is the image processing work to extract the tracking blobs from the video feed. The best way to deal with this is to have a model of where you think the controller will show up on screen and then search in a bounding box around that location. Since you are processing way fewer pixels you can typically see large performance gains from this. Chad was awesome and implemented this over the last few weeks.

This feature is currently disabled by default, but can be turned on by setting "disable_roi" to "false" in TrackerManagerConfig.json:

{
    "version": "2",
    "optical_tracking_timeout": "100",
    "use_bgr_to_hsv_lookup_table": "true",
    "tracker_sleep_ms": "1",
    "excluded_opposed_cameras": "false",
    "disable_roi": "false", <--- This is true by default

You can see the ROI region in the tracking PoV (select the "tracker video" button in the trst tracking tool). In that view you'll see the ROI box following the controller around.

One important bug with ROI. When tracking starts, if there is some other light source that could be considered the controller when the actual controller is out of view, the ROI will lock on to that light source. It won't track the actual controller when it comes into frame because it thinks it already sees the controller. You have to "displace" the imposter by moving the controller into the ROI box that the imposter is occupying. You can get around this issue by making sure the controller is in frame when tracking starts.

Lens Distortion Compensation

Every web cam lens has some amount of barrel distortion. Until now we haven't been correcting for it. This leads to small inaccuracies in position new the edges of the tracking frame. In order to compute the barrel distortion parameters we know have a calibration tool that you show a calibration pattern in several positions. Once enough samples have been captured we can compute the focal length and distortion parameters for the camera.

You don't actually need to run this tool for the PS3EYE since we now have the focal lengths and distortion parameters baked in. However this was an essential tool to add for support multiple camera types, which we want to support soon.

If you are really curious and want to run the tool look for the "distortion calibration" button on the tracker settings panel. The distortion calibration tool looks like this:

You'll need to print out the calibration mat found here:
https://github.com/cboulay/PSMoveService/blob/master/docs/Distortion/TrackerCalibrationPattern.png

The tool will ask you to measure the distance between the squares on the calibration mat. Usually this is around 24mm.

New Orientation and Position filter framework

You can now select between different orientation and position filters in the controller config. You can also reset to defaults if you forgot what the default filter settings were. The most important new filters are the Kalman Orientation and Position filter. We've spent months trying to get a version of these filters working. They are essential for smoothing out noisy optical tracking, which allows the DS4 to work at all.

Unfortunately the position Kalman filter still has some issues dealing with the accelerometer bias and extracting gravity from the signal, so for moment the Kalman position filter only smooths the optical tracking position. This results in the Kalman position filter feeling more latent than it should. Hopefully I can get the final kinks with this part of the filter worked out in the coming weeks.

If you do use the Kalman position or orientation filter I strongly recommend running the new optical noise calibration tool first. This tool measures how much noise we get from the raw position (and orientation in the case of the DS4) optical tracking. This is turn tells the Kalman filter how much to trust the optical measurements for a given tracking blob size. The optical noise calibration tool has pretty clear instructions. Basically you'll hold the controller in place at 10 different distances from the camera and then it will compute a best fit curve to the data it records. If you don't run this tool there are reasonable defaults in place.

Client CAPI

Current the client api is written in C++. This make psmove service trickier to interface with other programming languages (python, C#). We have a new client C api that wraps the C++ api. This still has some work to do, but is largely in place now. Over the coming months I'll be switching over the PSMoveConfig tool and SteamVR plugin to the C-API. Once that is done I'll rip out the C++ api that that we dont have to maintain two different client interfaces.

Intial PSVR headset work

Nothing to see here... move along...

https://www.youtube.com/watch?v=srRy6ZPwwYA
https://www.youtube.com/watch?v=1vYQvS2acpo

In all seriousness, there is some initial work I have in place for supporting the PSVR headset. This is still in very early development. I don't have optical tracking working yet. Don't bother poking around in this and hoping to do anything fun/useful with it yet. It's only in this release because we merged together some other branches. Once I have a chance to get more interesting work done on this I'll post some documentation on how to use this.

No more 32-bit releases

You can still build a 32-bit version of the project. But I'm not going to include the 32-bit version in the releases anymore. It's a pain to build both versions due to the manual build creation process I have at the moment. If you really do wan't the 32-bit version of the releases, please let me know in the google group.