message_filters
message_filters copied to clipboard
ros2
std::unique_ptr not supported
In order to get zero-copying inter-communication, std::unique_ptr are required. Unfortunately message_filters does not yet support std::unique_ptr.
duplicate with https://github.com/ros2/message_filters/issues/28 which is already answered by https://answers.ros.org/question/325146/how-can-i-implement-efficient-intra-process-communication-with-message-filters/
I'm also finding myself needing this. Any update?
can be closed.
I wouldn't close this issue, the answer provided only proposes a workaround, it would be nice to have a PR for this if it's a viable solution approved by the maintainers
I agree. I will try to implement if I have time, but I'm not making any real commitment, so feel free to do the same and open a PR pointing to this issue.
Moreover, be aware that rolling supports Type Adaptation (did a PR some time ago #95). This means that, in conjunction with intra-process comms, we would be able then to leverage the full spectrum of solutions to optimize wide ROS data exchange.
I'm giving it a look.
In my experience, I always used const MessageType::ConstSharedPtr as subscription callback type, and built MessageType::UniquePtr to be later ->publish(std::move(...))d.
message_filters make use of std::shared_ptr<MessageType const> signature, which is equivalent to MessageType::ConstSharedPtr.
It made be worth a try just to add const and see what happens as a first iteration.
To be completely honest, it seems to me that: https://github.com/ros2/rclcpp/blob/9019a8d9b7710bd405a5a31c8d74fdc9ffa686dd/rclcpp/include/rclcpp/any_subscription_callback.hpp#L935 just requires the pointed object of the shared_ptr to be const, not necessarily the pointer itself.
May I ask to you all to verify?
@tonynajjar @AndreasAZiegler may I ask you to test #103 and see if you get any performance gain?
Hey, I can try tomorrow. What should I be on the lookout for exactly? CPU consumption? Anything else? As far as I know the msg memory address should be the same regardless of the change in the PR right?
@tonynajjar was the address already the same in previous test of yours?
Because otherwise I may have lost the meaning of the problem in your previous comment:
I'm also finding myself needing this. Any update?
May I ask you to clarify what was the issue/need, if different?
@tonynajjar was the address already the same in previous test of yours?
When I made my first comment I hadn't tested anything yet, I was about to start working on a project in which I needed message_filters to support IPC and I took it for granted that it doesn't because of this ticket.
Now I did some tests on a particular setup of mine and without your changes, I'm able to get the same msg address for both the publisher and the message_filters subscriber. That's the only indication I know of that suggests that IPC is working. Currently I don't have a minimal reproducible example I can share, I'll try to find some time for that
Ok, nice to know. Then, I do not see any other internal copy or other blocking issue preventing message_filters to be IPC-friendly :)