ROS2 Real-time Working Group Online Meeting 2 - Aug 21st, 2019 between 7AM and 8AM PDT (UTC-7)

@brettpac see the invite to the next meeting: ROS2 Real-time Working Group Online Meeting 3 - Oct 2, 2019, 7AM PDT (UTC-7)

@wjwwood I transcribed your part of the meeting. Please quickly review if I got anything wrong:

This was a 2 pass work:

  1. finding and fixing unneeded memory allocations in rmw, rcl, rclcpp
  2. make changes in the rmw interface and make changes to allow middleware to manage the memory

For 1 memory_testing_tools has been developed. Looked for the tool to to not have to write it (similar to valgrind ,…) but could not find one that would also be portable to different platforms. It is implemented such that it injects the shared library and e.g. overwrites malloc.
Install hook for malloc as in gtest framework. They found lots of cases with unexpected memory allocation. You also get a stack trace and unwinding is setup. Using this you can exclude memory allocations from the shared libraries that you do not care about, e.g. some tests will only care if there is memory allocation within an rcl shared library.
One thing they found is the way thread local storage is implemented in most compilers is that the first time you access the thread local variable in a new thread, it allocates the memory then and not when you create the thread.
They have something similar to err-no in rmw which allows to set errors in a thread safe way and they had to find ways to work around that. Most of the memory allocations that is still happening in the common functions such as publish and take, are happening in the middleware. There are still memory allocations happening in the rclcpp - needs to still be audited.

There are still improvements to be made in the intra-process communication.

For 2: one problems in e.g. Connext Pro, we are not able to serialize ROS m sg to CDR and publish that with Connext. DDS prefers to use the DDS type so they can control serialization and de-serialization. What OSRF does is convert ROS to DDS msg before publishing it. So when the user publishes the ROS msg, we need to copy the data from ROS datastruct to DDS datastruct, write the DDS msg and free it again. This is bad because you call create and delete data functions from DDS once every publish. To avoid that they introduced a new API called pre-allocation and the idea is that the client lib (rclcpp) they can create a pre-allocation which with Connext Pro is an object opaque to the rclcpp. This object is created once and then re-used.

More work going on now:

  1. loan data from middleware
  2. mechanisms to specify additional information

Hello Dejan,
I just wanted to say thank you for both organizing the meeting earlier today and for inviting me as well. It was very interesting.

I look forward to attending future meeting (especially since they will be more frequent) and contributing.

Thanks again,

That all looks fine.

1 Like