Issue with Unstable Topic Frequency in ROS2 Driver Compared to ROS1

[Liu-Jinxin]

• Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

  • Consider checking our ROS RealSense Wrapper documentation README.
  • Have you looked in our Discussions?
  • Try searching our GitHub Issues (open and closed) for a similar issue.

• All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

---

Required Info
Camera Model	D435i
Firmware Version	(Open RealSense Viewer --> Click info)
Operating System & Version	Linux (Ubuntu 22)
Kernel Version (Linux Only)	(e.g. 5.4)
Platform	PC
Librealsense SDK Version	{ 2.55.1 }
Language	{C/C#/labview/opencv/pcl/python/unity }
Segment	{Robot }
ROS Distro	Humble}
RealSense ROS Wrapper Version	4.55.1

Issue Description

Description

I have conducted tests on the same Intel RealSense D435i camera, with the same computer, comparing ROS Noetic (ROS1) and ROS2 Humble. While testing the compressed image topic, I noticed that the frequency stability in ROS1 is quite consistent and satisfactory. However, in ROS2 Humble, the frequency is significantly less stable.

Questions

1. Is there a known issue with topic frequency stability in ROS2 drivers, particularly for image data?
2. Are there specific settings or configurations in ROS2 that I should adjust to improve this stability?

Any advice or suggestions would be greatly appreciated as I continue to integrate ROS2 into my projects.

Thanks for your support and looking forward to your insights!
Noetic:

Humble:

[MartyG-RealSense]

Hi @Liu-Jinxin There was a case at #3105 a couple of months ago about low performance from a compressed depth topic when using the ROS2 wrapper.

After a lot of discussion and investigation, one of my Intel RealSense colleagues published a recommendation at #3105 (comment)

[Liu-Jinxin]

Thank you for your suggestion and the information shared! Following your advice, I conducted some tests and discovered a very peculiar issue with the frequency.

ros2 run dynamic_subscriber_node dynamic_subscriber_node --ros-args -p topic_name:=/camera/color/image_raw/compressed -p topic_type:=sensor_msgs/msg/CompressedImage
[INFO] [1729693354.441169565] [dynamic_subscriber_node]: Subscribing to sensor_msgs/msg/CompressedImage on topic: /camera/color/image_raw/compressed
[INFO] [1729693355.441249107] [dynamic_subscriber_node]: Current Frequency (Hz): 484.20
[INFO] [1729693356.441269529] [dynamic_subscriber_node]: Current Frequency (Hz): 486.58
[INFO] [1729693357.441294360] [dynamic_subscriber_node]: Current Frequency (Hz): 471.05
[INFO] [1729693358.441336205] [dynamic_subscriber_node]: Current Frequency (Hz): 31.86
[INFO] [1729693359.441364402] [dynamic_subscriber_node]: Current Frequency (Hz): 32.04
[INFO] [1729693360.441370101] [dynamic_subscriber_node]: Current Frequency (Hz): 31.89
[INFO] [1729693361.441397199] [dynamic_subscriber_node]: Current Frequency (Hz): 31.93
[INFO] [1729693362.441415731] [dynamic_subscriber_node]: Current Frequency (Hz): 479.38
[INFO] [1729693363.441448575] [dynamic_subscriber_node]: Current Frequency (Hz): 463.09
[INFO] [1729693364.441472855] [dynamic_subscriber_node]: Current Frequency (Hz): 478.43

Specifically, after each normal publish, my compressed image gets published again with a very short interval. I have logged the intervals as follows, hoping to gain further insights or suggestions on this matter.

ros2 run data_recorder test_node

Time interval: 0.0016884803771972656 seconds, Frequency: 592.2485173679752 Hz
Time interval: 0.031346797943115234 seconds, Frequency: 31.901184989123657 Hz
Time interval: 0.0024383068084716797 seconds, Frequency: 410.1206609954043 Hz
Time interval: 0.03104853630065918 seconds, Frequency: 32.20763743309759 Hz
Time interval: 0.0021209716796875 seconds, Frequency: 471.48201438848923 Hz
Time interval: 0.031369924545288086 seconds, Frequency: 31.8776667300019 Hz
Time interval: 0.0020008087158203125 seconds, Frequency: 499.79790276453764 Hz
Time interval: 0.03139615058898926 seconds, Frequency: 31.851038462998822 Hz
Time interval: 0.001981496810913086 seconds, Frequency: 504.6689929009746 Hz

I also use topic hz to test

ros2 topic hz /camera/color/image_raw/compressed 
average rate: 59.117
        min: 0.002s max: 0.033s std dev: 0.01463s window: 61
average rate: 59.537
        min: 0.002s max: 0.033s std dev: 0.01464s window: 121
average rate: 59.669
        min: 0.002s max: 0.033s std dev: 0.01464s window: 181
average rate: 59.738
        min: 0.002s max: 0.033s std dev: 0.01462s window: 241
average rate: 59.782
        min: 0.002s max: 0.034s std dev: 0.01459s window: 301
average rate: 59.812
        min: 0.002s max: 0.034s std dev: 0.01460s window: 361
average rate: 59.833
        min: 0.002s max: 0.034s std dev: 0.01460s window: 421

[MartyG-RealSense]

Have you installed the image transport plugin designed for Humble using the instruction below, please?

sudo apt install ros-humble-image-transport

[Liu-Jinxin]

Hi @MartyG-RealSense, yes I have,

➜  ros2_ws dpkg -l | grep ros-humble-image-transport   
ii  ros-humble-image-transport                             3.1.9-1jammy.20240820.161125            amd64        image_transport should always be used to subscribe to and publish images.
ii  ros-humble-image-transport-plugins                     2.5.2-1jammy.20240820.163724            amd64        A set of plugins for publishing and subscribing to sensor_msgs/Image topics in representations other than raw pixel data.

[MartyG-RealSense]

I have highlighted your case to my Intel RealSense colleagues on the ROS team. Thanks very much for your patience!

[MartyG-RealSense]

Hi again @Liu-Jinxin My Intel RealSense colleagues have an existing internal development ticket open related to the issue with ROS2 compressed topics described at #3105 and they have added your case to the ticket.