Static typesupport #203

MiguelCompany · 2018-05-30T07:48:10Z

Summary

At eProsima we are working on static typesupport for rmw_fastrtps. We now have the basic functionality ready for C++, but we still have the following todos:

create package rosidl_typesupport_fastrtps_c with support for C (i.e. python)
refactor to avoid #ifdef RMW_FASTRTPS_CPP_STATIC_TYPESUPPORT
- create package rmw_fastrtps_shared_cpp with common code
- create package rmw_fastrtps_dynamic_cpp with dynamic specific (introspection) code
- leave static specific code only on package rmw_fastrtps_cpp
pass linters

Performance test

We have run some performance tests (which code is also in the repo). The test scenario involves two applications:

Listener application with subscriber for "test" and publisher for "test_echo":
- It will publish on "test_echo" anything received on "test"
Talker application with publisher for "test" and subscriber for "test_echo":
- It will publish on "test" anything received on "test_echo"
- It will increase a counter when receiving on "test_echo"
- It will show the counter value every 10 seconds
- It will publish a single message on "test" upon startup

For each data type we run the test as follows:

Start the listener
Start the talker and leave it running for 2 minutes
Take note of the number of times the message has gone from the talker to the listener and back

Performance test results

Depending on the data type, we see an improvement from 0.15% to 84%. The improvement increases with the size of the message as well as with its complexity (number of fields / nested submessages).

Data type	master	static	improvement
String ("Hello World")	1145937	1148323	0,21%
Array16k (16KB static array)	891891	913705	2,45%
Array4m (4MB static array)	1198	1976	64,94%
PointCloud512k (512KB static array + PointField [8])	10940	13411	22,59%
PointCloud8m (8MB static array + PointField [8])	874	1611	84,32%
Struct16 (16 byte fields)	1156054	1157837	0,15%
Struct32k (8 Struct4k fields, each with 16 Struct256 fields, each with 16 Struct16 fields)	50079	67757	35,30%
MultiDOFJointState (seq. of 1024 strings + seq. of 1024 Transform + seq. of 1024 Twist + seq. of 1024 Wrench)	27400	37763	37,82%

Allocation test

We have also run a different test scenario to compare memory allocation and copy. In this scenario (launching the applications with argument -m) there is no echo, just a standard talker and listener, and a fixed number of messages (30) is published once a second 30 times. This way, we know the serialization is done the same number of times.

We run the talker and the listener under valgrind tools 'massif' (to compare peak size of heap) and 'callgrind' (to compare number of calls to malloc, realloc, memcpy and such)

Allocation test results

The results show that peak size of heap is almost the same for both branches. The main improvements are in calls to allocation functions.

Results show that, on serialization, we are allways saving one call to malloc per message. We are also saving realloc calls depending on the size and complexity of the message (up to 860 per message!). For deserialization, one call to malloc is saved per message.

	listener		talker
Data type	Heap size diff (KB)	malloc diff (calls per msg)	Heap size diff (KB)	malloc diff (calls per msg)	realloc diff (calls per msg)
String ("Hello World")	0	1	0	1	0
Array16k	0	1	0	1	1
Array4m	0	1	0	1	1
PointCloud512k	0	1	0	1	2
PointCloud8m	0	1	0	1	2
Struct16	0	1	0	1	0
Struct32k	1740	1	204	1	338
MultiDOFJointState (1024 joints)	102	1	204	1	860

dirk-thomas · 2018-05-30T19:27:50Z

Can you please reference the exact messages which are being used in the "Performance test results" table.

I expected a "big" improvement for nested messages with many fields. I am a little bit surprised about the huge difference for a 8 MB point cloud. Do you have any more information why that is the case?

MiguelCompany · 2018-05-31T07:03:37Z

I edited the initial message including links to the message definitions on the tables. I also changed the allocation results table to only depict improvements.

In general, the main improvement is that we get rid of a temporary FastBuffer object. That means we are always saving one allocation of the default buffer size, and one copy of the whole serialized message. On serialization, for some messages (including PointCloud8m) we are saving reallocations of that temporary buffer.

I think that in the case of big messages (like PointCloud8m) the main improvement comes from the saving of the copy from the temporary buffer to the definitive one.

dirk-thomas · 2018-05-31T16:13:44Z

In general, the main improvement is that we get rid of a temporary FastBuffer object. That means we are always saving one allocation of the default buffer size, and one copy of the whole serialized message. On serialization, for some messages (including PointCloud8m) we are saving reallocations of that temporary buffer.
I think that in the case of big messages (like PointCloud8m) the main improvement comes from the saving of the copy from the temporary buffer to the definitive one.

Could these changes also be applied to the dynamic code path? Or are the only feasible in the static case? Could you reference the exact code line which you refer to in order to ease digging into this.

MiguelCompany · 2018-06-01T11:15:23Z

Could these changes also be applied to the dynamic code path? Or are the only feasible in the static case?

I think we could apply most of the changes to the dynamic code path. I will look into it next week while I perform the refactor to have dynamic and static support on different packages

Could you reference the exact code line which you refer to in order to ease digging into this.

Sure. For the publishing part, the related code is here

rmw_fastrtps/rmw_fastrtps_cpp/src/rmw_publish.cpp

Lines 43 to 50 in 3700d75

    
           eprosima::fastcdr::FastBuffer buffer; 
        
           eprosima::fastcdr::Cdr ser(buffer, eprosima::fastcdr::Cdr::DEFAULT_ENDIAN, 
        
             eprosima::fastcdr::Cdr::DDS_CDR); 
        
           if (_serialize_ros_message(ros_message, ser, info->type_support_, 
        
             info->typesupport_identifier_)) 
        
           { 
        
             if (info->publisher_->write(&ser)) {

Allocation and reallocations are performed in calls to the serialization methods of Cdr inside _serialize_ros_message. The final copy is done inside info->publisher_->write, exactly here:

rmw_fastrtps/rmw_fastrtps_cpp/include/rmw_fastrtps_cpp/TypeSupport_impl.hpp

Line 777 in 3700d75

memcpy(payload->data, ser->getBufferPointer(), ser->getSerializedDataLength());

For deserialization, an initial allocation and copy is performed here:

rmw_fastrtps/rmw_fastrtps_cpp/include/rmw_fastrtps_cpp/TypeSupport_impl.hpp

Lines 792 to 794 in 3700d75

    
           auto buffer = static_cast<eprosima::fastcdr::FastBuffer *>(data); 
        
           buffer->resize(payload->length); 
        
           memcpy(buffer->getBuffer(), payload->data, payload->length);

called from:

rmw_fastrtps/rmw_fastrtps_cpp/src/rmw_take.cpp

Lines 47 to 50 in 3700d75

    
           eprosima::fastcdr::FastBuffer buffer; 
        
           eprosima::fastrtps::SampleInfo_t sinfo; 
        
           if (info->subscriber_->takeNextData(&buffer, &sinfo)) {

MiguelCompany · 2018-06-07T05:58:50Z

Just adding a comment to let you know that refactor is complete.

@dirk-thomas I have updated my todo list to include the changes to remove the temporary buffer from the dynamic code path. If you prefer that to be on another PR, just let me know.

dirk-thomas · 2018-06-07T14:43:19Z

If you prefer that to be on another PR, just let me know.

Yes, please create a separate PR for that so that they can be considered/ reviewed / merged independently.

dirk-thomas · 2018-06-07T18:44:53Z

The current patch has conflicts and is not mergable. Please address those.

For the review as well as readability of the history can you please have separate commits for moving / copying existing files. And apply potential changes after that in separate commits. That will allow us to review only actual changes.

MiguelCompany · 2018-06-08T10:35:28Z

Ok @dirk-thomas.

I have refactored the commit history so the PR is ready for review.

deeplearningrobotics · 2018-06-08T13:02:19Z

rmw_fastrtps_cpp/include/rmw_fastrtps_cpp/custom_service_info.hpp

-  explicit ServiceListener(CustomServiceInfo * info)
-  : info_(info), list_has_data_(false),
-    conditionMutex_(nullptr), conditionVariable_(nullptr)
+  inline bool take(void * ros_request,


It would be great if at least all classes and public functions could be documented.

deeplearningrobotics · 2018-06-08T19:42:13Z

@MiguelCompany: I see you are creating a fastcdr::FastBuffer when calling rmw_publish. Does that mean that heap allocation happens every time a sample is published? Also does the same happen on the subscriber side?

dirk-thomas · 2018-06-08T21:54:01Z

The first commit is not a 1-to-1 copy of the existing files. Therefore git can't follow any history for these files. Please split that commit into two: the first doing a 1-to-1 copy of the existing files (without any changes), the second applying the necessary changes (renaming the package, namespace, etc.). Same for the later commit copying the file into rmw_fastrtps_dynamic_cpp.

I also noticed that a later commit also deletes some of the files previously added (e.g. `rmw_fastrtps_shared_cpp/src/type_support_common.hpp). Please don't copy those in the first place to reduce the amount of changes.

Also #192 has been merged recently and you patch seems to revert that change.

Nitpick: the copyright year you usually "extend" rather than replace: 2016-2018

MiguelCompany · 2018-06-11T05:27:15Z

To @andreaspasternak

I see you are creating a fastcdr::FastBuffer when calling rmw_publish. Does that mean that heap allocation happens every time a sample is published?

This is what happens in the code currently on master. The main improvement on the static typesupport is that we get rid of that temporary FastBuffer creation.

Also does the same happen on the subscriber side?

In the code currently on master, yes. Has also been removed on static typesupport

MiguelCompany · 2018-06-11T07:32:02Z

To @dirk-thomas

The first commit is not a 1-to-1 copy of the existing files. Therefore git can't follow any history for these files. Please split that commit into two: the first doing a 1-to-1 copy of the existing files (without any changes), the second applying the necessary changes (renaming the package, namespace, etc.). Same for the later commit copying the file into rmw_fastrtps_dynamic_cpp.

I also noticed that a later commit also deletes some of the files previously added (e.g. `rmw_fastrtps_shared_cpp/src/type_support_common.hpp). Please don't copy those in the first place to reduce the amount of changes.

Done

Nitpick: the copyright year you usually "extend" rather than replace: 2016-2018

You're right. Done. Thanks.

Also #192 has been merged recently and you patch seems to revert that change.

You're right! It was partially reverted! It's fixed now

deeplearningrobotics · 2018-06-11T14:30:43Z

@MiguelCompany: I tried to test this code by cloning it into my ROS2 workspace. But I get the following error:

Process package 'rmw_fastrtps_shared_cpp' with context:
--------------------------------------------------------------------------------
 source_space => /home/salus/andreas.pasternak/rmw_test/apex_ws/src/rmw_fastrtps_shared_cpp
  build_space => /home/salus/andreas.pasternak/rmw_test/apex_ws/build/rmw_fastrtps_shared_cpp
install_space => /home/salus/andreas.pasternak/rmw_test/apex_ws/install
   make_flags => -j6, -l6
  build_tests => False
--------------------------------------------------------------------------------
+++ Building 'rmw_fastrtps_shared_cpp'
Running cmake because arguments have changed.
==> '. /home/salus/andreas.pasternak/rmw_test/apex_ws/build/rmw_fastrtps_shared_cpp/cmake__build.sh && /usr/bin/cmake /home/salus/andreas.pasternak/rmw_test/apex_ws/src/rmw_fastrtps_shared_cpp -DBUILD_TESTING=0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/salus/andreas.pasternak/rmw_test/apex_ws/install' in '/home/salus/andreas.pasternak/rmw_test/apex_ws/build/rmw_fastrtps_shared_cpp'
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ament_cmake_ros: 0.4.0 (/opt/ros2/share/ament_cmake_ros/cmake)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3") 
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Found rcutils: 0.4.0 (/home/salus/andreas.pasternak/rmw_test/apex_ws/install/share/rcutils/cmake)
-- Found fastrtps_cmake_module: 0.4.0 (/home/salus/andreas.pasternak/rmw_test/apex_ws/install/share/fastrtps_cmake_module/cmake)
-- Found FastRTPS: /opt/ros2/include  
-- Found rmw: 0.4.0 (/opt/ros2/share/rmw/cmake)
CMake Error at /opt/ros2/share/ament_cmake_core/cmake/core/ament_package.cmake:65 (message):
  ament_package() called with unused arguments:
  CONFIG_EXTRAS_POST;rmw_fastrtps_shared_cpp-extras.cmake
Call Stack (most recent call first):
  /opt/ros2/share/ament_cmake_core/cmake/core/ament_package.cmake:59 (_ament_package)
  CMakeLists.txt:92 (ament_package)

Can you tell me how I can test it?

mikaelarguedas · 2018-06-11T14:40:06Z

@andreaspasternak It looks like you have an earlier version of ament_cmake. This option has been added after the ardent release: ament/ament_cmake#123

deeplearningrobotics · 2018-06-11T14:42:03Z

@mikaelarguedas: Great, I will try to install the newest ROS 2 version.

deeplearningrobotics · 2018-06-12T13:48:44Z

@mikaelarguedas, @MiguelCompany:

So I built ROS 2 from sources, using the master branch, while replacing the rmw_fastrtps with this repository: https://github.com/eProsima/rmw_fastrtps

This built fine.

Then I switched to this branch (static_typesupport) and got the following error:

+++ Building 'builtin_interfaces'
Running cmake because arguments have changed.
==> '. /home/andreas.pasternak/ros2_ws/build/builtin_interfaces/cmake__build.sh && /usr/bin/cmake -DBUILD_TESTING=1 -DAMENT_CMAKE_SYMLINK_INSTALL=1 -DCMAKE_INSTALL_PREFIX=/home/andreas.pasternak/ros2_ws/install /home/andreas.pasternak/ros2_ws/src/ros2/rcl_interfaces/builtin_interfaces' in '/home/andreas.pasternak/ros2_ws/build/builtin_interfaces'
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ament_cmake: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake/cmake)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3") 
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Override CMake install command with custom implementation using symlinks instead of copying resources
-- Found rosidl_default_generators: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/rosidl_default_generators/cmake)
-- Could not find eProsima Fast-RTPS - skipping rosidl_typesupport_fastrtps_c
-- Found FastRTPS: /home/andreas.pasternak/ros2_ws/install/include  
-- Using all available rosidl_typesupport_c: rosidl_typesupport_fastrtps_c;rosidl_typesupport_introspection_c
-- Found ament_cmake_cppcheck: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake_cppcheck/cmake)
-- Found ament_cmake_cpplint: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake_cpplint/cmake)
-- Found ament_cmake_uncrustify: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake_uncrustify/cmake)
-- Using all available rosidl_typesupport_cpp: rosidl_typesupport_fastrtps_cpp;rosidl_typesupport_introspection_cpp
-- Found rmw_implementation_cmake: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/rmw_implementation_cmake/cmake)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.5") 
-- Found python_cmake_module: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/python_cmake_module/cmake)
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.5m.so (found suitable version "3.5.2", minimum required is "3.5") 
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Using PYTHON_INCLUDE_DIRS: /usr/include/python3.5m
-- Using PYTHON_LIBRARIES: /usr/lib/x86_64-linux-gnu/libpython3.5m.so
-- Found PythonExtra: .so  
-- Found ament_cmake_flake8: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake_flake8/cmake)
-- Found ament_cmake_pep257: 0.4.0 (/home/andreas.pasternak/ros2_ws/install/share/ament_cmake_pep257/cmake)
-- Configuring done
CMake Error at /home/andreas.pasternak/ros2_ws/install/share/rosidl_generator_py/cmake/rosidl_generator_py_generate_interfaces.cmake:255 (add_dependencies):
  The dependency target "builtin_interfaces__rosidl_typesupport_fastrtps_c"
  of target "builtin_interfaces__rosidl_typesupport_fastrtps_c__pyext" does
  not exist.
Call Stack (most recent call first):
  /home/andreas.pasternak/ros2_ws/install/share/ament_cmake_core/cmake/core/ament_execute_extensions.cmake:38 (include)
  /home/andreas.pasternak/ros2_ws/install/share/rosidl_cmake/cmake/rosidl_generate_interfaces.cmake:169 (ament_execute_extensions)
  CMakeLists.txt:18 (rosidl_generate_interfaces)


-- Generating done
-- Build files have been written to: /home/andreas.pasternak/ros2_ws/build/builtin_interfaces

<== Command '. /home/andreas.pasternak/ros2_ws/build/builtin_interfaces/cmake__build.sh && /usr/bin/cmake -DBUILD_TESTING=1 -DAMENT_CMAKE_SYMLINK_INSTALL=1 -DCMAKE_INSTALL_PREFIX=/home/andreas.pasternak/ros2_ws/install /home/andreas.pasternak/ros2_ws/src/ros2/rcl_interfaces/builtin_interfaces' failed in '/home/andreas.pasternak/ros2_ws/build/builtin_interfaces' with exit code '1'
<== Command '. /home/andreas.pasternak/ros2_ws/build/builtin_interfaces/cmake__build.sh && /usr/bin/cmake -DBUILD_TESTING=1 -DAMENT_CMAKE_SYMLINK_INSTALL=1 -DCMAKE_INSTALL_PREFIX=/home/andreas.pasternak/ros2_ws/install /home/andreas.pasternak/ros2_ws/src/ros2/rcl_interfaces/builtin_interfaces' failed in '/home/andreas.pasternak/ros2_ws/build/builtin_interfaces' with exit code '1'

I guess the issue is this line here:

-- Could not find eProsima Fast-RTPS - skipping rosidl_typesupport_fastrtps_c

So what else do I need to do the get it built? Do I need a different FastRTPS version?

PS: I also had to make this small change

diff --git a/rosidl_generator_c/include/rosidl_generator_c/message_type_support_struct.h b/rosidl_generator_c/include/rosidl_generator_c/message_type_support_struct.h
index eb0702b..6e21d1d 100644
--- a/rosidl_generator_c/include/rosidl_generator_c/message_type_support_struct.h
+++ b/rosidl_generator_c/include/rosidl_generator_c/message_type_support_struct.h
@@ -15,6 +15,8 @@
 #ifndef ROSIDL_GENERATOR_C__MESSAGE_TYPE_SUPPORT_STRUCT_H_
 #define ROSIDL_GENERATOR_C__MESSAGE_TYPE_SUPPORT_STRUCT_H_
 
+#include <stddef.h>
+
 #include "rosidl_generator_c/visibility_control.h"
 #include "rosidl_typesupport_interface/macros.h"

MiguelCompany · 2018-06-12T14:11:10Z

Hi @andreaspasternak

Seems I forgot to add some changes when rearranging my commits.

It should be fixed now

deeplearningrobotics · 2018-06-12T14:52:22Z

@MiguelCompany: Great, it compiles now. Thank you!

…s_c(pp).

MiguelCompany · 2018-07-06T05:36:24Z

Hey @dirk-thomas,

I just rebased on top of master. Could this be reviewed and merged?

deeplearningrobotics · 2018-07-09T18:10:53Z

@dirk-thomas: Can we support you somehow to get this merged?

dirk-thomas · 2018-07-12T21:05:57Z

We are currently waiting for an internal discussion about the desired names of the rmw implementation packages (rmw_fastrtps_cpp vs. rmw_fastrtps_dynamic_cpp vs. rmw_fastrtps_static_cpp) as well as the choice which one to make the default...

--

I think the current conflict is due to #214. Instead of rebasing this huge patch I would suggest we revert the style patch, then this PR can be applied as is and then reapply the style fix. So nothing need to be done in this PR for now.

mikaelarguedas · 2018-07-12T21:13:01Z

I think the current conflict is due to #214. Instead of rebasing this huge patch I would suggest we revert the style patch, then this PR can be applied as is and then reapply the style fix. So nothing need to be done in this PR for now.

Fine by me if reverting #214 resolves the conflict we can reapply it after this being merged.

Though we may want to run uncrustify on this patch as well and fix the style violations before merging.

MiguelCompany · 2018-07-13T09:49:09Z

Though we may want to run uncrustify on this patch as well and fix the style violations before merging.

I agree with this. I have just added a commit with changes equivalent to the ones in #214.

deeplearningrobotics · 2018-07-13T19:22:04Z

@MiguelCompany: While testing this PR: ApexAI/performance_test#2 we run into problems building fastrtpsgen on Ubuntu 18.04. This will then also affect this PR I think as with this PR fastrtpsgen is also required, yes?

MiguelCompany · 2018-07-16T05:11:53Z

@deeplearningrobotics No. This PR does not require fastrtpsgen as the code to de/serialize the ROS messages is created directly using EmPy

deeplearningrobotics · 2018-07-16T11:32:58Z

@MiguelCompany: Can you elaborate this process? Could you also explain the future then of fastrtpddsgen? And what happens if ROS 2 switches from msg to idl type messages?

MiguelCompany · 2018-07-16T12:19:43Z

@deeplearningrobotics Sure.

Package rosidl_parser exports the classes needed to represent the structure of idl files. It also exports functions parse_message_file and parse_service_file to parse a message or service idl file and return an instance of the corresponding class (MessageSpecification or ServiceSpecification), which is used when expanding the templates.

This means that, as the parsing of the idl files is already been done by ROS 2 code, if the switch from msg to idl format is performed, I assume the rosidl_parser package will be updated accordingly.

We will still support fastrtpsgen for applications outside ROS 2, of course.

wjwwood · 2018-07-17T22:57:12Z

@ros2/team are we going to resolve the merge conflict by reverting the style commit or is this a new merge conflict? It would be nice to close this pr out to avoid it continually getting new conflicts.

dirk-thomas · 2018-07-17T23:03:18Z

are we going to resolve the merge conflict by reverting the style commit

Yes, as mentioned in my comment above: #203 (comment)

It would be nice to close this pr out to avoid it continually getting new conflicts.

It is still waiting for a decision on the package naming.

mikaelarguedas · 2018-07-17T23:05:48Z

From #203 (comment)
The conflicting commit will be reverted once this is about to be merged (otherwise our CI will fail as long as this is not merged)

I think the only thing pending is the decision on the naming and the default implementation

wjwwood · 2018-07-18T00:39:20Z

Sorry, I knew you guys had a plan, but I thought (incorrectly) that @MiguelCompany might of fixed it in 9b3be5d and since then a new conflict was introduced, but it looks like that's not the case.

deeplearningrobotics · 2018-07-24T12:21:24Z

@dirk-thomas, @wjwwood, @MiguelCompany: How can we get that merged? Please tell me if you need any support It is pending for 2 months now.

dirk-thomas · 2018-07-24T22:50:27Z

In today's meeting we decided to merge the patch as is (rmw_fastrtps_cpp becoming the static implementation, rmw_fastrtps_dynamic_cpp containing the "old" behavior based on introspection ts).

I will work on merging this and correlated patches to go along with the newly introduced rmw package name tomorrow...

dirk-thomas · 2018-07-25T22:04:10Z

Please see #218 which has been merged and contains the patches from this PR.

tfoote added the in review Waiting for review (Kanban column) label May 30, 2018

mikaelarguedas added in progress Actively being worked on (Kanban column) and removed in review Waiting for review (Kanban column) labels May 31, 2018

MiguelCompany changed the title ~~WIP: Static typesupport~~ Static typesupport Jun 7, 2018

MiguelCompany changed the title ~~Static typesupport~~ WIP: Static typesupport Jun 8, 2018

MiguelCompany force-pushed the static_typesupport branch from 2aa0cbb to d542c14 Compare June 8, 2018 10:28

MiguelCompany changed the title ~~WIP: Static typesupport~~ Static typesupport Jun 8, 2018

deeplearningrobotics reviewed Jun 8, 2018

View reviewed changes

dirk-thomas mentioned this pull request Jun 8, 2018

Nullify pointer to ClientListener in CustomClientInfo in destructor #205

Closed

MiguelCompany force-pushed the static_typesupport branch 2 times, most recently from fba7e0a to 3cda3ad Compare June 11, 2018 07:31

MiguelCompany force-pushed the static_typesupport branch from 3cda3ad to b09afa8 Compare June 12, 2018 14:04

MiguelCompany added 3 commits July 6, 2018 07:20

Refs #3061. Added code generating packages rosidl_typesupport_fastrtp…

eb7d8e3

…s_c(pp).

Refs #3061. Changes for static typesupport on rmw_fastrtps_cpp.

b4d0853

Refs #3061. Fixed (de)serialization of bool.

845634c

MiguelCompany force-pushed the static_typesupport branch from 7638276 to 4515414 Compare July 6, 2018 05:27

0.5.1 & mantainer

1429803

MiguelCompany force-pushed the static_typesupport branch from 4515414 to 1429803 Compare July 6, 2018 05:32

deeplearningrobotics mentioned this pull request Jul 10, 2018

Added the possibility to check the used middleware for memory operations. ApexAI/performance_test#2

Merged

fix template closing indentation

9b3be5d

dirk-thomas mentioned this pull request Jul 25, 2018

split rmw_fastrtps_cpp into static and dynamic rmw impl #218

Merged

dirk-thomas closed this Jul 25, 2018

dirk-thomas removed the in review Waiting for review (Kanban column) label Jul 25, 2018

alsora mentioned this pull request Feb 15, 2019

Strange RAM usage when creating subscriptions #257

Closed

wjwwood mentioned this pull request Mar 27, 2019

Bind a Fast RTPS publisher with a ROS 2 subscriber fails #251

Closed

MiguelCompany deleted the static_typesupport branch April 6, 2021 07:54

Static typesupport #203

Static typesupport #203

Conversation

MiguelCompany commented May 30, 2018 • edited Loading

Summary

Performance test

Performance test results

Allocation test

Allocation test results

dirk-thomas commented May 30, 2018

MiguelCompany commented May 31, 2018

dirk-thomas commented May 31, 2018

MiguelCompany commented Jun 1, 2018 • edited Loading

MiguelCompany commented Jun 7, 2018

dirk-thomas commented Jun 7, 2018

dirk-thomas commented Jun 7, 2018 • edited Loading

MiguelCompany commented Jun 8, 2018 • edited Loading

deeplearningrobotics Jun 8, 2018

Choose a reason for hiding this comment

deeplearningrobotics commented Jun 8, 2018

dirk-thomas commented Jun 8, 2018

MiguelCompany commented Jun 11, 2018

MiguelCompany commented Jun 11, 2018

deeplearningrobotics commented Jun 11, 2018

mikaelarguedas commented Jun 11, 2018

deeplearningrobotics commented Jun 11, 2018

deeplearningrobotics commented Jun 12, 2018

MiguelCompany commented Jun 12, 2018

deeplearningrobotics commented Jun 12, 2018

MiguelCompany commented Jul 6, 2018

deeplearningrobotics commented Jul 9, 2018

dirk-thomas commented Jul 12, 2018

mikaelarguedas commented Jul 12, 2018

MiguelCompany commented Jul 13, 2018

deeplearningrobotics commented Jul 13, 2018

MiguelCompany commented Jul 16, 2018

deeplearningrobotics commented Jul 16, 2018 • edited Loading

MiguelCompany commented Jul 16, 2018 • edited Loading

wjwwood commented Jul 17, 2018

dirk-thomas commented Jul 17, 2018

mikaelarguedas commented Jul 17, 2018

wjwwood commented Jul 18, 2018

deeplearningrobotics commented Jul 24, 2018

dirk-thomas commented Jul 24, 2018

dirk-thomas commented Jul 25, 2018

MiguelCompany commented May 30, 2018 •

edited

Loading

MiguelCompany commented Jun 1, 2018 •

edited

Loading

dirk-thomas commented Jun 7, 2018 •

edited

Loading

MiguelCompany commented Jun 8, 2018 •

edited

Loading

deeplearningrobotics commented Jul 16, 2018 •

edited

Loading

MiguelCompany commented Jul 16, 2018 •

edited

Loading