librealsense: RSUSB backend fails to set options

Required Info
Camera Model D415/D435
Firmware Version Signed_Image_UVC_5_12_6_0.bin
Operating System & Version Debian 10 & Raspbian 10
Kernel Version (Linux Only) 4.19.59 & 4.19.118-v7l+
Platform PC x86_64 and Raspberry Pi 4
SDK Version 2.36.0, latest master f7cdf6e8961e1709f6d864bdb33095c00a671ca7
Language C++
Segment others

Issue Description

When building the SDK with FORCE_RSUSB_BACKEND=ON, the emitter, auto exposure and region of interest requests don’t always work on a D415/D435. Here’s what the errors are:

Set region of interest
RealSense error calling rs2_set_region_of_interest(sensor:0x607000131d90, min_x:256, min_y:192, max_x:384, max_y:288):
 failed to set power state when setting auto exposure region of interest.
Setting auto exposure off
RealSense error calling rs2_set_option(options:0x607000131d90, option:Enable Auto Exposure, value:0):
 set_xu(id=11) failed! Last Error: Resource temporarily unavailable when toggling device auto exposure settings.
Enabling emitter
re-enable auto exposure
Set region of interest
RealSense error calling rs2_set_region_of_interest(sensor:0x607000131e00, min_x:256, min_y:192, max_x:384, max_y:288):                                                                      
 hwmon command 0x75( c0 120 100 180 ) failed (response 0= Success) when setting auto exposure region of interest.                                                                           
Setting auto exposure off
RealSense error calling rs2_set_option(options:0x607000131e00, option:Enable Auto Exposure, value:0):                                                                                       
 failed to set power state when toggling device auto exposure settings.
Enabling emitter
Sensor does not support RS2_OPTION_EMITTER_ENABLED
re-enable auto exposure
RealSense error calling rs2_set_option(options:0x607000131e00, option:Enable Auto Exposure, value:1):                                                                                       
 insufficient data writen to USB when toggling device auto exposure settings.

Two things of note:

  • Region of interest fails to set with two different errors: first with failed to set power state, then with response 0= Success. The second one is an oversight in the RealSense SDK that confused me for a while, but happens because of this part of hw-monitor.cpp where the firmware is supposed to respond with newCommand.cmd, in this case 0x44, but it responds with zero, which is then parsed as hwmon_response where 0 means hwm_Success.
  • The operations sometimes fail and sometimes succeed. In the above example, ROI fails to set followed by auto exposure failing to set, then the emitter is toggled successfully, followed by auto exposure toggling successfully, after which region of interest fails to be set followed by the sensor suddenly not supporting RS2_OPTION_EMITTER_ENABLED at all.

Other errors the requests sometimes produce are:

RealSense error calling rs2_set_region_of_interest(sensor:0x12f65c8, min_x:512, min_y:288, max_x:768, max_y:432):                                                                           
 set_xu(ctrl=1) failed! Last Error: No such file or directory when toggling device auto exposure settings.                                                                                  
RealSense error calling rs2_set_option(options:0x12f65c8, option:Enable Auto Exposure, value:1):                                                                                            
 map::at when toggling device auto exposure settings.

Here’s a minimal program demonstrating this.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 42 (3 by maintainers)

Most upvoted comments

After discussion with Intel, I have filed an offcial bug report. This is not confirmation that it definitely is a bug, but rather that it should be investigated to determine whether or not it is one.

Hi @SirDifferential You mentioned earlier that “I would prefer this to be kept open until it’s verified as a bug and fixed, or until there’s verification that this is simply invalid usage of the API from my part.”

I will ask about this case within Intel in order to bring the case to a resolution, one way or the other.

@SirDifferential , I’ve looked up the mentioned code and there are definitely things you can improve:

  1. https://github.com/SirDifferential/minimal_rs_advancedmode/blob/master/main.cpp#L397-L406 The ROI functionality is not available for all sensors. You have to check whether the sensor supports it before making the call (to avoid receiving errors)
    if (sensor->is<roi_sensor>())
    {
        sensor->as<roi_sensor>().set_region_of_interest(<TBD>);
    }
  1. In case the sensor supports “ROI” interface you need to ensure Auto-Exposure (AE) is ON before making set_roi call - it can’t work with Manual Exposure. And currently this check is omitted in the code. This is consistent with

The operations sometimes fail and sometimes succeed

as when you reach that code segment the AE state is unverified.

after which region of interest fails to be set followed by the sensor suddenly not supporting RS2_OPTION_EMITTER_ENABLED at all.

When iterating over all the sensors available you have use use heuristics to differentiate between sensors as the controls that you’ve selected do not apply to all sensors - set/get RS2_OPTION_EMITTER_ENABLED will fail for RGB. At the minimum you apply the check->use guard aproach:

    if (sensor.supports(ABC))
    {
        sensor.set_option(ABC);
        ....
    }
  1. The above applies to both RSUSB and v4L drivers implementation so it is strange that you encounter this only with RSUSB. Can you confirm that this code work correctly with v4l backend?.

The official bug report I sumitted on October 23 2020 is still active but there is no further information that I can provide at this time.

In a recent discussion about how events / callbacks can be missed when using RSUSB, advice was provided about changing the timing of timeout events:

https://github.com/IntelRealSense/librealsense/issues/6921#issuecomment-668652875