I am using the Nvidia Jetson + ROS + Freenect_Launch to access data from the Kinect. I am running into an issue (that I don’t run into on my intel-i7 laptop) where my node who is subscribing to the /camera/depth/points message, cannot ‘receive’ fast enough (for my purpose). I have played with different ways of configuring the call-back function (as well as using TransportHints().tcp_nodelay()), and the best I can do is about 7Hz.
I am not doing any processing of the pointcloud in the callback, I just have the subscriber-callback publishing a basic sensor_msg so I can use rostopic hz /mynode/basicsensormsg to see how fast the callback is occuring (about 7Hz).
Same exact node running on my laptop is full 30Hz. When I do a rostopic hz /camera/depth/points, this is also 30Hz.
I believe the Jetson board is bottle-necking during the transferring of the pointcloud data from the launch-node to my written node. I’m wondering if there is a more ‘efficient’ way of subscribing to such a large portion of data, or if anyone has compiled the freenect_camera driver into their rosnode and could share their experience (I’m moving toward the idea that the pointcloud delivery through ros sensor_msgs is not the right approach, and would rather have a node directly receive from the driver, eliminating needless memory transfer steps).
Description of some code I tried:
The callback: void cloud_cb(const sensor_msgs::PointCloud2::ConstPtr& point_cloud) was tried, and this callback defined this way did not have any bottle necks. However, I could not figure out how to use the cloud in a pcl::passthroughfilter() without using ‘pcl::fromROSMsg()’ first. The pcl::fromROSMsg() caused the 7Hz bottleneck once used in the callback function.
The callback: void cloud_cb(const PointCloud::ConstPtr& point_cloud) was used, and this callback defined this way bottlenecks without any additional code. However, I can directly use the cloud ‘point_cloud’ in a pcl::passthrough filter, avoiding the need to use 'pcl::fromROSMsg();