High CPU utilization AstraSDK on embedded system

I’m in the process of migrating from Orbbec’s ROS node (github.com/orbbec/ros_astra_camera) to my own custom node that uses the Astra SDK since there is no support for ROS2.

Previously, we had been using ROS Kinetic with the ros_astra_camera node (as of commit a592a1fccba762c8c3addc60a8f9db5efd821cbc). Our CPU utilization was relatively low for the Orbbec node with this configuration.

Now, with my new node using the Astra SDK directly, we’re seeing roughly 3x the CPU usage. I have observed the same, large increase in CPU usage with ROS Melodic + the latest release of ros_astra_camera.

Fundamently, the custom node I’ve written is almost exactly the same as the samples/cpp-api/DepthReaderEventCPP example from the SDK. The only additional work happening is publishing the Depth image read from the AstraSDK.

I see reference to some “filter” that is costly in embedded settings both in the README of the ROS package and some issues scattered across the web (this being one). However, from my research I haven’t found any reference to the filter in the AstraSDK, or really anything I can do to reduce the CPU utilization.

Could this filter explain the huge uptick in CPU utilization? What other options do I have for tuning the AstraSDK to use less CPU? Should I be installing some different version of OpenNI2 alongside my AstraSDK? Should I not be using the AstraSDK at all and using an OpenNI2 from your dropbox.?

Any help would be greatly appreciated.

P.S. I’ve already tried with and without depth_registration, and that made almost no difference. I’m only trying to read Depth images, I’m not using the Color or other streams.

2 Likes

The filter accounts for almost 2/3 of the CPU used by the driver.

Unfortunately, the implementation is proprietary (closed source) and using the filter is mandatory, because without it the data is too noisy to be used.

About 2 years ago I had to reverse engineer the algorithm and implement my own. This cut the total CPU used by half (my filter was 3x faster).

If any company is having problems with this and needs a solution, please contact me and I will be happy to help.