Questions on Zero-Copy for Variable-Size Messages (PointCloud2) with Iceoryx in ROS 2

Hi there! I can’t speak for RouDI configuration, but…

How should we handle messages where the size is not strictly fixed at compile-time while still maintaining zero-copy benefits?

The standard answer is you don’t. If you have control over the middleware, you can try to implement rmw_publisher_allocation_t and rmw_subscription_allocation_t APIs to pre-allocate and then loan your messages both ways. If you have control over messages, you can craft your own and ensure they are fixed size. IIRC that’s what the first demos for rmw_iceoryx used to do (see fixed_size_ros2_demo/fixed_size_msgs/msg at master · Karsten1987/fixed_size_ros2_demo · GitHub ).

Otherwise, intraprocess comms in rclcpp is a popular escape hatch.

If you are generally interested in the topic, the Accelerated Memory Transport Working Group is trying to address this. Nvidia is working on pushing large buffers to GPU memory. Like Nitros but ROS native. Should land in time for Lyrical. See Native buffer type . And I’m personally working on a reference implementation of REP-0157, which is still draft. Should go public at some point later this year.

2 Likes