Getting images from gazebo

[rocapal]

Let's take the following scenario: f1_renault model (configured with update_rate=20) and montmelo circuit. Gazebo-11 is executing with the UI, processing ~50 FPS and real_time_factor is ~0.53.

Subscriber mode

Using the subscriber mode, I get ~ 10 images per second (IPS) . It does make sense since real_time_factor ~0.53 and therefore gazebo simulation is running at around half due to lack of resources.

rospy.Subscriber('/F1ROS/cameraR/image_raw', Image, callback, queue_size=1)

Wait for message

Using 'wait_for_message' in theory, it should wait until there is a new message published in that topic. So, I expect to get similar rate than before. But, the surprise comes when I see that I can get ~ 19 IPS

rospy.wait_for_message('/F1ROS/cameraR/image_raw', Image, timeout=5)

I have analyzed the images received with this method, and I have seen that images are duplicated from time to time. That means that the real rate is not ~ 19. And this creates a worse behavior in the "follow_line" scenario since you could be analyzing an image that does not correspond to the current state.

Numbers

Definitely the numbers below show that it might not be a good idea to use 'wait_for_message' for continuous streaming of images (like inference scenario in gym-gazebo). 'wait_for_message' seems to be recommended to get sporadic messages from a specific topic.

Config(*)	Subscriber (IPS)	wait_for_message (IPS)
update_rate=20 - real_time_factor=0.53	~10	~19 (duplicated)
update_rate=60 - real_time_factor=0.91 (no UI)	~50	~24 (duplicated)

(*) Tested in laptop an server machine with similar results

UPDATED: Checking the doc wait_for_message creates a new subscription to the topic, receive one message, then unsubscribe.Definitely 'wait_for_message' should not be used to get images continuously, since for low update rates it does duplicate images, and for high update rates cannot get all of them.

Has someone experienced something similar or can confirm this behavior?

[rocapal]

I'm sharing a tool (test_image_rate.py) to measure the image rate acquisition.

This is my output for this configuration (update_rate=60 - real_time_factor=0.91 (no UI))

[WAIT_MESSAGE] Images received per second: 26.45 (duplicated=7)
[SUBSCRIBER] Images received per second: 58.02 (duplicated=0)

It makes sense that wait_message can't go further than ~ 25 IPS, since in every call it does create a new subscription, receive the message and unsubscribe.