Streaming IMU and image data

[sshhj89]

• 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	D435i
Firmware Version
Operating System & Version	Win10
Kernel Version (Linux Only)
Platform	PC
SDK Version	pyrealsense2 2.24.950
Language	python
Segment	Robot

Issue Description

<Describe your issue / question / feature request / etc..>
I would like to get streaming data including IMU, depth and color.

As far as I know the D435i's sampling rate for each data is different, for example,

Accelerometer has 63/250 hz, gyro has 200/400 hz, and image data has slower than this.

In current code,

the streaming looks like simultaneously depending on the image fps.

How can I get whole IMU data generated while image frame interval without drop.

Thanks in advance.

[eMrazSVK]

Use poll_for_frames() function. It will not block the thread. It is used in this example. The example considers using multiple cameras, but I hope the principle is the same. The elementary difference is:

• wait_for_frames() waits until frames are available and blocks main loop until frames are received
• poll_for_frames() tries to get frames, if frames are not available it exits and loop (thread) is not blocked

[ev-mp]

@sshhj89 hello,
You need to consider the following - using synchronous API calls (wait_for_frames, poll_for_frames, try_wait_for_frames streamlines the application logic flow. But the caveat is the processing required in the user's code. So if, in the above segment, the OpenCv part takes about 30msec to process than the theoretically the FPS is bounded to 33Hz. An actually it will be lower depending on the internal syncer logic.
In case you must not want to miss frames than you should probably examine the asynchronous approach by polling the frames into designated thread-safe queues an then processing them asynchronously.

See more details and per-method demo references in this comment

[dorodnic]

Also, please take a look at rs-callback example, specifically designed for higher frequency input