Open ashwinsushil opened 4 years ago
When I start the node, the /republished_images topic publishes at 30hz (as given in the publisher) but the moment I start ros-foxy-image-publisher and the /source_images is fed in the node, the rate of /republished_images decreasing rapidly from 30hz to 27hz to 25 to 20hz and finally settles at 5hz.
How are you measuring the rate?
are you using ros2 topic hz
?
AFAIR, that uses a best effort subscription. Maybe that's the issue. What is the size of the images being published?
Sorry for the late reply @ivanpauno. Yes, I'm using ros2 topic hz
to measure the rate. FYI, when I use ros2 topic hz /source_image
the rate is constant 30Hz. However, it is on /republished_images that the topic rate is low.
By the size did you mean the height and width? Then the height is 1080 and the width is 1920.
I modified the code to reduce the size of the image by 20% and now I can republish the image at 30hz. However, the quality is bad. But I don't still understand why I am unable to republish the image with original size.
Modified callback,
def image_callback(self, received_image):
cv_image = self._bridge.imgmsg_to_cv2(received_image)
scale_percent = 20 # percent of original size
width = int(cv_image.shape[1] * scale_percent / 100)
height = int(cv_image.shape[0] * scale_percent / 100)
dim = (width, height)
resized = cv2.resize(cv_image, dim, interpolation = cv2.INTER_AREA)
self.received_msg_ = self._bridge.cv2_to_imgmsg(resized, encoding="bgr8")
@ashwinsushil Sorry for the super-late reply.
By the size did you mean the height and width? Then the height is 1080 and the width is 1920.
I actually want to know the size in "MB" of the images (if your image was RGB24 the size would be ~3.4MB).
Some of the DDS implementations don't work pretty well out of the box with large messages (particularly if not all the QoS profiles are well tuned). See https://index.ros.org/doc/ros2/Troubleshooting/DDS-tuning/.
Your depth=1
option in the publisher also looks suspicious, maybe you're overriding the history cache before the last image went to the wire. Can you try depth=10
or higher?
It would also be good if you can measure how often the timer_callback
is being triggered in your code (i.e. if the timer is actually being triggered at 30Hz).
If it's not being triggered at that rate, this is likely a rclpy
performance problem.
If not, this is more likely a not good QoS
profile or DDS-tunning
issue.
Bug report
sensor_msg/Image
(which is published fromros-foxy-image-publisher
) and then republishing this image on a different topic at a particular rate./republished_images
topic publishes at 30hz (as given in the publisher) but the moment I startros-foxy-image-publisher
and the/source_images
is fed in the node, the rate of/republished_images
decreasing rapidly from 30hz to 27hz to 25 to 20hz and finally settles at 5hz.Required Info:
Steps to reproduce issue
I have created a docker file to reproduce the issue.
Please pull the docker image:
Start the container in interactive mode by
Once inside the container, source the script:
Run the node that republishes the image (please ignore the naming):
Check the rate of republished image (at the moment it is publishing an empty message type Image)
In another terminal inside the docker, run the image publisher that publishes an ROS2 image topic from the video named
v4.mp4
Expected behavior
/republished_images
topic publishes at 30hz at all times.Actual behavior
/republished_images
topic publishing decrease from 30hz to 5hz when the/source_images
is fed from theros-foxy-image-publisher
Additional information
I tried using FastRTPS and CycloneDDS implementation of the ros2 middleware but the behaviour is the same.
The code is already inside the docker image inside /umd2_ws