F200: cpp-config-ui crash when setting accuracy to 0

[floe]

Was just playing around with the cpp-config-ui example on my F200, got the following when setting accuracy to 0:

rs.error: TemperatureControlLoop: libusb_bulk_transfer(...) returned LIBUSB_ERROR_TIMEOUT
RealSense error calling rs_set_device_option(device:0x2546018, option:F200_ACCURACY, value:0):
    UVCIOC_CTRL_QUERY:UVC_SET_CUR error 5, Input/output error

[floe]

Not a big deal, just thought I'd mention it here.

[floe]

Similar error with motion range:

rs.error: TemperatureControlLoop: libusb_bulk_transfer(...) returned LIBUSB_ERROR_TIMEOUT
RealSense error calling rs_set_device_option(device:0x221b5e8, option:F200_MOTION_RANGE, value:2):
    UVCIOC_CTRL_QUERY:UVC_SET_CUR error 5, Input/output error

Device needs to be re-plugged afterwards to work again.

[ddiakopoulos]

Thanks! We'll be working shortly to reconcile our internal bug tracker for this repository with the external one since there's a few controls in there like this.

[sgorsten]

My bad, the F200 Accuracy hardware control only has a range of 1-3. I've pushed a commit (05c8f21) to fix this range.

The Motion/Range control should be valid in the range of 0-100. Do you see a crash every time you run the program, or only occasionally?

[sgorsten]

On our V4L2 backend, we've observed that getting and setting UVC extension controls tend to fail spuriously, and are often recoverable with a simple retry. We had this behavior in place for R200 but had neglected to implement it for F200/SR300. I've pushed a commit (78b93c3) extending this behavior across all cameras.

[floe]

Looks good now, thanks! I still get the occasional

rs.error: TemperatureControlLoop: libusb_bulk_transfer(...) returned LIBUSB_ERROR_IO

when setting F200_MOTION_RANGE, but everything recovers quickly.

On a related note, are you planning to expose these controls via the standard V4L2 interface (similar to, e.g., the exposure control for the color camera)? Would have the advantage of making them accessible to standard tools such as v4l2-ctl.

[teknotus]

I know there are some things marked TODO in the temperature compensation code. I'm impressed by how quickly these bugs are getting fixed.

As far as standard v4l2-ctl I wrote a small program that tells the kernel what they are, and doesn't require a custom kernel. I'd be happy to contribute it if that makes things easier for people.

https://github.com/teknotus/depthview/tree/udev

It currently only works with F200. I had only figured out some of the R200 controls as of the time librealsense was released. I think it only makes sense to expose some of the R200 controls as normal v4l2 controls as many don't act in the way standard UVC controls are expected to act. For example instead of doing separate calls for min, max, default, resolution (how big is a step between possible values) a call to get current might return all of those values in an array. The depth tuning, and depth scale controls for R200 work in the expected way so I could add those.

Of course I think the UVC standard basically says that manufacturers can do whatever they want with control extensions so I wouldn't say that intel is doing anything wrong they just don't map simply to normal UVC controls, and would need a UVC quirks mode to act like a normal v4l2 control. They could also fix it with a firmware update but that might break userspace software that has already shipped.

[ev-mp]

Valid accuracy options for F200 are [1,2,3] only ( supported in firmware).
Zero is not included.