Oculus Interfering with PSMove

[ambershee]

Firstly, thanks for all the help so far, it's really helped me get up and running pretty quickly and I have game mechanics working already in the engine. Hopefully this is the last you'll hear from me issues-wise.

I initially found that the PSMove would become incredibly unresponsive when running a DK2 alongside it, largely down to huge input latency, and I solved this by moving some USB devices onto a powered hub. I'm still having issues however - it would seem that when Oculus is running, the device is now running smoothly, but seems to be returning the wrong values, particularly left and right tilt. I suspected Oculus' infra-red positional lights might have been interfering with the PSEye, but I've tried covering this over and this does not seem to be the case. Does anyone have any idea what might cause this?

Thanks!

[cboulay]

The PSEye camera has an infrared filter, so I doubt the DK2 LEDs are causing interference. Does it only happen when the controllers are near the headset? The electronics of the DK2 may disturb the magnetic field sensed by the PSMove IMU.

Can you describe the 'tilt' problem a little more to see if we can narrow it down? A video would be good, but I'm sure @HipsterSloth would appreciate an MSPaint drawing.

[ambershee]

I've tested distance, and it seems to happen all the time (I can stand about six feet away and it works fine without Oculus, but suffers when Oculus is on), so I don't think it's the magnetometers themselves being interfered with. Playing with the magnetometer calibration tester also doesn't show anything obvious when the headset is nearby.

Can't really help with anything visual (there's a lot going on to video) - but to describe the problem a little better we have a control scheme that revolves around tilting the controller forwards, backwards, left and right (pitch and roll through wrist rotation) - when Oculus is on, the tilt values become inaccurate, but not consistently so; sometimes movement does not seem to be picked up, and particularly when tilting left and right, the values may outright be wrong and sometimes even in the complete opposite direction.

[ambershee]

Update: It's definitely input latency - I've added some a test widget to my project, and when Oculus is running, PSMove is crippled and often receiving sporadic updates.

[HipsterSloth]

Sounds like the usb root hub that the bluetooth adapter is on is getting saturated. Do you have you have the ps3eye or dk2 on the same root hub as your bluetooth adapter?

[ambershee]

I have tried a few different combinations, but generally the bluetooth adapter has been connected to the hub via the front panel whilst Oculus has been plugged into the back panel.

[HipsterSloth]

Is the front panel actually on a different usb root hub though? (You can tell by looking at your windows device manager and see what usb ports are connected to what root hub). Also you don't have the ps3eye connected to the front ports do you?

[ambershee]

That was an excellent question - I couldn't see it through the device manager, but I downloaded the old USB Viewer and discovered that only the USB 3.1 and USB-C ports were on one root, and every single other USB port was on the other.

I've moved the bluetooth adapter to the 3.1 port and everything else is on the others - there's no input latency any more (hooray! thanks a lot!), but annoyingly control issues still persist when tilting the controllers left and right. This part must be implementation, so I'll do some fiddling - unlike the basic example I do not have a motion controller as a root, I'm instead trying to pipe in the input from a dummy actor that does. I have a hunch that this is causing issues with Oculus leading to the sporadically incorrect input controls. I'll update this thread later with my findings.

[ambershee]

Well, I didn't make any progress - the problem with the implementation seems to be that there are very few ways to get data out of the move controller, and this seems to be partially an issue with how Epic have implemented their motion controls, and partially an issue with the plugin.

The only way I seem to be able to get the tilt of the controller it is via the relative rotation of the motion controller component, as none of the default functions for grabbing input from a motion controller seem to actually return anything, but the real root of my problem is that the motion controller component insists on being glued to the screen rather than actually being parented to whatever I have parented it to. As far as I can tell this is the root of my problem, as when my player is stationary there are no problems, but once moving, if the component isn't keeping up with the camera for whatever reason, everything goes to shit because the relative rotation isn't correct. If I could either leave the motion control component stationary in the world (which is what I have tried to do by having it on another actor), or otherwise access the raw data from the motion controller rather than relying on unreliable transforms from an actor in the world that is lagging behind the player, then things might be a bit better.