Cannot receive depth frames consistently #7621
Comments
|
Hi @msaliharslan The fact that you have problems on both Ubuntu and Windows computers would suggest that something external to the computers is involved that is used with both computers - for example, the camera firmware driver (stored inside the camera hardware, not on individual computers) or the USB cable. If the camera is able to at least be detected, a good first step would be to perform a Gold Reset of the camera to return it to its factory-new configuration. If the calibration table stored inside the camera is corrupted then a Gold Reset can also correct that problem. You can perform a Gold Reset using a program called CustomRW that is part of the Dynamic Calibrator camera calibration tool. You can install this tool on Linux by following the instructions on page 14 onward of the tool's user guide. Once the tool is installed, you can launch CustomRW in the Gold Reset mode with the command below: Intel.RealSense.CustomRW -g |
|
Hi @MartyG-RealSense thanks for your reply. I followed the instructions and made a gold reset to the device, but, unfortunately it did not work. Nothing has changed. |
|
Thank you very much for the tests. When you use the RealSense Viewer, do you have the camera plugged into a USB 3 port? If you do, is the camera being correctly detected as USB 3? You can tell this by looking at the number beside the camera name at the top of the options side-panel. If it says '3.2' then it is a USB3 connection. If it says '2.1' and the camera is in s USB3 port then the camera is being mis-identified as being on a slower and more limited USB2 connection. |
|
Yes |
|
Thank you. I see that you have depth, color and IMU all enabled at the same time in your image, and a Frames not received error on the depth stream. Problems when all three of these stream types are active is a known-about issue that can occur. It can be corrected in Python and C++ applications written by RealSense users, but I am not aware of a solution for the RealSense Viewer for affected users. You should be able to successfully display color, depth and IMU simultaneously in the rs-multicam example program though, as tests that I have conducted have consistently shown that it does not experience this problem. The rs-multicam program can display color, depth and IMU panels from a single attached D435i camera despite the program's name. https://github.com/IntelRealSense/librealsense/tree/master/examples/multicam |
|
Screenshot is just a sample, I had tried only enabling the stereo module too, it did not work as well. Also, my own c++ application cannot receive any frames either. rs-multicam example says "please connect one or more device", however, other examples (rs-align, rs-capture, C/depth, C/distance) see the device but says "Frame didn't arrive within 15000". C/color example runs and gets RGB frames. |
|
This time I was lucky enough to receive depth frames(still the problem remains). However, I noticed another issue which is the left side of the depth frame is missing as if depth frame is slightly slided to right. Do you think this is related to the original problem? Also, on graph it says that on average 55 frames drop per second, is this normal? |
|
There have been a couple of recent cases involving Frames didn't arrived within 15000 that were resolved by updating to the currently latest SDK and firmware. I see you have the latest SDK 2.39.0. Are you also using the latest camera firmware 5.12.8.200 please? Regarding the frame drop chart, I would not use it as an indicator of performance. It is normal for the left edge of the depth image to be jagged in 2D mode. It is a phenomenon called the Invalid Depth Band. It is described on page 64 of the current edition of the data sheet document for the 400 Series cameras. https://dev.intelrealsense.com/docs/intel-realsense-d400-series-product-family-datasheet |
|
It is already running with 5.12.8.200 |
|
I do not know if this has any significance, I hope it is a clue: 848 x 480 resolution is more problematic than the others. I had received depth frames for all other resolutions(still not consistent) but this one. Also, note that after trying to enable depth stream with this resolution, the others do not work either from then on. |
|
I have investigated your case carefully. The fact that the camera has problems on both Ubuntu and Windows and on multiple Viewer versions leads me to suspect the camera firmware driver that is stored inside the camera. As the camera can be detected by the Viewer, could you try the steps below please:
https://dev.intelrealsense.com/docs/firmware-releases#section-d400-series-firmware-downloads
Bear in mind that RealSense cameras can only have their firmware downgraded 20 times before they can only be upgraded to a newer version once the limit is used up. So the downgrade operation should not be performed multiple times.
|
|
I am sorry to say that downgrading to 5.12.7.100 via realsense-viewer as you suggested did not change anything. |
|
Thanks again for the further update. On Windows, can you confirm whether you experience the problems if you download the standalone executable .exe version of the Viewer from the Assets list at the bottom of the details listing for SDK 2.39.0? https://github.com/IntelRealSense/librealsense/releases/tag/v2.39.0
The Intel.RealSense.Viewer.exe file should be launched from the location on your computer that you downloaded it to by double-leftclicking on the file, and not the Viewer launch icon on the Windows desktop. |
|
When I said I tried on windows I already used that version of the realsense-viewer. Sorry for misleading you. |
|
It is okay! :) May I also ask whether you connect the camera to a USB hub when you use the camera with your Ubuntu and Windows PCs, or do you connect the camera directly to the USB port on the computer? |
|
Directly to computer |
|
Thank you very much for your patience. Next, please see whether the camera is detected if the command rs-enumerate-devices is used. |
|
Camera can be detected. I added the output of the program also, copied here.
|
|
The next test is to unplug the USB cable's micro-size end from the side of the camera, turn the micro connector upside down and re-insert it into the side of the camera (the micro-size USB C port has two-way insertion, unlike the large connector that only inserts one way up). |
|
Well it is not affected by orientation of the cable. Also, I have an update, my c++ code works with librealsense version 2.28.1 but not with 2.38 an 2.39. However, there are regular frame drops both for RGB and depth. On realsense-viewer 2.28.1 depth frames arrive except for 848 x 480 resolution. Moreover, after trying to enable this resolution, frames does not arrive for any other resolutions as well and my c++ code stops working until I un-plug & re-plug the device. |
|
In the RealSense Viewer, are you able to receive infrared frames successfully in the same way that you can with color and motion frames? Also in the Viewer, could you test whether performing a hardware reset before you begin streaming makes a difference? You can do this by going to the More option at the top of the Viewer's options side-panel and selecting Hardware Reset from its drop-down menu.
|
|
Hardware reset has no effect, but after trying to enable at 848 x 480 hardware reset makes other resolutions work just like re-plugging. For infrared frames, they behave like depth, i.e. they work fine for resolutions other than 848 x 480. At 848 x 480 one set of infrared frames (one from each) arrives after about 5-7 seconds. However, IR pattern is not visible in the images. Disabling emitter or enabling just one infrared does not change anything. I believe my issue is very similar to #3376, for that case 640 x 480 is problematic, for me it is 848 x 480. Also, on realsense-viewer 2.28.1 in the output section I see REC error. |
|
At this point it may be worth trying to build librealsense from source code with the RSUSB method that is not dependent on kernel versions or Linux versions and does not need patching. This should determine whether or not the problem is related to the kernel, since RSUSB does not rely on the kernel to operate. RSUSB is enabled by using the CMake build flag -DFORCE_RSUSB_BACKEND=true |
|
848 x 480 resolution still is not working |
|
I have researched the case completely again from the beginning but cannot find an explanation for the behavior. So I will consult with Intel about it. Thanks again for your patience. |
|
Hi again @msaliharslan I have received guidance for your case.
As you have access to a Windows PC, it will be easiest to use the Dynamic Calibrator tool if you download the Windows version from the link below. The user guide for the tool can also be found at this link. https://downloadcenter.intel.com/download/29618/Intel-RealSense-D400-Series-Dynamic-Calibration-Tool If you would prefer to use the Linux version of the Dynamic Calibrator tool, page 14 onward of the user guide has Linux installation instructions. |
|
Dynamic calibration did the trick, now it works!! Thank you. |
|
Great news - thanks for the update! :) |
Issue Description
I was able to run my code and collect depth information from the device then after a few days I was not. During those few days I did not use the camera. On realsense-viewer I am rarely able to receive depth frames for certain image size and frame rate configurations but not for others. In other words, most of the time realsense-viewer says no frames received regardless of configuration. I tried with other versions of realsense-viewer(2.39, 2.38, 2.27) and on a windows pc the problem persists on those platforms as well. On the other hand, I can consistently receive color and motion frames on realsense-viewer. However, I cannot receive color frame with my C++ code with which I used to.
The text was updated successfully, but these errors were encountered: