Previously, math_pose_invert would apply a multiplication in the wrong
order. This lead to the position of the 'original' pose being rotated.
This patch fixes that, and adds a unit test to check this case.
Commit e41cc1eec3 added support for the XRT_INPUT_SIMPLE_AIM_POSE pose
input in the QWERTY driver. Unfortunately it didn't change the code that
identifies whether the pose for a controller or HMD is being read.
In the QWERTY driver, the hands are positioned relative to the HMD, so
if you move or rotate the HMD the hands stay in the same place
on-screen. Whether a pose lookup is multiplied by the HMD transform
depends on whether the pose being looked up is that of a controller.
Thus the aim pose would not be positioned relative to the HMD.
Previously the pose on the remote driver controllers would always have
the set pose and the valid-tracking flags set. Leaving the pose set
makes sense (you might want to track how your game behaves when a
controller looses tracking but still has a pose set, for example
tracking issues caused by occlusion) but it wasn't possible to test with
the pose marked as not being tracked.
Therefore this patch deactivates the tracking flags when the controller
is not marked as active.
In an Odyssey+, it seems that before the first IMU sample the frame timestamps
do not make sense and thus can make the SLAM system crash.
Also, this commit enables SLAM submission from start unless specified.
SLAM for WMR headsets now works "out of the box" :)
An isometry is a rigid body transform. In this context I'm using the term to
refer to 4x4 homogeneous matrices in SE(3). I.e., matrices comprised of a
3x3 rotation, a 3x1 translation, and a [0,0,0,1] last row.
This matrix represent both rigid body transforms.
Isometry3f is a 4x4 matrix transform that performs only rotation and translation
(an SE(3) matrix). Its inverse can be computed trivially by Eigen compared to a
regular 4x4 transform.
