Device or resource busy on set_option
FrederikVinter opened this issue · comments
-
Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):
- Consider checking out SDK examples.
- Have you looked in our documentations?
- Is you question a frequently asked one?
- Try searching our GitHub Issues (open and closed) for a similar issue.
-
All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)
| Required Info | |
|---|---|
| Camera Model | D400 |
| Firmware Version | 5.16.0.1 |
| Operating System & Version | ubuntu 22.04 |
| Kernel Version (Linux Only) | 6.5.0-26-generic |
| Platform | Desktop. |
| SDK Version | 2.55.1 |
| Language | C |
| Segment | Robot |
Issue Description
I have a sporadic issue with the set_option function causing:
'rs2::invalid_value_error' what(): get_xu(ctrl=1) failed! Last Error: Device or resource busy
(A full coredump can be seen at the end of the message)
Note that the value is within the valid range. The issue will show up sporadically, and is not fixed by hardware resets. I set a range of different settings using the following approach:
rs2::sensor depth_sensor = device.first<rs2::depth_sensor>();
depth_sensor.set_option(RS2_OPTION_EMITTER_ENABLED, 1.0);
depth_sensor.set_option(RS2_OPTION_FRAMES_QUEUE_SIZE, 16.0);
depth_sensor.set_option(RS2_OPTION_ERROR_POLLING_ENABLED, 1.0);
depth_sensor.set_option(RS2_OPTION_OUTPUT_TRIGGER_ENABLED, 0.0);
depth_sensor.set_option(RS2_OPTION_DEPTH_UNITS, 0.0010000000474974513);
Note that the error will show up at different calls to set_option. Also the camera is able to capture images, only changing the settings is not possible.
The error has occured on multiple realsense devices and multiple desktop computers. But >99% of the time it runs as intended.
I have tried
- Updating firmware
- Introducing a delay between calls to set_option
- Using the usbreset tool (https://github.com/jkulesza/usbreset) to reset the usb connection (the issue persisted afterwards)
Any suggestions are highly appreciated.
The following coredump is generated:
terminate called after throwing an instance of 'rs2::invalid_value_error'
what(): get_xu(ctrl=1) failed! Last Error: Device or resource busy
Thread 1 "robot_pose_ultr" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140736421072576) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt -full
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736421072576)
at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = 0x7fffc0628ec0
old_mask = {__val = {8245935278391256437, 16711680, 71777205704392953, 0, 4278856899096962286, 0, 13830551742854778125, 0, 0, 0, 0, 93824992724448, 2, 9223372036854775822, 0, 0}}
ret = <optimized out>
#1 __pthread_kill_internal (signo=6, threadid=140736421072576) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140736421072576, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007fffcca42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#4 0x00007fffcca287f3 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0xd68, sa_sigaction = 0xd68}, sa_mask = {__val = {140736628635296, 1, 140736628635427, 3432, 140736627001825, 5, 0, 140736628635296, 93825029551176, 140736632868528, 93825029551392, 93824992737105, 93824994120408, 140737354125376, 140737353973004, 140737488344576}}, sa_flags = -134368756, sa_restorer = 0x7fffccc1b860 <stderr>}
sigs = {__val = {32, 0, 0, 0, 24, 114, 140736631343168, 140737488344528, 0, 140736627558612, 0, 1, 140736628635427, 1, 93825029551176, 140736626994925}}
#5 0x00007fffccea2b9e in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffcceae20c in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007fffcceae277 in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007fffcceae4d8 in () at /lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x00005555555d2272 in rs2::error::handle(rs2_error*) (e=0x5555578eb850)
at /usr/include/librealsense2/hpp/rs_types.hpp:155
h = RS2_EXCEPTION_TYPE_INVALID_VALUE
#10 0x0000555555647df3 in rs2::options::set_option(rs2_option, float) const
(this=0x7fffffffd730, option=RS2_OPTION_DEPTH_UNITS, **value=0.00100000005**)
at /usr/include/librealsense2/hpp/rs_options.hpp:103
e = 0x5555578eb850
#11 0x0000555555642e73 in RealsenseDriver::set_depth_sensor_default_config(Settings&) (this=0x7fffffffdd30, settings=...)
at src/hardware/realsense/realsense.cpp:309
depth_sensor = {<rs2::options> = {_vptr.options = 0x555555722e98 <vtable for rs2::sensor+16>, _options = 0x5555578eec00}, _sensor = std::shared_ptr<struct rs2_sensor> (use count 1, weak count 0) = {get() = 0x5555578eec00}}
Hi @FrederikVinter Did you install the RealSense SDK from source code with CMake using the -DFORCE_RSUSB_BACKEND=TRUE flag, please? If you did then then when the value of settings is changed with set_option instructions, the SDK may occasionally not be ready to respond to a setting change request if it has been built in RSUSB = true mode. This issue is described at #6952
A solution that has been suggested in the past at #6921 (comment) is to customize the value of a setting called cancellable_timer.try_sleep that can now be found in a file in the SDK source code called polling-device-watcher.h.
For example, change this line:
if( cancellable_timer.try_sleep( std::chrono::milliseconds( POLLING_DEVICES_INTERVAL_MS ) ) )
to:
if( cancellable_timer.try_sleep(1000))
in order to poll settings for changes every 1 second ('1000' milliseconds) instead of only every 5 seconds.
If the SDK is built from source code in RSUSB = false mode (i.e a kernel patch script has been applied to the kernel) then the SDK should poll for changes in settings more often than an RSUSB = true build, meaning that the above edit would not need to be made to the source code.
#5212 (comment) has a good comparison of the advantages and disadvantages of a libuvc-based install vs kernel patching. Scroll down to the section of the linked-to comment headed What are the advantages and disadvantages of using libuvc vs patched kernel modules?
Thanks for the rapid response.
I have installed realsense using this guide. Is it correct that this places us in the second catagory (RSUSB = false + kernel patch)? If so based on the listed advantages/disadvantages I would think that the current install method is the right - reliability is key in my use case.
Any ideas on why i experience the issue with this install method?
The distribution_linux package instructions install the SDK from packages. The kernel patch is included within the packages, so there is no need to apply a kernel patch. This type of build is RSUSB = false. So it does not appear as though your set-option problem is related to response delay from RSUSB.
Next, I would recommend looking at the line depth_sensor.set_option(RS2_OPTION_FRAMES_QUEUE_SIZE, 16.0);
Setting a custom queue size value can be risky as some values may break the streams. If you are using two streams (depth and color) then setting the queue size to '2' should be sufficient. If you feel that you need a larger value then '50' has worked in the past for other RealSense users.
Would 3 then be recommended if the infrared stream is also enabled?
If you have 3 streams enabled then using '3' would be reasonable and logical. '5' should also be okay.
I have made the proposed change and removed calls to set_option that sets the default values. I have not seen the problem for some time now but I do not think is an ideal solution.
The approach of not setting options to their default values when they are already using the default is a reasonable one in my opinion. And if the solution provides long-term stability then it is a good fix. Code does not always have to be perfect so long as it achieves its goal and is not messy.
Hi @FrederikVinter Do you require further assistance with this case, please? Thanks!
No thanks, the issue is solved for now
Thanks very much @FrederikVinter for the update! As you do not requre further assistance at this time, I will close this case. Please feel free to re-open it at a future date if you need to do so. Thanks again!