Using Unity 2017.1 with OVRPlugin 1.18.1 I observe that the reported speed and acceleration of the Oculus Touch controllers are reported as 0 once the controller speed exceeds 10 meters/second. I obtain the velocity using OVRInput.GetLocalControllerVelocity. The acceleration reported just before the values become 0 is typically around 140 meters / sec**2, or about 14g. Are the reported 0 values of velocity and acceleration due to the inertial measurement unit (IMU) in the controller going out of range? I see that the Oculus Touch has an InvenSense MPU-6500 (as does the HTC Vive controllers) and that specs for that device say its accelerometer can report up to +/-16 g. The hardware device does not integrate to get velocity, that must be done by the Oculus SDK. My testing suggests the transition to 0 velocity and acceleration is triggered by velocity > 10 m/s and although it could be out of range acceleration. Such a speed threshold would have to be in the Oculus SDK code if it exists. Needless to say it is quite frustrating to work with closed source libraries like Oculus SDK. Is it possible to get the source code?
Here is an image of the reported Oculus Touch controller path moving it along an approximately 2 meter arc from bottom to top. The pink region at bottom is below 10 meter/sec, the pink position before it switches to yellow is at 9.6 meter/sec and the previous pink position is at 8.5 meter/sec. No frames are dropped with rendering at 90 frames per second. Time between frames is about 11 milliseconds, and the acceleration is around 140 meter/sec**2 at the pink position before positions turn yellow. The yellow region has velocity and acceleration reported as 0. It seems likely all information from the inertial measurement unit is being ignored in the yellow region, with no velocities the Oculus SDK probably cannot predict the pose at a later time, so the path immediately jumps backwards. This hand controller motion was completely smooth done with the arm with a side-arm throwing motion. It was a ping pong loop stroke and not an especially fast one. The path in the yellow region is erratic. Consecutive time points sometimes report identical positions for the controller. Likely the entire position prediction is being done by the Oculus cameras running at a lower frame rate than the 90 frames/second, so it is not surprising that the track quality degrades immensely. Position errors of more than 30 centimeters (1 foot) are likely in this region. The tracking recovers at the top shown in pink with the first pink position after the yellow reporting 3 meter/second and about 6g acceleration. The virtual ping pong ball I was trying to hit would have contacted in the middle of the yellow region -- of course the tracking errors were much bigger than the paddle size and I missed the ball!
Here is an image of the reported Oculus Touch controller path moving it along an approximately 2 meter arc from bottom to top. The pink region at bottom is below 10 meter/sec, the pink position before it switches to yellow is at 9.6 meter/sec and the previous pink position is at 8.5 meter/sec. No frames are dropped with rendering at 90 frames per second. Time between frames is about 11 milliseconds, and the acceleration is around 140 meter/sec**2 at the pink position before positions turn yellow. The yellow region has velocity and acceleration reported as 0. It seems likely all information from the inertial measurement unit is being ignored in the yellow region, with no velocities the Oculus SDK probably cannot predict the pose at a later time, so the path immediately jumps backwards. This hand controller motion was completely smooth done with the arm with a side-arm throwing motion. It was a ping pong loop stroke and not an especially fast one. The path in the yellow region is erratic. Consecutive time points sometimes report identical positions for the controller. Likely the entire position prediction is being done by the Oculus cameras running at a lower frame rate than the 90 frames/second, so it is not surprising that the track quality degrades immensely. Position errors of more than 30 centimeters (1 foot) are likely in this region. The tracking recovers at the top shown in pink with the first pink position after the yellow reporting 3 meter/second and about 6g acceleration. The virtual ping pong ball I was trying to hit would have contacted in the middle of the yellow region -- of course the tracking errors were much bigger than the paddle size and I missed the ball!
