orientation delay after a significant move

[gb2111]

I have noted that after a significant move of the controller there is a delay and kind of slow-motion for the virtual controller to get its actual orientation. so basically I make a controller move and change or orientation (like you would aim with a gun) and then you need to wait until virtual controller slowly get its position. i made video where behavior is captured. any advise what can be the cause would be helpful https://www.youtube.com/watch?v=-2k0LkupDYE

[gb2111]

@HipsterSloth , @cboulay I winder if you could take look on video, and comment what can be cause in orientation delay. Its not a big issue but bit annoying when many zombies around ;)

[HipsterSloth]

Sorry I kept forgetting to comment on this. Thanks for the video by the way. That helps a lot.

The problem has to do with how the ComplementaryMARG OrientationFilter deals with the accelerometer. Most orientation filters use the accelerometer to tell where gravity (down) is. The problem is that accelerometer also measures linear acceleration. So basically any acceleration on the controller will skew where the controller thinks gravity is pointing. For small accelerations gravity overpowers the linear acceleration signal. But for large linear accelerations like you showed in the video you get a really skewed gravity signal. Because the ComplementaryMARG OrientationFilter always trusts that accelerometer = gravity it'll temporarily get thrown off until it can correct itself.

If a filter has a model of the controller's physics you can better compensate for large skews in the linear acceleration like this. This is actually what the Kalman orientation filter is supposed to handle (if it's properly tuned).

I think the real fix here is basically exposing some tuning parameters for the Kalman Orientation filter so that you can adjust that until it feels correct.

[gb2111]

looks like hard topic for me. actually humans have same issue, e.g. after carousel. i wonder if any recent controllers handle this well. do you know?

[HipsterSloth]

Yeah the Vive and the Touch handle it super well. Both of those controllers have the advantage that you compute an orientation optically (where as the psmove you can only track position optically). This better corrects for drift you get with the IMU. Also I think the IMU on both the Vive and the Touch operate at 100Hz (as compared to 120hz on the PSMove).

[gb2111]

Thanks for info. Will your Kalman do this?

[HipsterSloth]

It should theoretically do better in this circumstance. However it needs a slider exposed in the UI to adjust how heavily it filters. Right now it feels a bit too over-filtered.

[gb2111]

I have noted that after controller calibratoin with all directions with all possible spins the reaction to orientation is so much better that I feel like I have new quality :) But when you calibrate, then tool says it is happy very quickly so I am doing this for a while after it finishes. I wonder if there is something we can do better about this.

[gb2111]

@HipsterSloth @cboulay

Please find video with result of reduced delay in orientation caused by changes in my latest changes. For me personally this is amazing difference based on expierence in games like Serious Sam where this kind of movement if quite often.

https://www.youtube.com/watch?v=YgXj_bKYSV4

Compare it with first video. https://www.youtube.com/watch?v=-2k0LkupDYE

It is 4-5 times faster!!!

Here is the code https://github.com/cboulay/PSMoveService/pull/375

If you have other suggestion how this can be solved then I would be happy to know. I have also seen one reply from HS that its actually something not easy to fix but here it is.