Experiment: shared-memory and type-adapted paths for faster point cloud transport

[Maik13579]

Hey,

I have been experimenting with a few ways to speed up transport of large sensor messages, especially images and point clouds. I thought I would share what I built in case it is useful for future point_cloud_transport improvements or related discussions.

Repo: https://github.com/Maik13579/ros2_shm_sensor_transport

Small disclaimer: I developed and tested this on ROS 2 Jazzy, so it may need some adjustments for other ROS 2 distributions.

What I tried

1. Shared-memory transport for sensor payloads

First, I implemented a shared-memory publisher/subscriber path for large sensor messages.

The basic idea is:

• Keep the normal ROS message structure for metadata.
• Extract the large payload buffer, for example:
  • sensor_msgs/msg/Image::data
  • sensor_msgs/msg/CompressedImage::data
  • sensor_msgs/msg/PointCloud2::data
• Write that payload into a shared-memory ring buffer.
• Publish a small metadata message containing the shared-memory object name, slot, sequence number, and layout information.
• The subscriber receives the metadata, reads the payload from shared memory, validates that the slot was not overwritten while readings and reconstructs the original ROS message.

This gives a more efficient inter-process path for large local sensor streams, while keeping the message semantics close to normal ROS usage.

2. image_transport and point_cloud_transport plugins

After that, I added transport plugins for both:

• image_transport
• point_cloud_transport

These expose the shared-memory path through the existing transport plugin APIs.

So users can select the SHM transport in the same style as other transports, while the plugin internally moves the large payload through shared memory instead of sending the full serialized message through DDS.

3. Type-adapted transport wrappers

I also experimented with REP-2007 type adapters.

The goal is to support applications that use custom C++ data types internally, while still remaining compatible with normal ROS tools and external subscribers.

The wrapper publisher/subscriber works roughly like this:

• Public subscribers still receive normal ROS messages through image_transport or point_cloud_transport.
• Same-process subscribers can receive the adapted C++ type directly through ROS 2 intra-process communication.
• If only same-process adapted subscribers exist, the publisher can avoid converting the custom type into the ROS message entirely.
• If external/public subscribers also exist, the publisher converts once for the public transport path and also publishes the adapted object locally.
• For std::unique_ptr<T> publishing/subscribing, same-process delivery can preserve ownership transfer and avoid copying the adapted object under the right circumstances.

For point clouds, this means a node can publish a custom cloud representation locally with low overhead, while external consumers can still subscribe to the normal sensor_msgs/msg/PointCloud2 topic via point_cloud_transport.

Why I am sharing this

I am not sure whether this belongs directly in point_cloud_transport, as a plugin, or as a separate experimental package. But I thought the ideas might be useful.

Maybe some of this could help improve high-throughput point-cloud pipelines or inspire future transport features.

Happy to share more details if this direction is interesting.