D435i no longer returns frames after first application run #10141
Comments
|
Hi @Brac24 May I first confirm that you are closing the program using the 'X' at the top of the window to make sure that the program has been closed down properly, please? |
|
Hello @MartyG-RealSense thank you for the reply. Yes just closed the terminal completely and started a new terminal session and tried running rs-depth and got the same error. |
|
I note that you are using kernel 5.11.0-44-generic. The librealsense SDK only currently officially supports up to kernel 5.8 at the time of writing this. Whilst librealsense can work with unsupported kernel versions, there may be unpredictable consequences in regard to stability.
If your project is unable to change its kernel version then you can instead build librealsense from source code with CMake using the RSUSB backend install method and its CMake build term -DFORCE_RSUSB_BACKEND=ON This type of build is not dependent on Linux versions or kernel versions and does not require patching. If you have not already used this method, installation instructions can be found at #9931 (comment) |
|
Got it @MartyG-RealSense . What about this? #9727 |
|
You are correct, a feature contributed by a RealSense user enabled patches for kernel 5.11 and was released as part of librealsense 2.50.0. I was unaware of this addition, so thanks very much for highlighting it! My interpretation of the available information is that the patch for 5.11 would be applied using the same method as when support for kernel 5.8 was added, by using the patching instruction below. ./scripts/patch-realsense-ubuntu-lts.sh |
|
Well now I don't know what happened but I did a sudo apt-get dist-upgrade and then pulled in changes into my local master branch from the development branch in this repo. Now when I run ./scripts/patch-realsense-ubuntu-lts.sh I get the error - fatal: You need to specify a tag name Seems to be some sort of git tag issue. Not sure if pulling from the development branch caused the issue. I thought the changes from #9727 weren't merged into master yet that is why I pulled from development. |
|
The changes in #9727 were included in the master 2.50.0 release that was published on 11 November 2021, as it is listed on the 2.50.0 release notes under the Bug Fixes and Enhancements section. https://github.com/IntelRealSense/librealsense/wiki/Release-Notes#release-2500 |
|
I was not able to fix the issue with applying the patch but I got to original issue fixed by rebuilding with the following cmake flags |
|
Details of the advantages and disadvantages of RSUSB versus patching can be found by going to #5212 (comment) and scrolling down through the linked-to comment to the section headed What are the advantages and disadvantages of using libuvc vs patched kernel modules? |
|
I kept getting issues where after a while the camera would just stop working and my machine would no longer even detect it. I want to try applying the patch but it looks like I'm getting an issue with the scripts/patch-realsense-ubuntu.lts.sh script here It doesn't set the variable to anything. The kernel_full_num variable is 5.11.0-46 Not sure if that value is right or wrong. |
|
Ok so I had actually upgraded the kernel to that -46 version so the above issue was resolved reverting back to 5.11.0-44 kernel version. I'm currently building the patched kernel modules and will try it out. |
|
So I built the patch modules but I keep getting modprobe Exec format error when replacing videodev which I think is here librealsense/scripts/patch-utils.sh Line 207 in c94410a |
|
As you mentioned, disabling Secure Boot in the computer BIOS can be a solution for the issue, as described in #1225 (comment) and #3354 (comment) If that does not work, a RealSense team member at #3354 (comment) describes a reset process that can be performed before the patch script is run. |
|
Hi @Brac24 Do you require further assistance with this case, please? Thanks! |
|
Just a data-point, I ran into the same issue when the script was trying to load the .ko modules, when I was using 5.11.0-48 generic. I downgraded to use to kernel 5.11.0-25 -generic, and this version looks to be what the patch was created against. Once I switched to using this kernel, the respective .ko modules loaded successfully. |
|
Thank you @kronos30. So I just did a fresh install of Ubuntu 20.04 with the 5.4.0-96-generic kernel. I followed the installation for Linux Distribution here https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md. I still get an issue with simply running rs-depth. If I run it the first time it works well. As soon as I close the program with Ctrl-C and then re-run rs-depth I get the follwing error: At this point I don't think this is kernel issue. No idea how to proceed. My main goal at the end of the day was to be able to use my desktop for some development which might ultimately go on a jetson nano. Just for completeness here is the verification that the kernel was updated successfully during the installation |
|
Hi @Brac24 If you are using the C example program rs-depth, do you experience the same problem with the other C examples? https://github.com/IntelRealSense/librealsense/tree/master/examples/C |
|
I will try it later today |
|
Thanks very much, @Brac24 - I look forward to your next report. Good luck! |
|
Hello @MartyG-RealSense so I tried both rs-distance and rs-color and yes I do experience the same issue with both. I have to physically disconnect and reconnect it again and then it will work. Same thing occurs if I run realsense-viewer, close, then reopen realsense-viewer. Turning on the stereo module within realsense-viewer will show the error that frame did not arrive within 5 seconds. I would have physically reconnect device for it to work again. |
|
So I tried running the rs-hello-realsense example from here https://github.com/IntelRealSense/librealsense/blob/master/examples/hello-realsense/rs-hello-realsense.cpp This would work every other time without needing to unplug the device. So it would run correctly, then close with ctrl+c, then run it but this time I would frame didn't arrive error, rerun again and it would work, then close with ctrl+c, then rerun and another error and so on. Below is what I mean that it would work every other time. I was printing out some messages for debugging which is why there is weird messages there. I tried using the rs2::pipeline::stop() function but that didn't seem to make a difference either. |
|
Did you launch rs-hello-realsense by inputting rs-hello-realsense into the Ubuntu terminal to launch the pre-built version of the example in the usr/local/bin folder? |
|
No I wrote it out in VSCode and compiled it myself and ran it. |
|
The examples that are bundled with the RealSense SDK have a non-standard build mechanism compared to scripts that you have created yourself from the beginning. With the SDK examples, the whole set of examples are built with CMake instead of just one. Then if one of the examples is modified, you perform 'make' again and it builds only the programs that have had changes made and not the entire set of examples. This process is discussed in #6797 |
|
So I'm using the same Cmake system being used. I took some of the Cmake examples. So I have my cpp file with a CMakeLists.txt. I create a build folder and run cmake .. in that folder then run make -j to compile it. I guess what's causing it to not close correctly? |
|
If the pre-built version of rs-hello-realsense supplied by the SDK in the usr/local/bin folder runs correctly without the 'works only every second run' behavior then this would suggest that something in your build method might be negatively affecting your own build of it. I can only recall seeing this issue in one previous case, in a Jetson discussion several years ago at #840 (I know you are not using Jetson yet). A suggested solution was to patch the kernel. You already tried that in #10141 (comment) earlier in this case and experienced an error though. |
|
I will have to try running that later. |
|
rs-hello-realsense is C++ |
|
So I get the same behavior running the pre-built version where it works every other time. The interesting thing I saw was that first it would work then not work, and then work, and then not etc. But when I expect it to fail I then have to make sure to run it within the next 5 seconds or so or else it won't work at all anymore and I have re-plug in the device. So if you look at the above image, it works on and off but the last 3 times you see it never works again until I re-plug it in and that would be when I would wait too long to run rs-hello-realsense again. |
|
I might have found my issue. I might be connected to a USB 2.0. I have front USB ports that are Blue which I assumed meant they were USB 3.0. I tried plugging in to the back USB ports that are blue with the SS label as well and that seems to be working so I will keep going with that. Thank you again @MartyG-RealSense for all your help. |
|
You are very welcome, @Brac24 - it's great to hear that you found a solution. Thanks very much for the update! |
|
Hi @Brac24 Do you require further assistance with this case, please? Thanks! |
|
Case closed due to no further comments received. |
Issue Description
After I run one of the example applications for D435i, if I close that application and run a new one it will stop working by not returning any frames. Almost like it is still stuck on the other program that I already closed. I built and installed librealsense from source. The only way to fix this issue right now is that I have to physically disconnect it from the USB port and reconnect and then run the application.
The text was updated successfully, but these errors were encountered: