ros2/rmw_connextdds

rclcpp::SensorDataQoS not working for sensor_msgs::msg::Images

Opened this issue · 1 comments

xander-m2k commented

System Info

  • OS
    • Ubuntu 20.04
  • ROS version and installation type
    • ROS Foxy binary install
  • RTI Connext DDS version and installation type
    • Newest apt packages Foxy as of today

Bug Description

When publishing sensor_msgs::msg::Image with images larger than h*w (tested with height 1944 width 2592), and using the standard QoS for sensors, messages cannot be read. Messages are published (checked with wireshark).

Expected Behavior

Messages should be readable.

How to Reproduce

Publish an image of a similar size I described (with sensor_msgs::msg::Image and rclcpp::SensorDataQoS), and read on that topic (ros2 topic echo /<image_topic>. Cannot share code, working on code under NDA, I'm sorry.

Workarounds

Just used the standard '10' as QoS with the create_publisher() function in rclcpp

asorbini commented

Hi @xander-m2k,

thank you for reporting this issue. I will try to reproduce it soon, but on the top of my head, I suspect the issue might lie in the use of "best effort" Reliability QoS (used by the "sensor data" profile) when trying to send "large data" (i.e. messages which need DDS-level fragmentation like the image you are trying to publish).

I'll quote from this online documentation page:

If you use Best Effort, the application is not going to try to recover any lost fragments. Since in Best Effort communication the lost fragment isn’t resent, the DataReader will discard the entire sample. Depending on its size, the sample could have a lot of fragments, meaning it is more likely to lose a fragment (and therefore, the entire sample). By using Reliable Reliability, if a fragment is lost Connext DDS will try to recover it.

I would suggest switching the publisher to be "reliable" and see if that improves things.

Workarounds

Just used the standard '10' as QoS with the create_publisher() function in rclcpp

I'm not quite sure how modifying the history depth would affect this issue. I suspect that by "standard '10'" you mean you are using the alternative signature of create_publisher() which only takes the history depth value and applies it on top of the standard QoS profile. It would make sense that you see communication happen in this case, because the default QoS is reliable.