JdeRobot / JdeRobot/RL-Studio

Getting images from gazebo

Open
#11 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
38
Forks
8
PR merge metrics
No merged PRs in 30d

Description

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](https://docs.ros.org/en/diamondback/api/rospy/html/rospy.client-module.html#wait_for_message) 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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.