Skimming through it, it would seem that from a very high-level this is similar to using shared-memory for the entire message (ie: like nodelets in ROS 1) but then using pub-sub for the *reference to the object* in the shared-memory segment.
It's not clear to me from the paper what the benefit is of splitting up the message in a part that uses regular serialisation ("control part") and a part that gets pushed into shared-memory: it would seem that you get the disadvantages of using a shared message anyway (ie: nodes cannot change "their copy" without affecting the message contents for all subscribers), and messages cannot be presented to callbacks without having deserialised the control part.
The latency improvements are to be expected: (de)serialisation times in ROS 1 and 2 are typically mostly dominated by fields that are larger than the L1 / L2 cache of the CPU used (depending on memory bandwidth), so if you can skip those it will instantly improve message throughput (almost linearly).
The authors also don't discuss compatibility with nodes not using this transport. From the description it would seem there is no fallback to full serialisation when communicating with non-extended nodes. Nodelets are certainly not perfect, but at least supported some measure of graceful degradation.
---
Edit: re: why split the message: it's not made very clear, but this sentence seems to provide a possible rationale:
> The ETHZ-ASL framework eliminates copying operations, but multiple serialization operations remain. This is because the whole message is too complicated to be shared within shared memory without serialization.
"too complicated" is a bit vague though.
---
[Visit Topic](
https://discourse.ros.org/t/tzc-efficient-inter-process-communication-for-robotics-middleware-with-partial-serialization/6264/5) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)