wjwwood:
It looks like you’ve avoided the need for a new rosidl_generator_flatbuffer-like packages in your flatros2 PoC by using some reflection (a la flatros2/flatros2/include/flatros2/message.hpp at 8a8ad51ffbe363c8e4d8909b548de075d4b26ceb · Ekumen-OS/flatros2 · GitHub ) and you’re using rosidl_typesupport_introspection_cpp to handle support in the middleware, which is nice because it’s above the rosidl/rmw level mostly. However, to gain more optimizations, or for a marshaling library like protobuf or arrow (or even to use flatbuffer better), you’d probably want some build-time step, which is where a rosidl_generator_cpp_X/rosidl_runtime_cpp_X/rosidl_typesupport_cpp_X like set of packages would come in. With that in mind, I guess I don’t know which parts of rosidl need to change, because it seems like, at least in theory, it should be possible to solve these performance problems.
comming from flatros2, and I created protoros2, the name is inspired by flatros2. ZhenshengLee/protoros2: protobuf support for ros2 with non-intrusive modifications.
the protoros2 follows what @wjwwood said the official way to support protobuf serdes(typesupport_protobuf, generator_protobuf, typeadapter_protobuf etc.)
protoros2 is based on the work of Easier Protobuf and ROS 2 Integration - ROS / ROS General - Open Robotics Discourse and New rosidl typesupport based on Google Protobuf - ROS / ROS General - Open Robotics Discourse and Will intrinsic supports ros2 on bazel with bzlmod? - ROS / ROS General - Open Robotics Discourse