ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Issues with borrow_loaned_messages and eProsima FastDDS / zero-copy data-sharing

asked 2022-05-20 15:58:48 -0500

AspireChef gravatar image

I'm running ROS2 Galactic Geochelone and am seeing a couple of things that don't make sense to me in terms of borrow_loaned_messages() use. Hopefully someone out there can shed some light on this for me.

Setup

I configure a publisher node with this:

 publisher_ = this->create_publisher<camera_interfaces::msg::Camera>("camera_sensor_topic", 10);

The message consists of:

uint64 ts
uint32 seqnum
uint32 magicnum
uint32 poolnum
uint32 cksum
uint8[8294400] camera_data

My environment is configured with:

export RMW_FASTRTPS_USE_QOS_FROM_XML=1
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
export FASTRTPS_DEFAULT_PROFILES_FILE=`pwd`/enable-loaned-msgs.xml

Finally, the enable-loaned-msgs.xml (referenced in the env above) is:

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">

  <!-- Default publisher profile -->
  <data_writer profile_name="default publisher profile" is_default_profile="true">
    <qos>
      <publishMode>
        <kind>ASYNCHRONOUS</kind>
      </publishMode>
      <data_sharing>
        <kind>AUTOMATIC</kind>
      </data_sharing>
    </qos>
    <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
  </data_writer>

  <data_reader profile_name="default subscription profile" is_default_profile="true">
    <qos>
      <data_sharing>
        <kind>AUTOMATIC</kind>
      </data_sharing>
    </qos>
    <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
  </data_reader>
</profiles>

Questions / observations:

1) As a part of testing, I use borrow_loaned_messages() from a timed loop and do NOT publish the message, and thereby do NOT return it to the middleware.

I would expect to see the entries in /dev/shm to grow unbounded. They don't. Instead they get to ~11*sizeof(message) and don't change in size from that point. My timed loop never aborts. No new allocations seem to be occurring. Further, I never error out from not being able to borrow a loaned message... that operation always seems to succeed.

What am I missing with my understanding? I'm thinking it might be because of "PREALLOCATED_WITH_REALLOC" (emphasis on _REALLOC), but if I'm never returning the message to middleware, how is this even working? Dumb luck?

Perhaps when the timed_loop exits and the reference to the loaned_message goes away, the loaned_message automatically goes back to the middleware? The API documentation seems to indicate that you must explicitly return loaned messages so I'm not sure if that's correct.

2) With the publisher created with a size of 10, what's causing things to apparently grow to a size of 11? At least, that's what it looks like in terms of /dev/shm memory usage. I've tried a few different sizes and the overall size always seems to be +1 over what value I configure via create_publisher.

Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-05-24 06:47:12 -0500

AspireChef gravatar image

After instrumenting the code, I learned that the destructor was getting implicitly called at the end of my timed_loop callback. This ultimately returned the loaned message back to the middleware. That explains point 1).

edit flag offensive delete link more

Comments

I think point 2) may be that there are 10 messages of "history" + 1 "active" message for processing.

AspireChef gravatar image AspireChef  ( 2022-05-25 15:51:32 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2022-05-20 15:58:48 -0500

Seen: 151 times

Last updated: May 24 '22