Can't set "create_timer" callback frequency properly
Hi, I am fairly new to ros2 and running into problems with the "create_timer" callback function, trying to create an image publisher with a specific frequency. My code looks like this:
class DataFromFilesNode(Node):
def __init__(self):
super().__init__("data_from_files")
self.img_publisher_ = self.create_publisher(Image, "image_front", 10)
self.publish_data()
self.get_logger().info("data_from_files_node running!")
def publish_data(self):
self.img_file_paths = self.get_file_paths('path_to_image_folder/Images/') #array with image paths
self.number_of_files = len(self.img_file_paths)
self.br = CvBridge()
self.counter_imgs = 0
self.timer_ = self.create_timer(1.0/40.0,self.publish_img) #!!main issue here!!
def publish_img(self):
img_raw = cv2.imread(self.img_file_paths[self.counter_imgs])
msg = self.br.cv2_to_imgmsg(img_raw)
msg.header.frame_id = self.get_frame_from_file_path(self.img_file_paths[self.counter_imgs])
msg.header.stamp = self.get_clock().now().to_msg()
msg.encoding = 'bgr8'
self.img_publisher_.publish(msg)
self.counter_imgs += 1
if self.counter_imgs == self.number_of_files:
self.counter_imgs = 0
This code works fine in that sense that it publishes the image data and I can visualize it using rqt. However, the publishing frequency is way off from what I set it to be in the code. For example for a frequency of 40Hz set in the "createtimer" callback, the actual publishing frequency is around 33-34Hz. Same goes for a set frequency of 25Hz where the actual frequency is around 21-22Hz. I checked the run time of the publishimg() function which is below 0.02 sec, so a max. frequency of 50Hz should be possible. I am not sure if I am doing something wrong or if that's the precision I have to expect from ros2?
Asked by Karl_Bauer on 2023-01-16 04:22:48 UTC
Answers
Is it possible you are trying to publish more image data than your network can handle? That leads to a lower received frame rate at the subscriber. Question #q410972 is related.
Asked by Mike Scheutzow on 2023-01-18 20:20:19 UTC
Comments
Hey Mike, that was my first guess as well. Generally I can enforce a higher publishing rate by increasing the publishing rate in the “create_timer” callback function. I believe that this should not be possible if my network is the limiting factor. If that was the case I would expect that no matter how much I increase the frequency in the “create_timer” callback function, my actual publishing rate would not increase beyond a certain value. My problem is that the publishing value I set in the “create_timer” callback function always has a big offset to the actual publishing rate. It is a little annoying only being able to set a specific publishing rate by trial and error until I find the “correct” offset. In the mean time I got the feeling that the problem is maybe connected to the “sensor_msg:Image()” message type that I am using for the image publisher. To get an exact value for the publishing rate I am using “ros2 topic hz /topic_name”. To display the image data I am using rqt. I i
Asked by Karl_Bauer on 2023-01-20 08:06:06 UTC
mplemented a slider using dynamic reconfigure to change to publishing frequency while the program is running. Just from looking at the image output in rqt, the playback speed of the images responds perfectly fine to the changes I make to the publishing frequency using the slider. So I tried to display the publisher frequency as well in rqt to see if I these values differ from the ones I get by using “ros2 topic hz”. However, the frequency can not be displayed in rqt because of the message type I am using. I found the following related question #q360929 that explains in which way “sensor_msgs” can cause problems. I have to admit that I do not fully understand what they are talking about in this question but could it be the case that “ros2 topic hz /topic_name” does not properly function for specific message types?
Asked by Karl_Bauer on 2023-01-20 08:06:52 UTC
What QOS_reliability are you using for this topic? If you choose BEST_EFFORT, you are telling the DDS that it can drop any packets it wants to; a packet drop is very bad for image data.
Asked by Mike Scheutzow on 2023-01-20 12:03:10 UTC
I am using QOS_reliability "RELIABLE":
Type: sensor_msgs/msg/Image
Publisher count: 1
Node name: data_from_files
Node namespace: /
Topic type: sensor_msgs/msg/Image
Endpoint type: PUBLISHER
GID: 01.0f.e4.6a.99.18.ad.07.01.00.00.00.00.00.11.03.00.00.00.00.00.00.00.00
QoS profile:
Reliability: RELIABLE
History (Depth): UNKNOWN
Durability: VOLATILE
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
Asked by Karl_Bauer on 2023-01-23 04:46:46 UTC
Comments