ROS2: Create Shared Message from ROSCon 2014

Hi,

I was going through old slides and came across some lines auto msg = pub->create_shared_message() in the slide deck from the state of ROS2 in 2014 [1].

While that’s clearly been long going since at least beta3, I was curious to learn why that functionality was removed. That seems actually very useful and from some discussions we’ve had on the real-time front regarding getting loaned messages from the middleware to take some reserved memory, this seems like a natural way to do it from a user-level API. Recreating it, or some derivative, could get folks in the work flow that will be necessary later on when that is implemented.

I see some comments on loaned messages that didn’t quite make it for Eloquent [2], but I can’t really find any reference other than this slide deck to the create_shared_message() incarnation of the API in rclcpp, rcl, or rclc (no tickets or PRs reference it). Clearly [1] and [2] are not directly correlated, just noting the value that a method like this may have for wrapping that concept to a user.

CC @Dejan_Pangercic

[1] https://www.osrfoundation.org/wordpress2/wp-content/uploads/2015/04/ROSCON-2014-Why-you-want-to-use-ROS-2.pdf
[2] https://github.com/ros2/ros2/issues/734

I can’t speak to why that specific API is no longer around, but you can find what did land in Eloquent here in terms of zero-copy support: https://github.com/ros2/ros2/issues/785

While many of the structures and apis are in place, currently the only middleware that supports it is https://github.com/ros2/rmw_iceoryx. @karsten1987 gave a presentation on this at ROSCon 2019: (slides) (video)

I think that the closest current analogy is the new rclcpp api: publisher->borrow_loaned_message() , which should return either a) a shared memory segment or buffer (if the underlying rmw supports it), or b) use a user-provided allocator to internally allocate the message.

You may also be interested in the Design Document for Zero Copy API

1 Like

I see some comments on loaned messages that didn’t quite make it for Eloquent [2]

@smac which comments are you referring to in terms of loaned messages which didn’t make it? Or asked differently, which functionalities are you currently missing for working with loaned messages?

I’m just purely going off the checklist of tasks undex Apex that wasn’t checked with loaned messages.

This just seems to be a far more natural user-facing API than borrow_loaned_message() for the typical user that really shouldn’t need to care how it was made. It’s just giving them a message to work with.

That’s exactly what borrow_loaned_message() does, lends them a message which may or may not be allocated on demand. They can work with that message, and when done they can return the loan.

If you just want a new message and don’t care where it comes from, then I suggest you just use std::make_shared<MsgT>, right?

Based on:

It seems like you do want the middleware to optimize this if possible and if not, give the user a heap message to work with, which again is what pub->borrow_loaned_message() does, I think.

1 Like

Got it. I think then the remaining comment is then more pedantic in naming.

I know that’s exactly descriptive about what it does, but I strongly disagree with much of the ROS2 user-facing APIs. I think its far too “powerful” for the average or novice user to a point of making it unapproachable without detailed knowledge of what’s happening under the hood. Whenever that API review comes around, I’ll give a more formulated argument on it… I have a reasonable understanding of what’s going on because I sit here doing this all day, but I don’t think that’s representative of the userbase of ROS1.

but sounds like my question was answered: it basically is there, just under another name, but not widely used as its not widely implemented by RMWs.

1 Like

I fully agree on the complexity of the API. The ROS1 succeeded due to its approachability in terms of threshold before being able to publish& subscribe, but it was built for R&D.

ROS2 goes for an industrial approach with production in mind.

These two worlds are not much aligned in terms of objectives (research vs Industry). One aims on quick prototyping to test algorithms while the other look for robustness and reliability with an increased complexity.