Skip to main content
bullale
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

    Show previous replies
    cybereality
    Inspiring
    July 18, 2015
    For the YouTube tag, just use the video code (not the full url).
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    Fredz
    Up and Coming
    July 18, 2015
    IIRC I had this kind of drift some months ago, but I don't have it anymore with Unity and the Madgwick algorithm implementation in C#. I'll try again with the C algorithm to see if there is a difference. I guess you did calibrate the PS Move magnetometer ?
    bullaleAuthor
    Up and Coming
    July 21, 2015
    I compared your C# Madgwick and the one in the psmoveapi. They are identical except for the beta parameter. You are using 0.03, psmoveapi is using 0.5. I tried 0.03 and I had the same alignment problem as you described. I tried 0.1 and I get good (but not perfect) alignment and substantially less drift, but not zero drift. It's a good compromise for now.

    There are a couple other things I can take a look at. For one, the accelerometer readings for one of my axes seem to range between -0.96 and +1.04 (all other axes are -1 to +1) so there seems to be something off there. I think it's also possible to threshold the gyroscope so anything below noise (obtained during some resting calibration) is treated as 0. And there are also other AHRS algorithms to try.

    If we can get the orientation to near perfect then I will look at using dead-reckoning for fast positional updates then using the optical tracker only for corrections to the position.

    Unfortunately, I have to move on to other projects at work for a little while. I'll come back to this when I can.
    Fredz
    Up and Coming
    July 21, 2015
    "bullale" wrote:
    You are using 0.03, psmoveapi is using 0.5.
    I took the value directly from the paper, I don't know why the PS Move API uses 0.5 by default, looks a bit high.

    "bullale" wrote:
    There are a couple other things I can take a look at. [...] And there are also other AHRS algorithms to try.
    Yes, I've been reading a lot of papers lately and it seems the Madgwick algorithm is not the best in town contrary to what I thought (and what the original paper claimed).

    "bullale" wrote:
    If we can get the orientation to near perfect then I will look at using dead-reckoning for fast positional updates then using the optical tracker only for corrections to the position.
    Than looks like a good idea. Making it an independent service like you previously mentioned that can operate at the max refresh rate of the sensors and camera would be nice as well.

    "bullale" wrote:
    Unfortunately, I have to move on to other projects at work for a little while. I'll come back to this when I can.
    Too bad, I've had a little less motivation for the past weeks so I've not progressed much on the orientation, but I hope I'll be able to motivate myself to finish this. Good luck for your other projects.
    bullaleAuthor
    Up and Coming
    July 22, 2015
    "Fredz" wrote:

    "bullale" wrote:
    There are a couple other things I can take a look at. [...] And there are also other AHRS algorithms to try.
    Yes, I've been reading a lot of papers lately and it seems the Madgwick algorithm is not the best in town contrary to what I thought (and what the original paper claimed).


    Can you list the other algorithms (and sources if you have them handy)? If I can find some code for them and it's not under license then I may spend a couple hours trying to get it to work. Right now the psmoveapi does not enable Madgwick by default because it's under GPL, and as a result there are a bunch of checks and initialization code to see if orientation is enabled. Having a less restrictive license for another algorithm would allow for orientation to always be enabled and therefore we could get rid of some compile-time options and other runtime checks. Not a big deal but it would simplify the code.
    Fredz
    Up and Coming
    July 22, 2015
    "bullale" wrote:
    Can you list the other algorithms (and sources if you have them handy)?
    Basically extended and linear Kalman filters, but they're more complex to implement and I've not seen open source implementations yet (didn't search for that specifically). In the paper it's said that the gradient descent algorithm is as good as EKF but I've seen several other papers showing that it's not the case. And the fact that there is a weird parameter to fine tune doesn't help as well.

    "bullale" wrote:
    Having a less restrictive license for another algorithm would allow for orientation to always be enabled and therefore we could get rid of some compile-time options and other runtime checks. Not a big deal but it would simplify the code.
    If the code is in a service that is only accessed by IPC I guess there shouldn't be a problem with the GPL license.
    Fredz
    Up and Coming
    July 27, 2015
    I've been playing a bit more with the Madgwick algorithm and I can reproduce the drift reliably. I thought the PS Move sensors were not up to the task but I can get the same problem with the DK2 using a 1.0 value for beta. With this a small rotation can provoke a gimbal lock problem (180° systematic rotation) for either the DK2 and the PS Move.

    The PS Move sensors are lower quality than the DK2 so it can happen with lower values of beta. If the values are low (< 0.5) it looks like a drift problem, but I think it's a problem with the algorithm itself. Time to try to implement Kalman filters I guess.
    bullaleAuthor
    Up and Coming
    September 14, 2015
    Sorry for the silence. There's been a lot of work on the psmoveapi, and on the UE4 plugin.

    Brendan Walker of PolyarcGames found a bug in the Madgwick implementation and went ahead and made a variant of the Madgwick that does something or other with Kalman filtering and gradient descent. Honestly I haven't looked at the code. All I can say is that there is almost no yaw drift now.

    The other big contribution from him was to make the UE4 plugin implement the IMotionController interface, so using the PSMove in UE4 is a lot like using the Vive (in coding, not in performance).

    There's a sample UE4 project that you can build and run to test it out.
    See here.

    Before you can actually use this, you need the PSMove paired and connected, the PSEye installed, you need to do a magnetometer_calibration, and you need to coregister_dk2. Once all that is done it should be quite easy to use, I hope.
    bullaleAuthor
    Up and Coming
    September 14, 2015
    Fredz,

    Do you think you can update UniMove to use the latest psmoveapi (my fork)?
    Fredz
    Up and Coming
    September 30, 2015
    Hi, I've not been following the forum lately, I'll have a look.

    You may have a read at this for optical tracking : https://www.reddit.com/r/oculus/comment ... w_optical/
    Terms & ConditionsAccessibility statement