[FEA] add typeadapter(REP2007) to access protobuf struct directly.

[ZhenshengLee]

Feature description

this repo points to make proto file the single truth of idl of the ros2 system

but for now, the inner communication serdes are still cdr, because the protos are transfered to rosidl.

typeadapter(REP-2007) utility enables rmw_vendor_protobuf_cpp to use typesupport_protobuf_cpp, just like what rosidl_typesupport_protobuf did New rosidl typesupport based on Google Protobuf, with rmw_ecal_proto_cpp and rosidl_typesupport_cpp.

but rmw_ecal_proto_cpp+rosidl_typesupport_protobuf make rosidl first class, and presume user will use msg file, which did not match proto2msg’s need.

so, if typeadapter added to proto2msg, rmw_iceoryx2_proto_cpp(a fork of rmw_iceoryx2_cpp or other rmw) may use the proto as first class serdes, and cdr(when other rmw nodes join the graph), and zerocopy(if idl is a supported POD).

Additional considerations

flatros2 is a non intrusive modification of ros2 to enable flatbuffer serdes

https://github.com/Ekumen-OS/flatros2/blob/main/README.md

[mhidalgo-rai]

@ZhenshengLee thanks for the ticket! Though I must say I'm not 100% sure what you are proposing.

proto2ros transpiles Protobuf messages into a ROS 2 messages, with suitable conversion functions to aid conversion higher up the stack. To the best of my knowledge, type adaptation is an rclcpp feature. Non-message types never make it all the way down to the middleware. I guess you could rework rclcpp type adapters to forward protobufs unmodified, and push proto2ros conversions to a type support wrapping another (e.g. FastRTPS' CDR based typesupports), but that's way, way out of scopre for proto2ros. That'd be a non-trivial, cross-stack change.

[ZhenshengLee]

@mhidalgo-rai thanks for your reply!

To the best of my knowledge, type adaptation is an rclcpp feature. Non-message types never make it all the way down to the middleware

you are right.

and please look at https://github.com/intrinsic-opensource/ros-central-registry/blob/main/examples,

rclcpp::Publisher<example::msg::pb::ExampleMessage>::SharedPtr publisher_;

this example enables developer to create protobuf message in the user space, and use rclcpp::Publisher directly publish the protobuf message. this rclcpp feature relies on REP2007 typeadaption feature, and RCLCPP_USING_CUSTOM_TYPE_AS_ROS_MESSAGE_TYPE support added to rclcpp since ros2 Jazz.

currently this feature is made by eCAL community(continental), and typeadapter is provided by https://github.com/eclipse-ecal/rosidl_typesupport_protobuf , actually this repo provide 3 parts:

1. proto_ros_conversion: typesupport_protobuf_cpp namespace convert_to_ros() and convert_to_proto(), that's what proto2ros do, but in rclcpp user layer
2. typeadapter: provides feature to rclcpp that user can access pb_msg struct
3. typesupport_handle and serialize() deserialize() function.

typeadapter is reused by rclcpp layer, while the typesupport_handle and serdes() then be used by rmw layer, in the case of middleware the use proto as ssot, https://github.com/eclipse-ecal/rmw_ecal/tree/master/rmw_ecal_proto_cpp, with rmw_ecal_proto_cpp, inner serdes is protobuf.

the inner serdes in rmw layer becomming protobuf makes data in ros2bag(mcap) protobuf binary, which make mlops pipeline in cloud directly access protobuf files, which saves a lot of cputime, ML loves protobuf.

the differenence between proto2ros and rosidl_typesupport_protobut/rmw_vendor_proto_cpp is

1. proto2ros makes proto the SSOT(single source of truth), and provides proto_msg_conversions
2. rosidl_typesupport_protobuf/rmw_vendor_proto_cpp, makes msg the SSOT, and provides, proto_msg_conversions, typeadapter and rosidl_typesupport

then , like what I said in the top, I suggest that proto2msg provide typeadapter, so we can make true protobuf SSOT

finally, I have created https://github.com/ZhenshengLee/protoros2, there are some POC of what I said.