Skip to main content
Up and Coming
March 15, 2015

Working PS Move plugin for UE4; need help coreg with DK2

Update:

The plugin is not done but it's ready for public testing. I made a new thread here.


Hello all,

I recently made a PSMove plugin for UE4 that works in both Windows and OSX. It should work in Linux too with a simple compile of the psmoveapi binaries. The changes I had to make to the psmoveapi and PS3EYEDriver should also help anyone that wants to use the PSMove controllers in Windows or OSX (it's always worked in Linux) outside of UE4.

I need help co-registering the coordinates I get from the psmove (in cm from the camera) with the DK2's coordinate space.

For orientation, the roll and pitch are easy. The PSMove has a magnetometer so it's possible to get its true yaw but to make that useful in game I would also need access the DK2's magnetometer (I've read mixed reports that it even has one). Does anyone have any ideas here? Does it truly have a magnetometer? If so, does anyone know how to access it from within UE4?

If it does not then I'll need to somehow coregister the orientations by relying on the user to somehow point the controller in a specific orientation and pressing a button. I'm not too excited about that option.

For position, I would love it if I could access the DK2's camera's image feed. I could have the users run a quick calibration app that asked them to draw in the air then for each frame I would estimate the PSMove controller's position in 3D space relative to each camera, then create a transformation matrix from PS3Eye coordinates -> DK2 camera coordinates. This matrix could be stored in a data file somewhere (or registry entry) and as long as the cameras don't move relative to each other then it should stay the same. Any ideas on accessing the DK2's images, even outside of a game engine or the SDK?

If I can't access the DK2's camera feed then I'll probably need to touch the PSMove at specific locations on the surface of the DK2 and sample >=4 fiducial locations. I would need accurate dimensions of the DK2 body relative to whatever origin
it uses. Anyone have any experience with this?

Accuracy is important to me. We've all read that accuracy goes a long way to helping with immersion, so I hope that it's important to you too, but it's especially important to me because I'm using the data for research. So I can't really accept calibration methods that simply ask the user to put the controller near where they think it should be in the world and press a button.

    180 replies

    Up and Coming
    April 15, 2015
    "bullale" wrote:
    I don't think we'll ever get to 0.05 mm precision with this technology.

    Yes I guess this precision is probably not attainable, but having at least submillimeter precision and accuracy would be nice and looks feasible to me.

    "bullale" wrote:
    I'm not sure if sub-pixel fitting will gain you anything over the fitEllipse. fitEllipse returns the ellipse center, rectangle, and angle in float, not pixel ints.

    I didn't meant to replace fitEllipse since it already seems more effective than using the bounding box, but I guess it's initialized with integer coordinates where we could use floating point sub-pixel coordinates if it supports that.

    "bullale" wrote:
    I printed the angle fitEllipse returns and the angle calculated by taking atan2f(x,y) and they were off by 1-3 degrees when the controller was in the upper right quadrant. When the controller was in another quadrant they were very different, but not quite 180 degrees different.

    Not bad. It's curious than the angle was different for other quadrants though.

    "bullale" wrote:
    Since the last message I updated the annotation function to draw the fit ellipse. You can see that it matches the blob very well and it doesn't jitter around, even though the ROI jitters around.

    Nice, I'll have a look.

    "bullale" wrote:
    When I occlude part of the sphere (either with my hand or with the controller itself by rotating it away from the camera), the ellipse x-y center is approximately the same but the fit ellipse is much smaller, and therefore the algorithm thinks it is much further away. Also, when this happens, the ellipse is definitely not pointing at the center.

    That's weird, I though the Fitzgibbon algorithm accounted for partial occlusion. Maybe the algorithm was replaced or it is only reliable with small occlusions.

    "bullale" wrote:
    I'm interested to see how it works with your coregistration program. Do you think you could give me some metrics on how well it works vs thp's original algorithm? Maybe the RMS of the error? If we can get some hard numbers then maybe it'll motivate the upstream maintainer to finally merge my changes.

    I'll try to implement that.

    "bullale" wrote:
    Do you think I can have access to your coregistration program by this weekend, even if it's incomplete? I'm hoping to use the PSMove in an experiment next week.

    The code is a bit in a flux but I'll refactor it a bit for this week-end. I'll keep the three implementations separate to not lose info about each of them.
    bullaleAuthor
    Up and Coming
    April 15, 2015
    "Fredz" wrote:

    I didn't meant to replace fitEllipse since it already seems more effective than using the bounding box, but I guess it's initialized with integer coordinates where we could use floating point sub-pixel coordinates if it supports that.

    I don't see anything in cvFitEllipse2 or cv::fitEllipse (which it wraps) that relies on the input being integers. We should be OK to supply it with an array of floats.

    "Fredz" wrote:

    That's weird, I though the Fitzgibbon algorithm accounted for partial occlusion. Maybe the algorithm was replaced or it is only reliable with small occlusions.


    If we roll our own ellipse-fitter then we can constrain the major axis angle to point toward the origin. Also having access to the variables solved by the ellipse fitter will allow us to find the sphere 3D position more easily. But, I think this part can be put on hold and returned to when the other pieces are in place; the tracker is already doing very well.

    Let me know when you've done your tests because I plan to clean up the tracker code replacing the original functions with my own and getting rid of a lot of things that are no longer necessary.
    bullaleAuthor
    Up and Coming
    April 17, 2015
    I updated my repo replacing the old tracker algorithm with mine, getting rid of the _cbb functions. I haven't finished cleaning up the code entirely but it's getting there. I got rid of the need to edit the registry when using the PS3Eye. I also changed the order the quaternion is returned in as described here. This needs more investigation. Maybe I should have left it alone, but I'm late for something...
    Up and Coming
    April 18, 2015
    I've not managed to get something working yet, sorry about that.

    I tried to show the real-time difference between the DK2 and PS Move positions after my simple coregistration (not accounting for rotation) but my modification of your implementation with sub-pixel fitting was jerky again and was worse than thp's original one. I'll use your latest changes to see if it's better.

    I've tried to display the RMS error (which I hopefully calculated correctly) but it's not going to be useful without a correct coregistration implementation, the error is currently in centimeters. I guess showing the difference between the two positions in real time may be more useful for now.
    bullaleAuthor
    Up and Coming
    April 18, 2015
    "Fredz" wrote:

    I tried to show the real-time difference between the DK2 and PS Move positions after my simple coregistration (not accounting for rotation) but my modification of your implementation with sub-pixel fitting was jerky again and was worse than thp's original one. I'll use your latest changes to see if it's better.


    Try changing the define value in both these lines to 0 before comparing my tracker to THP's. By default, THP's does smoothing and mine does not. I think we can add smoothing later; it's not useful when trying to measure precision.
    Participant
    April 18, 2015
    I have no programming skills, but let me know if you need an alpha tester. Got 2 PS Moves, a first gen PSEye, DK2, beefy system and Win 8.1 ... just need compiled builds.
    i7-4790K @4.00 GHz, EVGA GTX 980 SC, 16 GB RAM, Win 8.1 64 Bit
    bullaleAuthor
    Up and Coming
    April 18, 2015
    "SputnikKaputtnik" wrote:
    I have no programming skills, but let me know if you need an alpha tester. Got 2 PS Moves, a first gen PSEye, DK2, beefy system and Win 8.1 ... just need compiled builds.


    You can try the UE4 plugin if you want to play around with it in UE4. Even if you don't intend to use the plugin, if you can follow the setup steps (mostly in that page's wiki) to install the PSEye and controllers and report back then that would be very helpful. All the binaries are provided in the above repo.

    You can get a zip version of the repo by clicking on the "Download Zip" button on the right then checking the Binaries\Win64 folder.
    Up and Coming
    April 19, 2015
    I've put the latest version of my setup utility with the sources here : http://www.mediafire.com/download/07crp ... 282%29.zip

    For now it does this :
    - stores correlated positions of the DK2 and PS Move (strapped together) when the orientation of the DK2 is less than 5°
    - after 250 positions are stored, the outliers are removed using absolute deviation around the median
    - the mean distance between the two sets of points is calculated

    Then it displays the corrected position of the PS Move using this calculated distance and it shows the positions of the DK2 and PS Move, the difference before correction and the difference after correction.

    None of my attempts at calculating the rotation have worked out, it's probably beyond my abilities. I've left the code out (Horn and SVD methods) if anyone is interested and I've removed the code about RMS since it didn't make sense.

    You should be able to replace the psmoveapi.dll and psmoveapi_tracker.dll files in the PS Move Setup\Assets\Plugins\x86_64 with other versions if the name of the functions didn't change (psmove_tracker_update, psmove_fusion_get_position). You can modify the PSMOVE_TRACKING_THP and PSMOVE_TRACKING_CBB defines in UniMoveController.cs if you want to use your previous functions.
    Participant
    April 20, 2015
    "bullale" wrote:
    "SputnikKaputtnik" wrote:
    I have no programming skills, but let me know if you need an alpha tester. Got 2 PS Moves, a first gen PSEye, DK2, beefy system and Win 8.1 ... just need compiled builds.


    You can try the UE4 plugin if you want to play around with it in UE4. Even if you don't intend to use the plugin, if you can follow the setup steps (mostly in that page's wiki) to install the PSEye and controllers and report back then that would be very helpful. All the binaries are provided in the above repo.

    You can get a zip version of the repo by clicking on the "Download Zip" button on the right then checking the Binaries\Win64 folder.


    Would you mind also uploading a simple unreal project including the necessary code/blueprint mentioned in the wiki? As I said, I dont' have a programming background and this would speed up the process considerably. I do have UE4 4.7.5 installed though. I'm very interested in helping you test this!
    i7-4790K @4.00 GHz, EVGA GTX 980 SC, 16 GB RAM, Win 8.1 64 Bit
    bullaleAuthor
    Up and Coming
    April 21, 2015
    "SputnikKaputtnik" wrote:
    Would you mind also uploading a simple unreal project including the necessary code/blueprint mentioned in the wiki? As I said, I dont' have a programming background and this would speed up the process considerably. I do have UE4 4.7.5 installed though. I'm very interested in helping you test this!


    I'm afraid UE4 projects aren't really meant to be shared like that. Even the most basic project I could come up with is 1.38 GB. On top of that, the directories that the Visual Studio project point to will be all wrong. There's really no good way other than creating the project yourself.

    I promise it's not that difficult. You really don't need to know any programming. You will never have to edit a line of code. I will expand the instructions to give more details about creating a project in UE4, adding the plugin, and building the project. In the meantime, you should download and install Visual Studio Community 2013.