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 4, 2015
    "bullale" wrote:
    That's great. I'm loving reading the progress.

    Thanks, I wasn't sure anyone was reading. :)

    "bullale" wrote:
    If you want to put this up on a repo somewhere then I will try to contribute if I can.

    I'll need to clean the code a bit before, I would be ashamed to show it in its current state. When I have a good structure I'll create a repo on Github.

    "bullale" wrote:
    How do you propose we work together on the psmoveapi tracker? I don't know if using the upstream repo is a good idea.

    Your repo seems fine, maybe a new branch for the modifications to the blob tracking implementation or even a new repo if you're talking about the new tracking architecture.

    For now I think I'll finish the implementation by just calculating the transform matrix without using nonlinear optimization and I'll have a look at the orb tracking code, using ellipses. It seems to be the biggest culprit in the lack of accuracy for the tracking. I'll see if I can use the calibration for the camera as well, I don't know if there is still code for this in the PS Move API.

    I'll probably have a bit less time to work on this since my girlfriend is back from holiday, but I'll try to do at least a bit of something each night.
    Up and Coming
    April 4, 2015
    "jllabelle" wrote:
    Thanks for all your work, it's really cool to read on your progress!

    You're welcome. :)

    "jllabelle" wrote:
    Are you still planning to release a version for Unity integration?

    I already released a 32 bit version previously using the CL Eye driver but yes, I'll release a new one using the PS3EYEDriver for 64 bit if nobody beats me to it.

    Not a high priority for now though since the tracking is not really 1:1. I've implemented several demos with the PS Move but they're barely usable because of this. Having your arm extended from 0.5 m to 1.5 m while moving doesn't help when you need to point a gun precisely or handle a sword with any kind of accuracy.
    Up and Coming
    April 4, 2015
    By the way, if anyone know where the origin is located for the DK2 tracking that would help. It seems it's a point between the lenses surface but I'd like to have a precise value if possible. IIRC someone from Oculus mentioned that on this forum but I couldn't find the post (if it does exist).
    bullaleAuthor
    Up and Coming
    April 4, 2015
    "Fredz" wrote:

    "bullale" wrote:
    How do you propose we work together on the psmoveapi tracker? I don't know if using the upstream repo is a good idea.

    Your repo seems fine, maybe a new branch for the modifications to the blob tracking implementation or even a new repo if you're talking about the new tracking architecture.

    For now I think I'll finish the implementation by just calculating the transform matrix without using nonlinear optimization and I'll have a look at the orb tracking code, using ellipses. It seems to be the biggest culprit in the lack of accuracy for the tracking. I'll see if I can use the calibration for the camera as well, I don't know if there is still code for this in the PS Move API.


    The problem with using my psmoveapi repo is that it's a fork, and because it's a fork it has no issue tracker, pull requests, or wiki. The owner of the upstream repo is very slow to merge any of my Windows-only changes, so I'm many commits and merges ahead at this point, making it almost impossible to track upstream, making pull requests and issues nonsensical.

    Are you comfortable with Python? If so then I will try to put together a simple Python application that does not use the psmoveapi and put that up on a repo. I find that prototyping algorithms goes a lot faster in Python development than it does in C. If you don't like Python then I can do something similar in C. I should learn how to use C debuggers anyway.

    "Fredz" wrote:

    I'll probably have a bit less time to work on this since my girlfriend is back from holiday, but I'll try to do at least a bit of something each night.

    I totally understand. My wife and daughter just got back from a 3 week holiday so I have a lot less free time.
    bullaleAuthor
    Up and Coming
    April 4, 2015
    "Fredz" wrote:
    By the way, if anyone know where the origin is located for the DK2 tracking that would help. It seems it's a point between the lenses surface but I'd like to have a precise value if possible. IIRC someone from Oculus mentioned that on this forum but I couldn't find the post (if it does exist).

    It's on page 12 of the new SDK docs.
    By default the tracking origin is located one meter away from the camera in the direction of the optical axis but with the same height as the camera.

    The diagram further shows that, when facing the camera straight on, that +X is right, +Y is up, +Z is away from the camera.

    Edit: This is not the same coordinate system that the psmoveapi_tracker returns. It uses the camera pixels, with 0,0 being the top-left pixel in the image (i.e. when facing the camera, +X is left, +Y is down), and for the z-axis the 0 point (in cm) is at the lens (actually the ring around the lens).

    I think it's reasonable to hard-code the psmoveapi to return the X,Y origin as the middle of the camera's optical axis with +X right and +Y up. I wouldn't want to change Z=0,0 to be 1 m away though, that seems rather arbitrary. One thing I don't get is how the DK2 camera knows its pitch so the X-Z plane stays perpendicular to gravity.
    bullaleAuthor
    Up and Coming
    April 4, 2015
    Edit: Deleted diagram and essentially incorrect information. See here for latest tracker algorithm.
    Participant
    April 4, 2015
    Just to let you know, Fredz and bullale: People are reading your posts here (even though I don't understand half of what you are talking about :D ) Keep it up! People are gonna appreciate your great work once it comes to fruition!
    i7-4790K @4.00 GHz, EVGA GTX 980 SC, 16 GB RAM, Win 8.1 64 Bit
    Up and Coming
    April 4, 2015
    "bullale" wrote:
    The problem with using my psmoveapi repo is that it's a fork, and because it's a fork it has no issue tracker, pull requests, or wiki.

    Ok then creating a new repo seems to be the best solution. Maybe a new name should be chosen as well to avoid confusion with the original.
    "bullale" wrote:
    Are you comfortable with Python?

    I've touched it a little but I'm not a big fan. It's very slow and I don't like the syntax very much. I generally don't prototype in C either, I often do it in PHP when it's just for non-realtime testing or in Lazarus (Delphi clone using Object Pascal) for realtime when I need visual feedback, but I've started to use C# for my PS Move Setup app and I like the language (I've been using it a bit in my previous job and now again in my new job).

    With Unity it's also easy to have visual feedback as well and in 3D. Implementing what I've done in anything else would have taken much more time for me.
    "bullale" wrote:
    It's on page 12 of the new SDK docs.

    I just had a look but I've not seen anything about the tracking origin on the HMD itself.
    "bullale" wrote:
    I think it's reasonable to hard-code the psmoveapi to return the X,Y origin as the middle of the camera's optical axis with +X right and +Y up.

    I guess with co-registration this is going to be automatic ?
    "bullale" wrote:
    One thing I don't get is how the DK2 camera knows its pitch so the X-Z plane stays perpendicular to gravity.

    I guess they use both the orientation calculated from the sensors and the position from the LEDs. If the sensors indicate a perpendicular orientation relative to the ground I guess they can simply infer the camera rotation since they know the orientation of the array of LEDs.
    "bullale" wrote:
    I don't know how to embed images

    Just copy & paste a link to an image, select it and click the Img button in the buttons bar. Or simply use Upload attachement if you've got the image on your disk, that's what I did to post my screenshots, but it's a bit unreliable at times.
    "bullale" wrote:
    The following pseudo-code will calculate the 3D position of the sphere given only the inner and outer limits of the sphere in x and y in pixels, after image undistortion of course.

    I'll have a look at the current implementation before trying to modify the algorithm, but I think in the end a complex algorithm will be needed (subpixel edge detection and using most information about the image as possible). But for a first approach that's probably better than the current implementation.
    "bullale" wrote:
    It does assume that the camera's diagonal FOV is 75 degrees.

    I'm not sure we can rely on this kind of assumption, I've not seen any hard data about this value and I think with undistortion it may no longer be valid.
    "bullale" wrote:
    This does not account for the fact that the sensor pixels are not perfect squares. See the sensor datasheet. If the image area dimensions are to be taken at face value, then each pixel is 6.225 um x 6.15 um. This would affect the phi values (60.2604 and 44.6507).

    Nice find, we should need to test if it really has an influence in the end. Maybe by taking photos of a perfect square and see if the side dimensions are equal. Maybe the lenses or some embedded electronics correct this though.
    "SputnikKaputtnik" wrote:
    Just to let you know, Fredz and bullale: People are reading your posts here (even though I don't understand half of what you are talking about :D ) Keep it up! People are gonna appreciate your great work once it comes to fruition!

    Heh, thanks for the support. :)
    bullaleAuthor
    Up and Coming
    April 4, 2015
    "Fredz" wrote:

    I'll have a look at the current implementation before trying to modify the algorithm, but I think in the end a complex algorithm will be needed (subpixel edge detection and using most information about the image as possible). But for a first approach that's probably better than the current implementation.


    "Fredz" wrote:

    "bullale" wrote:
    It does assume that the camera's diagonal FOV is 75 degrees.

    I'm not sure we can rely on this kind of assumption, I've not seen any hard data about this value and I think with undistortion it may no longer be valid.

    We can also use the focal length if desired. See Setion IV a here for basically the same thing as my figure above but using focal length instead of FOV. That paper also has techniques for handling motion blur and estimating speed.

    Unfortunately my printer is not good enough to print out the checkerboard pattern needed for OpenCV's calibration methods. I'll try to print it at work.
    Up and Coming
    April 4, 2015
    "bullale" wrote:
    We can also use the focal length if desired. See Setion IV a here for basically the same thing as my figure above but using focal length instead of FOV.

    Looks like a good idea. Ideally when the undistortion is applied to the image we should rely on the intrinsics parameters of the camera for the tracking (focal length, image sensor format and principal point). This wouldn't require an additional step for the non-square pixels.

    "bullale" wrote:
    That paper also has techniques for handling motion blur and estimating speed.

    That's a very interested paper, bookmarked.

    "bullale" wrote:
    Unfortunately my printer is not good enough to print out the checkerboard pattern needed for OpenCV's calibration methods. I'll try to print it at work.

    Do you know where the image can be found ? It was mentioned that it was available in the PS Move API but I didn't find it.