Investigate adding in explicit IPC for Nav2 nodes again

[SteveMacenski]

Previously, we didn't do this since IPC required the use of only the default QoS profiles and we use several others in Nav2 for various things. We should investigate if this challenge has been overcome now and we can use IPC.

Additionally, Nav2 default launches with rviz2 and application nodes that may subscribe to topics outside of the container. In this case, these performance improvements are negated, but I suppose worthwhile to include unless there's some reason not to. I believe that only the topics that are communicating outside of the process break IPC, but worth checking on that to make sure the entire node isn't broken out of IPC for a debug logging topic or something.

It would be great to get an update from @clalancette on these thoughts -- then execute as it is seen fit.

[clalancette]

It would be great to get an update from @clalancette on these thoughts -- then execute as it is seen fit.

So during the Jazzy development cycle, we ended up merging in https://github.com/ros2/rclcpp/pull/2303 , which added transient_local functionality to the intra-process manager. However, as far as I understand, the intra-process manager still doesn't support the full range of QoS options.

Still, if transient_local functionality is enough for your use-case, you could consider turning it on. There are 2 different ways to turn it on:

1. You can pass an rclcpp::NodeOption when constructing the node that will create all publishers and subscriptions (including the built-in ones) as intra-process.
2. When you create individual publishers and subscriptions, you can turn on intra-process mode for just that entity.

Additionally, Nav2 default launches with rviz2 and application nodes that may subscribe to topics outside of the container. In this case, these performance improvements are negated, but I suppose worthwhile to include unless there's some reason not to. I believe that only the topics that are communicating outside of the process break IPC, but worth checking on that to make sure the entire node isn't broken out of IPC for a debug logging topic or something.

The intra-process manager is fairly sophisticated. If a publisher and subscription on the same topic with the same type are created within the same Context, and intra-process is turned on for both of them, then it will communicate between them using only intra-process. If any one of those conditions is false, it won't use it. However, even in the case where intra-process is used, it still always creates a DDS entity for the outside world to discover. That's so that things like ros2 topic list still show the topic. In the case where you have an intra-process publisher, an intra-process subscription, and a non-intra-process subscription, then what happens is that intra-process is still used between the publisher and the intra-process subscription, and a copy is used to send out to the non-intra-process subscription.

All of that is to say is that the intra-process manager will do the correct thing in all situations, though the efficiency goes down somewhat in situations other than a single intra-process publisher and single intra-process subscription.

[SteveMacenski]

still doesn't support the full range of QoS options.

Are the 'main' 4 (history, durability, depth, reliability) fully covered? We use throughout Nav2 all the options for those four in various places, but not sensitive about the deadline, lifespan, liveliness, or lease duration (yet, at least).

In the case where you have an intra-process publisher, an intra-process subscription, and a non-intra-process subscription, then what happens is that intra-process is still used between the publisher and the intra-process subscription, and a copy is used to send out to the non-intra-process subscription. All of that is to say is that the intra-process manager will do the correct thing in all situations, though the efficiency goes down somewhat in situations other than a single intra-process publisher and single intra-process subscription.

I believe then I was either initially misinformed or something has changed since I last looked -- was at any point it true that if a subscription was outside of IPC (intra-), it changed all subscriptions to be inter-process?

Follow up question: If we have 2 subscriptions, one intra-process and one inter-process, is the performance any worse on the system by enabling (intra-) IPC than if we did not at all? I assume not, but your the wording of that response makes me want to clarify if there's any reason not to always enable IPC now.

It also used to be true that IPC (intra-) would throw if a sub/pub was using QoS that IPC couldn't handle. Is that still the case or can we enable IPC (intra-) globally now in the software and it'll use where it can, but default back to inter-process (though still with composition benefits) where it cannot?

Thanks for the follow up :-) It looks like IPC has made some great gains since the last I looked at this in the early Foxy days. We got such good performance boosts from Composition and the QoS would throw for the non-default profile, we weren't able to move further. It sounds like we might be able to fully embrace IPC now across the board for another joyous performance boost!