Suspending / Resuming capture to reduce permanent CPU load

[sans-ltd]

Required Info
Camera Model	D435i
Firmware Version	Signed_Image_UVC_5_12_2_100.bin
Operating System & Version	{Win 10
Platform	Embedded PC, Celeron N3160 CPU
SDK Version	2.32.1
Language	C++
Segment	Machine Control/computer vision

Issue Description

On the embedded systems of our customer, we run into thermal issues when we permanently process the 3D image of the D435i. We capture at 1280x720 but reduce on 640x30px using the decimation_filter as suggested in the rs-measure example.
So we thought about activating/deactivating the camera by starting the pipe only if needed. But this takes ~3s which is inacceptable for our use case. So we tried to block the processing_thread with a std::condition_variable. This did not help either, the CPU load was as high as before (100%).

From our application, we know when we want to capture (normally only for some seconds) so a fast resume/suspend mechansim would be great for us.
The second best solution would be to throttle down the frame rate and give the CPU some time to enter its sleep states.
Regards
Florian

[MartyG-RealSense]

If you used poll_for_frames then you could manually decide when to put the CPU to sleep and the sleep duration.

#2422 (comment)

If you have thermal issues and it is an embedded system (suggesting that a Module Kit circuit board version of the camera is being used) then a better heat-sink component to draw away heat from the camera board might also be able to be designed using the guidelines in the 400 Series data sheet document.

https://dev.intelrealsense.com/docs/intel-realsense-d400-series-product-family-datasheet

Page 82 of the current edition of the data sheet contains heat sink design guidance.

[sans-ltd]

Hello,
thanks for your help. No we use the cased D435i since the machine is quite big. So space is not an issue. But the computer housing is ready designed and it is quite difficult for our customer to change things on the mechanics at this time.
Yes we use poll_for_frames as in the rs-measure example. And now we block the processing_thread with an std::condition_variable before polling, this works sufficently for us. Thanks a lot.

Can't recall why it did not work on the first try anyway.
Thanks a lot & regards
Florian

[MartyG-RealSense]

You are very welcome. :)

You may be able to shave some further % off the CPU usage by making use of a feature called GLSL Processing Blocks to offload some of the CPU work onto a GPU, though it may be ineffective to do so on low-power systems.

#3654

[sans-ltd]

Is the GPU of our Celeron N3160 (I think it's PowerVR based) supported for GLSL? Is it useful for this CPU?

[MartyG-RealSense]

GLSL is "vendor neutral", so the brand-name of the GPU should not matter, unlike CUDA offloading that only works with Nvidia GPUs.

The in-built graphics of the Celeron N3160 look pretty good, according to Intel's ARK processor details site:

https://ark.intel.com/content/www/us/en/ark/products/91831/intel-celeron-processor-n3160-2m-cache-up-to-2-24-ghz.html

[kafan1986]

@sans-ltd You are currently skipping frames using some logic. The data is still being transferred from device to your CPU and this also uses some cpu. Why don't you reduce the frame rate in the first place? Although too low framerate can blur the image. But currently if you are using say 30 FPS and skipping alternate frames, then using 15 FPS solves our problem, without a need for using frames skip logic.

[MartyG-RealSense]

Case closed due to no further comments received.