It would be good to do some auditing on QoS settings in Nav2 and make sure that they are sensible. In particular:

• Subscriber depths should be as minimal as possible to keep the data fresh and only process what is live and needed. Older data probably doesn't need to be kept if the system isn't keeping up. However:
• Publisher depths should be larger, such that they can keep a queue (when using async publication) to process to make sure messages aren't lost, its up to the subscriptions to decide they're not interested
• Remove or reduce use of best effort QoS that has the unfortunate side effect of blasting data at full rate, even if the network is having trouble keeping up, without any ACKs. Really, this should be used sparingly when on the same CPU. best effort's CPU performance is pretty not-great and can make network issues worse due to its ignorance about what else is going on and its own communication status
• Transient local for any static published data states

Consider also adding in support for the newer features like:

• Deadline to notify when issues arise and handle them
• Lifespan to disregard sufficiently old data
• Liveliness to possibly replace bond in the lifecycle manager (but probably not?)

It might also be good to have launch files that launch and process a discovery server to reduce network traffic.

DDS configs like transport layer, sync vs async, local host only, buffer / fragment sizes, unicast, etc should be left to the user's setup

Considerations

I think we could have a set of Nav2 specific QoS policies for "publishers", "subscribers", and "latched" so that these are portable and consistent across the code base. During the audit, rather than fix each one, we can move each to use our default profiles, unless there is a compelling reason for some to be differentiated.

We could even wrap the create_XYZ() factories in a Nav2 version that also does things under the hood with respect to QoS override acceptance, deadline/liveliness callbacks (nav2_utils::LifecycleNode to handle), perhaps even lifecycle for subscription, etc