Zedcam update rate in ROS is slow(.125Hz), but fast when using the SDK examples [closed]
As the title says, the update rate in ROS is abysmally slow. It used to be much faster, but after updating to the 3.0 SDK and also updating to Nvidia 430 drivers, I no longer have fast updates in ROS. This issue is present whether viewing both pointcloud data as well as camera output in RVIZ. I have tried changing resolution/framerate/quality of the camera through the yaml files, but I suspect the problem is elsewhere. Any help you can provide would be greatly appreciated. I do not have the framerate or update issue when looking at my other datastreams (Hokkuyo Lidar, Ultrasonic sensors x2, GPS, or Razor IMU). I have tried disabling all other datastreams to ensure it wasn't a bottleneck also.
System is ROS Kinetic on Ubuntu 16.04 with NVIDIA-Driver Version: 430.64 CUDA Version: 10. Graphics card is a GTX 750ti, while monitoring system resources my processor remains under 10% utilization, 4gb/16gb ram, and typically 1-1.5gb/2gb VRAM.
rostopic hz /zed/zed_node/point_cloud/cloud_registered
subscribed to [/zed/zed_node/point_cloud/cloud_registered]
average rate: 0.125 min: 8.028s max: 8.028s std dev: 0.00000s window: 2
I am starting the zed node using roslaunch zed.launch, and I can verify that it is running through rviz, rostopic list, and other methods. I receive the same update hz when running rostopic hz on the image topic aswell. When I run ZED_Explorer or Depth Viewer, I get the expected frame rate(15/30/60/120 depending on the frame rate selected for the given resolution).
Any help in this matter would be greatly appreciated.
I am noting that another person has a similar problem that also went unanswered: #q138706.
Seeing as Stereolabs officially supports their own ROS integration, I would suggest you as them for support.
An issue on the stereolabs/zed-ros-wrapper issue tracker would be the first thing to do I believe.
If/when you post there, please post a comment here with a link to your new issue, so we can keep things connected.
And it even looks like there are quite a few issues open about this problem on that tracker already.
See stereolabs/zed-ros-wrapper#525 fi. And stereolabs/zed-ros-wrapper#526.
I had already posted this on https://github.com/stereolabs/zed-ros..., but I highly suspect this is a problem moreso on the ROS end of things which is why I posted this here. Is there some variable that could have been set incorrectly to only push an update every 8 seconds?
then you should have mentioned that you are cross-posting.
Please give the Stereolabs devs some time to figure out the problem and refrain from cross-posting.
I'm going to close this question for now.
We can re-open later if it turns out the problem is not with the ZED SDK or their ROS packages.
If the ZED wrapper slows down to such frequencies the cause is often related to a problem with the TF tree. If the configuration of your robot requires to disable static TF by URDF (
publish_urdf=false) or to disable odom TF (publish_tf=false) you must guarantee that the TF chainmap->odom->base_link->zed_camera_center->zed_left_cameraexists, otherwise the node will wait for it to be available with a timeout set to 2 seconds. The ZED Node respects the conventions described in the REP105 for TF chain: https://www.ros.org/reps/rep-0105.htmlFor more info you can read these issues on Github: - https://github.com/stereolabs/zed-ros... - https://github.com/stereolabs/zed-ros...
It turns out the issue was with the zed-wrapper version I was using, after updating this cleared the problem.