Timeouts

[lukier]

Not strictly an issue, more of a question.

Do you consider adding timeouts for the rs_wait_for_frames call? I see it has some std::chrono fixed 5 second timeout, but this is just busy looping in infinite while loops, not a blocking call.

It is not passed to struct timeval for the select in v4l2 backend or libusb transfer setups - libuvc also hardcodes 5 second timeout.

This is perhaps not that critical as proper blocking is not that useful for cameras that don't have external triggers (like dc1394 or PointGrey), but I think it would be useful to have user settable timeout anyway (5 s might be too long).

In the meantime I'll read the code some more and think how to approach this issue.

[sgorsten]

This is a somewhat tricky issue. The behavior of rs_wait_for_frames(...) is to block until a coherent frameset is available. However, there are also a class of hardware errors which prevent further streaming and which are only portably detectable by the fact that new frames stop arriving over the UVC connection, so rs_wait_for_frames(...) is also responsible for detecting this scenario and raising an error in that case.

The timing and synchronization code is due for a bit of an overhaul, though, and if there's interest, we could add a second method (rs_check_for_frames(...), perhaps?) with a user specifiable timeout and a return value to indicate if new data is available.

As an aside, if you have a use case that seems to be frequently triggering the timeout, please open it as a second issue, and we'll see if we can do something to improve the reliability of streaming for that use case.

[lukier]

I thought it might be tricky with multiple streams from multiple devices (/dev/videoX) etc.

I was mostly worried about while(true) loops in wait_all_streams consuming CPU core looping, either until next frame (15-30 ms) or in error condition until 5 second timeout, but it seems not that bad - I suppose thanks to the atomics in triple_buffer.

BTW are the sensors (RGB/Depth) in F200/R200 hardware synchronized? Either by sharing pixel clock or exposure timestamped to a common HW timer? I see something related in stream_buffer::frame::timestamp so I was hopeful that the cameras have proper timing, not like Kinect with two separate free running sensors.

[ddiakopoulos]

Both F200 and R200 have internal sync mechanism to trigger the sensors on a common clock. These are exposed to software via frame-counters, and we provide matched frame sets in librealsense. The SR300 has a revised timing architecture (via frame metadata in the UVC protocol) that provides additional timing information, and we'll expose that as a feature when SR300 reaches general availability.

[lukier]

Awesome, that's proper camera engineering right there :) If only these cameras had GPIO trigger in/out to synchronize other things as well (think IMU, robot's odometry etc).

[floe]

👍 for trigger I/O (or at least for a hint on where to solder :-)

[muzafferkal]

Trigger IO would be awesome; please?