Is depth broken in my SR305
I'm using realsense-viewer and I'm not sure if it's a broken renderer or the data is wrong from the sensor but it distance appears to be inverted and only within a 10cm at best.
What setting should I have?
-
I haven’t, no. I opened the box yesterday and freshly installed the RS software for Ubuntu 18.04.Today I installed and ran on Windows 10. The behavior is more to what I would expect although it still reports it as an SR300:Just so you know, I also own a 400 model RS. I’ve had that for some time.
-
It is unusual that your SR305 is being detected as an SR300 but not necessarily bad. In fact, some people prefer getting their SR305 to be detected as an SR300 so that the camera works with old programs that support SR300 but may have problems when the camera identifies itself as SR305.
Do you still need to get the camera to work as desired on the first computer that you tried it on or are you happy to use it on Windows 10, please?
-
The SR305 user in the case I mentioned earlier found that by editing one Librealsense file to disable CUDA in that file only, they could fix the broken depth. They created a forked version of the SDK with the fix built in to make it easier for other SR305 users to replicate.
https://github.com/IntelRealSense/librealsense/issues/6373#issuecomment-630584604
-
Brad Colbert Thanks very much. Documentation on how Librealsense uses CMake as a standard mechanism for building is available at the link below:
https://github.com/IntelRealSense/librealsense/wiki/Build-Configuration
Edit: I am off-shift for the day now but will be back in 7 hours from the time of writing this and will be happy to continue the support conversation. Good luck!
-
Yep, got it. I'm digging into it but have some quick questions mainly about how often some calls are called:
Specifically these:
unpack_z16_y8_from_sr300_inzi()unpack_z16_y16_from_sr300_inzi()std::shared_ptr<pointcloud> pointcloud::create()I'm adding a getenv() switch that allows you to set an environment variable to disable CUDA use even if you compiled it in. getenv() isn't horribly expensive but it's not free, so would prefer to make sure it isn't called 1000X per frame.
-
Thanks for the effort that you have put into debugging this problem!
I do not have information on unpack_z16. I notice though that in the Viewer you are getting a warning message about multiple udev rules being detected, which is a problem in itself. A RealSense team member gives advice for fixing it in the link below.
https://github.com/IntelRealSense/librealsense/issues/6153#issuecomment-605687547
Please sign in to leave a comment.
Comments
22 comments