I've taken the CameraWithCVAndCalibration sample and added a hologram that is positioned over a detected marker in world space. Everything works as expected, except that when the marker is stationary but the head set is moving, the position of the hologram is wrong. That is, if I'm moving to the left, the hologram will be positioned too far to the left until I stop and the hologram drifts back to the correct location. It's as though the localization estimate and camera frame are not time-synchronized, even though I'm using the SpatialLocator::TryLocateAtTimestamp function, passing the timestamp I get from IResearchModeSensorFrame::GetTimestamp.
Is this the correct way to get the location of a frame, and if so, is this the expected behavior? It seems that stationary holograms don't exhibit this same drift under head set motion, so I guess this implies that the SLAM localization error is not the cause of this error. On a related note, is there some limit to the range of timestamps I can pass to TryLocateAtTimestamp, and how is the accuracy affected? Is there actually some sliding window of (time, location) pairs being cached internally? Or does it, for instance, just estimate the location based on the current location, velocity, acceleration, etc?
I've taken the CameraWithCVAndCalibration sample and added a hologram that is positioned over a detected marker in world space. Everything works as expected, except that when the marker is stationary but the head set is moving, the position of the hologram is wrong. That is, if I'm moving to the left, the hologram will be positioned too far to the left until I stop and the hologram drifts back to the correct location. It's as though the localization estimate and camera frame are not time-synchronized, even though I'm using the SpatialLocator::TryLocateAtTimestamp function, passing the timestamp I get from IResearchModeSensorFrame::GetTimestamp.
Is this the correct way to get the location of a frame, and if so, is this the expected behavior? It seems that stationary holograms don't exhibit this same drift under head set motion, so I guess this implies that the SLAM localization error is not the cause of this error. On a related note, is there some limit to the range of timestamps I can pass to TryLocateAtTimestamp, and how is the accuracy affected? Is there actually some sliding window of (time, location) pairs being cached internally? Or does it, for instance, just estimate the location based on the current location, velocity, acceleration, etc?