-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drift #10
Comments
Before I try reproducing it, I assume you are using the depth tracker (ICP) and not the colour tracker? If so, then only the intrinsic calibration of the depth camera is used and maybe the OpenNI internal conversion of disparities to depth values. Since this calibration of the depth sensor is used both for reconstruction and for tracking, it should not cause any drift, regardless of how wrong it is. Also, we are not using OpenGL- or CUDA-related images anywhere, which are notorious for the +0.5 coordinate bugs. I doubt there is any such issue in the current implementation, though. That leaves the last of the three ideas, the TSDF values. These values are not actually returned anywhere for tracking, but they are used for raycasting, and it might be that a small bias in the raycasting leads to the observed drift. This would be a nightmare to track down. I'd assume in this case the direction of drift would vary depending on the scene context. Could you try and verify this? Of course it might also be something completely different. I might find a bit of time to look for the problem myself... |
I'm using the standard depth tracker (from a clean git clone/build) and OpenNI2 with an asus xtion pro. I'm suspecting the third option, since I ran into something similar earlier when trying to port my own sdf-tracker to the InfTAM framework. I kept getting slight offsets on the values I was reading out from it when fusing/evaluating into/from the tsdf without applying any transformations and not moving the camera. I didn't keep probing because I assumed I was doing something wrong (some transposed index or something) since, as far as i understand, the Ren tracker uses the TSDF values directly, too. Maybe the robust loss function it uses has been set to throw away the offset points as outliers though? (just brainstorming here). A way to verify it would be perhaps to:
If you do this, an example code snippet for how to do this would be helpful :) |
Re-merge master into makeitfaster
Not sure if anything has changed to address this issue specifically, but it doesn't appear to be happening in the current version so I will close this issue. |
Hello, I have encountered the same problem. My problem is that the disparity parameters in calib.txt has not been replaced with a new sensor after the Azure kinect DK has been replaced. hope it can help you |
Experiment:
Expected result:
slight surface degradation due to quantization and continuous integration without motion
Actual result:
Possible reasons why it happens:
The text was updated successfully, but these errors were encountered: