Ask Your Question

[ROS2] topic hz provides wrong rate for larger msgs

asked 2020-04-27 07:40:42 -0500

Phgo gravatar image

updated 2020-05-06 03:48:24 -0500

While testing the ros2_intel_realsense package on ROS eloquent (Ubuntu 18.04, ROS middleware FastRTPS) I realized, that ros2 topic hz reports far lower rates for a pointcloud2 topic than an explicit C++ subscriber. The rgbd point cloud has about 5MB/frame and is published at 30Hz.

C++ subscriber:

[INFO] [pointcloud2_subscriber]: Recived 27 messages in 1.00 s (27.00 Hz)
[INFO] [pointcloud2_subscriber]: Recived 28 messages in 1.00 s (28.00 Hz)
[INFO] [pointcloud2_subscriber]: Recived 30 messages in 1.00 s (30.00 Hz)
[INFO] [pointcloud2_subscriber]: Recived 27 messages in 1.00 s (27.00 Hz)

ros2 topic hz:

average rate: 12.106
    min: 0.022s max: 0.641s std dev: 0.09745s window: 100
average rate: 11.019
    min: 0.022s max: 0.641s std dev: 0.10628s window: 100
average rate: 10.903
    min: 0.022s max: 0.641s std dev: 0.10630s window: 100
average rate: 11.917
    min: 0.022s max: 0.572s std dev: 0.09033s window: 100

This difference is quite significant. Moreover, ros2 topic hzseems to cause a considerable load on the system, so that the rate of the C++ subscriber drops from ~25Hz to ~15Hz (ros2 topic hz drops to about 8Hz in this case).

As ros2 topic hz is written in python I also tried setting PYTHONOPTIMIZE=0 as suggested here, however with no effect on the results. For comparison reasons, I tested a similar setup with ROS(1) melodic, where rostopic hz provides accurate and stable results.

Which leads me to the following questions:

  1. What could cause this significant difference of the measured rates? (related to QoS settings?)
  2. Is it possible to improve the performance of ros2 topic hz in some way?
  3. What is the recommended way of measuring rates of larger messages such as point clouds or images in ros2?
edit retag flag offensive close merge delete



ros2 topic hzcausing an unexpected load on the system and outputing a seemingly lower/bad rate is "known." I thought I had seen work being done on it in the past 6 months, but I can't find anything. Not sure what can be done though. It might be worth opening a bug and see what the maintainers say:

christophebedard gravatar image christophebedard  ( 2020-05-06 07:08:54 -0500 )edit

@christophebedard thank you very much for your reply. It is good to know, that I am not the only one facing this issue and that this is not caused by my specific setup/configuration. I will go forward and open an Issue on GitHub as you suggested.

Phgo gravatar image Phgo  ( 2020-05-06 07:33:52 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-06-12 06:49:38 -0500

Phgo gravatar image

After some further testing I think I finally found the reason for the considerable difference in the message rate between ros2 topic hz and my custom C++ subscriber.

As it turns out, ros2 topic hz uses Sensor data QoS profile, while I used Default QoS in my C++ Subscriber. If i change the QoS setting to match ros2 topic hz, the results are comparably low.

So this issue appears to be more related to proper choice of QoS settings and not specific to ros2 topic hz. However, it points out, that measuring message rates with ROS2 CLI might be ambiguous, as the actual rate depends on the QoS settings of the subscriber.

edit flag offensive delete link more


does changing your subscriber's QoS setting to match ros2 topic hz's QoS cause a high system load as well? Because, while they may match, a high system load (for either of them) is still not normal.

christophebedard gravatar image christophebedard  ( 2020-06-15 07:25:40 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2020-04-27 07:40:42 -0500

Seen: 35 times

Last updated: Jun 12