bpeck, that sounds like you’re using psmove-pair-win? You have to cycle through the psmove-pair-win process 5+ times. Keep tapping the psmove button while the display updates.
Are you using Windows 8.1 or Windows 7? If you’re using Windows 7, then you can try connecting with this method. It’s essentially the same under the hood, but the linked method has more feedback so you might have more luck. You can also try this in Windows 8 but it’s incomplete. The missing step, that psmove-pair-win does, is a registry edit necessary in Windows 8. Here’s the original thread about the registry edit.
I made a pretty significant update to the plugin today, which required some changes to the psmoveapi. This may change the way you use it.
The default z=0 position is now 100 cm away from the camera. This is the same as used by the Oculus Rift DK2
I figured out what was wrong with orientation. It should now work properly. Though yaw drift is still a problem. More work needs to be done on the sensor fusion algorithm.
You can now request that the pose be reset. This will reset the yaw (assuming that gravity is normal to the horizontal plane of the controller, with the sphere pointing), and it will reset position.
The BluePrint diagram in the Wiki now suggests getting the player controller position, adding a constant offset (e.g., +15, 0, 0), and adding the controller position.
Protip for Oculus: Reset the HMD Position and Orientation, then place the controller horizontal (sphere pointing right) and press a button on the controller (I use select) to reset the controller pose.
I just updated my system to windows 8.1 and am reinstalling this plugin. Am I supposed to follow the steps for the registry edit listed above? Also my move controller keeps connecting and disconnecting from my computer, (I think that it might just need some charging) but the light doesnt stay on when I have it connected to the usb
No, the registry edit is no longer needed. See the wiki for current setup procedure.
As for the frequent disconnecting, others have reported that too but I have never experienced it. It might be BT-dongle specific, or it might be the device itself. One user said that he had two controllers, and one of them frequently disconnected while the other was OK.
I think it was a bad device. I returned it, but they didn’t have any more used ones so I’m just working with 1 unit now.
It’s an Asus Impact VI board, with whatever on-board broadcomm bluetooth adapter built in. I’ve got an asus bt-400 as well, but I haven’t tested with it.
My big question is now:
How do i setup the animation blueprint to correctly move the arms based on the move position. I have a fabrik node driven by data from the controller, but honestly, I’m not sure about the animation side. Do I set the main bone to the hand, and the root bone to upper arm? How do I feed the transform in so that it’s not backwards?
I tried to look at the leap-motion sample, but they drive every bone manually from the data. My suspicion is that this isn’t hugely difficult, it’s just something I’ve never monkeyed with.
TLDR - How do I setup a skeleton to Ik the arms/hands based on move position?
@Lord_Pall I have the asus bt-400 as well. On my windows 7 machine the move controller paired after messing around with some drivers but forgot which ones so I may find it hard to replicate that. As for my controller on this machine when I connect it via USB I see on my device manager that it connects for a second then disconnects. It does this about three times before it doesn’t come back. Was this something along the lines that happened to you?
Also I see a motion controller bluetooth device on my device manager even when the controller is unplugged but I still cannot get it to connect consistently.
So the bt400 won’t even work on this machine due to the onboard bluetooth controller. I believe it’s the same chipset though.
I can get it working sometimes. Light comes on, calibrates, and I Can work for a bit. When I’m testing, usually task switching away, the light turns off and the move turns off as well.
When that happens I just restart the editor.
WHat’s more problematic is the rotation data. Roll (wrist) seems to be solid, but yaw and pitch are almost non-existent. Is that just a side effect of the optical tracking?
Update - Losing connection seems to be related to task switching. Turning off the “Use less cpu resources” under misc in preferences seems to have fixed it.
You’re not supposed to use USB for testing. Setup uses USB to sync, but then it’s all bluetooth.
The shuffle is as follows. Some of these might be superstitious steps.
Follow pairing instructions. Get it setup. Make sure you can run the tracker test in the plugin binaries folder.
Plug move into usb. Unplug from usb. Wait for it to turn on and go solid. Run the editor. When it pops up, open your movecomponent blueprint. See if the camera turns on. Wait for the light to blink on the move, point move at camera until it goes solid. Hope it doesn’t turn off.
Work with it.
If you crash, and the camera red light does not turn off, unplug and replug camera.
I plug the move into the usb plug and unplug every time it crashes as well, but I’m unsure if that’s needed.
@Lord_Pall my diconnecting problems are happening in the syncing process I can’t even run the psmovepair nor the pair-win exe because my controller connects and disconnects repeatedly never allowing the programs to connect the move controller. In my device manager I see that when on usb it plugs in as an input device but again it disconnects to quick to do anything with it
Today I made a pretty significant update to the plugin. I came here to say: DO NOT DOWNLOAD THIS UPDATE! I should have kept it in a separate branch. oh well.
The updated plugin has a functioning implementation of coregistration with the DK2. Unfortunately, it requires access to a IHeadMountedDisplay member variable that is not exposed in C++, so I had to modify the engine source code and recompile the engine itself. See here for details. I may have to make one more small change to the engine to get access to another member variable.
Even if you were to patch the engine, there are still a couple things I need to tweak. (1) The controller is way out of position when not using the HMD. I know how to fix it but I haven’t had time yet. (2) The workspace where the coregistration works well is smaller than I hoped. I will try to recalibrate my camera and if that doesn’t help then I’ll spend a little bit of time tracking this down.
Assuming I can get that working well, the next step is to sort out orientation (mostly in the psmoveapi).
Here’s a quick video demonstrating how well (or not well) it works for me. You can see the yaw drift.
The coregistration was done before recording this video. I added some smoothing to my tracking algorithm. It definitely reduces the jitter, but it also adds latency . I might disable XY smoothing and only keep the z-smoothing. Having added latency in only one dimension might be less noticeable.
Hey!
Having a really hard time getting the controllers paired, how long did it take you gus using the psmove-pair-win executable?
Any updates on this, should I still compile the Engine from source I guess?
In any case your work is much appreciated on my end
I’m holding off on publicizing directions on how to set everything up until I have a chance to implement Epic’s generic motion controller interface. This will make it possible to switch between using the PSMove and using (e.g.) the Vive controllers pretty easily. It should also greatly simplify the instructions. I hope to do this next week.
Even when that happens, it may still be necessary to patch and compile from source. I finally made a pull request so I hope that speeds things along. If you are feeling adventurous then you can try my ihmd_baseOffset branch of UE4, but I won’t be able to provide any support. (As of right now, this branch doesn’t compile but I’m almost certain it is not related to my simple patch and is instead a problem with Epic’s master branch)
And finally, the yaw drift is still not solved. It will probably be necessary to replace the current AHRS (Madgwick) with either a Kalman filter or maybe even a custom orientation algorithm. I don’t know when I’ll have the time to do that, though.
I’ve never used MotionInJoy but I’ve only heard bad things about it (along the lines that it installs spyware).
Anyway, I’m pretty sure the MotionInJoy drivers are incompatible with the psmoveapi, which is what the plugin depends on. Brendan Walker of PolyarcGames has modified the plugin and along the way made the wiki a lot more extensive. We’re working together on back-porting some of his changes directly to psmoveapi (so they can be used by Unity if necessary) and on some other changes. The plugin and psmoveapi are rapidly changing so I would recommend not developing against it at the moment. I’ll make an announcement here when everything is tightly integrated.
Anyway, you can take a look at Polyarc’s wiki for more detailed setup instructions.
And you can take a look at a simple UE4 project that I put together for testing. Note that as of this writing, the plugin requires some changes to the UE4 source. I have a pull request out but as far as I know it hasn’t been merged (yet?). It’s a small change anyone that’s willing to build UE4 from source can do themselves. See here. I hope it gets integrated into UE4 at some point so I don’t have to keep telling this to people.
Take a look at https://.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/Engine/Private/PhysicsEngine/PhysXLibs.cpp
Now to the interesting part:
Check out this file https://.com/EpicGames/UnrealEngine/blob/release/Engine/Source/ThirdParty/PhysX/PhysX.Build.cs
Around line 150 you will find this
. I might disable XY smoothing and only keep the z-smoothing. Having added latency in only one dimension might be less noticeable.
