Ver: 1.5.0 | PSMove Positional Tracking Slower | Decreased fling velocity at defaults

[stickman89]

As the title implies. With default positional and orientation filter settings, positional tracking and therefore controller fling velocity on version 1.5.0 is slower and impeded.

It appears as though the PSMove controllers positional movement has friction, almost as if you are moving through water; movement is slower. Floating as such...

When reverting to V1.4.2 with the same configuration and positional/orientation filter settings there is no such anomaly.

[HipsterSloth]

I did make some pretty big changes to how the sensor data was processed. There were a lot of dropped IMU packets before. I'm betting that now that we are getting more IMU packets the filter tuning values need to be adjusted. Which position and orientation filters do you have set in the Controller Settings window?

[stickman89]

Orientation Filter: ComplementaryMARG and Position Filter: LowPassExponential (default value of Max Velocity 1)

I did notice in v1.5.0 an additional paramater was defined in each of the controller configuration files regarding polling and it's timeout, as well as a few other intervals were tweaked in psmoves accompanying configuation files.

Would soley modifying Max Velocity suffice or any other configuration to correct this behaviour, or would you need to modify other integers/data in source before recompiling?

... It's funny. I was trying to slap 'Bob', my unfortunate patient within Surgeon Simulator after having psmovesteamvrbridge just updated. Just for the life of me I. Could. Not... Well easily anyway. Orientation responds in a timely manor, however Position tracking hasn't finished the full travel before being interrupted by the Orientation tracking - causing the velocity path to curl away prematurely.

[stickman89]

Cross referencing an open issue at Cboulay's PSMoveService Github page, which is of relevance. Sounds like a similar report.

https://github.com/cboulay/PSMoveService/issues/588

I have explained the issue and reiterated on what you have mentioned here against that case also.

[stickman89]

Did the latest release version, 1.5.1, offer a potential fix for this? commit: 77c9a54bf455d46ce9660f3e4179d3720394325d .

If it did, it unfortunately still feels a hare slower when tracking controller position when compared with 1.4.2.

Also the hands still feel as though they roll away prematurely, as though the trajectory of the controller is being interrupted early by orientation <- although that's how it feels, it's hard to verify if it is better than 1.5.0, or if it's just placebo.

Something tells me if tracking speed/velocity was increased a bump it would counteract that feeling, or if you can declare a variable within config to drop/skip every other IMU? Like, skip a frame.

It's just weird to see your hands in vr turn when your own, do not feel as though they are - post trajectory of the controller.

Now it's got me wandering... Could that be lens distortion at play? Does the lens distortion between PSEye models differ at all; Are different lenses applied on newer/older revisions of the PSEye Camera?

[stickman89]

Are there any solutions for this issue yet? I am still using the older 1.4.2 release as a result; all releases after 1.4.2 have this problem.

Ideally I would like to migrate to the latest version of psmoveservice and freepiebridge to take advantage of the fixed commandline for hmd startup. PSMoveFreepieBridge15 doesn't contain this fix, and the latest version isn't compatible with 1.4.2.

Update: I've compiled PSMoveFreepieBridge 15 to include Stephen O'Hair's HMD startup parameter commit. Which now works as expected, and allows me to automate everything in a cleaner fashion. Still, I am very confused to as why there aren't more people being vocal about this bug; it prevents the playablity of many games.

Best Regards,

stickman89

[el-bohno]

@stickman89, you are right, thanks for that information. In the latest psmoveservice release it is the same. Since the controller in many games disappears, i use driver4vr. But now with the Alpha Release #8.10.0. Its much faster tracking. Thanks for your advise.

[ZedVR]

stickman89 Hello! I have a big problem with the controllers orientation, and if 1.4.2 works well with freepie bridge 15, I would like to try it out too. Could you please explain it to me: "I've compiled PSMoveFreepieBridge 15 to include Stephen O'Hair's HMD startup parameter commit." What doeas it mean, what did you have to do? Thanks in advance!

Update: Ok I just simply downloaded the above two versions, made a safe copy of the appdata psmoveservice files and my steamvr config file, and just ran them. They work almost the same, only difference is that with 1.4.2 service the juggly moving in tracking pose is gone! Which is good in regards of the tracking, but the orientation is the same... with the default filter settings it gets back to were it should face, but after more time passes, and the more I swing my sabber, it takes more and more time, and the blade's direction wanders away as I move it... unplayable, so will continue to find a solution!

[stickman89]

stickman89 Hello! I have a big problem with the controllers orientation, and if 1.4.2 works well with freepie bridge 15, I would like to try it out too. Could you please explain it to me: "I've compiled PSMoveFreepieBridge 15 to include Stephen O'Hair's HMD startup parameter commit." What doeas it mean, what did you have to do? Thanks in advance!

Update: Ok I just simply downloaded the above two versions, made a safe copy of the appdata psmoveservice files and my steamvr config file, and just ran them. They work almost the same, only difference is that with 1.4.2 service the juggly moving in tracking pose is gone! Which is good in regards of the tracking, but the orientation is the same... with the default filter settings it gets back to were it should face, but after more time passes, and the more I swing my sabber, it takes more and more time, and the blade's direction wanders away as I move it... unplayable, so will continue to find a solution!

In the latest version of PSMoveFreepieBridge, I think from release 16. A commit (https://github.com/HipsterSloth/PSMoveFreepieBridge/commit/f962194f6e1b89ac214be7cc5469c1d6e7f86a34) was merged from Stephen O'Hair's branch that allowed PSMoveFreePieBridge to accept command line startup parameters. Essentially it allows you to declare a HMD or a controller as a head tracking source in a startup script for PSMoveFreePieBridge; meaning you don't have to declare it everytime via the CMD menu at startup.

I coded a WPF C# application that kickstarted all of the processes/services automatically, including launching and starting Freepie and PSMoveFreePieBridge. Since I was on an older version of PSMoveSteamVRBridge (1.4.2), I could only use PSMoveFreePieBridge rel 15. Release 15 didn't allow startup parameters... So I applied Stephen O'Hair's commit to rel 15 source code manually myself and compiled. Best of both worlds.

Something else is causing your drifting issue then. It could be a USB latency issue. It could be occlusion, and/or even cameras detecting the assigned controller colour from another source in your room. I discovered after some troubleshooting, my cameras were detecting the colours from my computer screen that was on and in the background. Every now and then it would inadvertingly and intermittently track my monitor instead. Afterwards I took some extra measures to reduce false detections... I applied some black foam at the tops of my controllers to prevent the controller light from reflecting/boucing the led colour off the plastics. Defused the inside of the PSMove orbs to prevent hot spots of light. Always keep curtains closed, and try to play at night, unless you have some seriously good curtains... Basically the aim of the game is to keep other light sources to an absolute minimum.

Drift can also happen when the CPU is stressed and at 100% load. You can even experience what looks like bad tracking from aggressive GPU Power Management settings, essentially hindering performance. Multi-Display Power Saver caused me havoc once upon a time when I was playing with Nvidia Inspector. Took a "eureka" moment to hone in on that issue. There are so many variables. There even used to be an elliptical orbit issue with steamvr and psmoveservice at one stage that caused controllers to wander off. I haven't had to apply that fix in a long time, so I assume that issue is resolved now...

I suspect it's a latency issue though. Whether caused by a stressed CPU at full load, or simply exceeding your USB interface's available bandwidth. Too many concurrent usb connections demanding high amounts of bandwidth on a single interface will impede on read/write transfer rates for those devices. This will greatly affect the cameras ability to track consistantly, especially at higher framerates (60FPS). Use window's 'Performance monitor' tool to monitor USB related errors, and bandwidth usage.