@alsora thank you for that context, that is incredibly valuable insight to have our observed behaviors confirmed. That solidifies our decision to use manual composition with single threaded executors for the time being. It’s always hard to tell if this is “did I miss something?!” or actual behavior.
We’ll need to wait for more QoS profiles to be usable with intra-process comms before we can enable that in the stack.
I now have a little bird chirping in my ear about potentially making the default bringup scheme for Nav2 be a manually composed bringup to have this behavior come out by default. However since we still can’t do lifecycle-components in launch, it would have to be manually composed.
Which would work fine, the main concern I have is around localization system vendorization (e.g. AMCL, SLAM Toolbox, other systems) if manually composed. Perhaps separate out the localization system but have the rest of Nav2 be manually composed? What do you think? I think the rest of the servers / system are pretty standard for everyone’s use and if they don’t want one of them, they could always remove it from the list of nodes to transition up in lifecycle manager and leave very little overhead (but they should probably just create a new manual composition file with what they need in their company’s specific bringup package)