Determine best-practice for setting topic names on nodes
Two methods exist for setting/changing a topic name for a node at runtime:
- Creating a publisher/subscriber with a hard-coded, "default" topic name in the constructor, which can be remapped through topic name remapping.
- Providing a string parameter which is parsed by the node, then used in the constructor of the publisher/subscriber.
Both methods are used in different locations in the Autoware.Auto codebase. The ROS style guide does not recommend one or the other and both have pros and cons, which I will try to summarize here. This issue exists to attempt to realize a consensus. Once a consensus is reached, another issue will be created to track the implementation of that decision.
Hard-coded Default with Name Remapping
Pros
- The default name is guaranteed to exist prior to remapping and is not dependent upon external files (e.g. launch files).
- Namespacing the node correctly namespaces all included topic names, unless the hard-coded default is relative to the root (e.g.
/scan
). - Remapping can be done from the command-line.
- The design docs indicate that dynamic name remapping will eventually be implemented.
- Once dynamic topic name remapping is implemented, there is no need to reconstruct the publisher/subscriber object if the topic name is changed.
- Less code is required due to the lack of a parameter for each topic.
Cons
- The default name is harder to find for users of the node unless it is properly documented in the API documentation.
- Topic name remapping does not seem to be currently supported in the Python launch file syntax (though I may have missed it). It is supported in XML syntax (Eloquent and above).
- Remapping a topic requires you to know the default value while setting a parameter does not.
- Remapping a topic name must be done on the command line or in a launch file (see caveat above) and can not be done in a parameters YAML file.
Parameters for Topic Names
Pros
- Requiring the user to provide a new name for the topic is easy because the parameter can be set to "required."
- Since dynamic name remapping is not yet implemented, you can provide a pseudo-implementation by using a parameter change callback.
- Topic names can be set in the same parameters YAML file as all other parameters.
Cons
- There is a choice to be made if a "default" topic name is desired for a given topic:
- If you give the parameter a default value, making it a required parameter makes the default value useless.
- If you don't give the parameter a default value, it will be a required parameter in which case there is no "default" name as it must always be provided by the user.
- More code is required because you should (in theory) have a parameter for every topic name to which the node subscribes or publishes.
- Implementing the pseudo-implementation of dynamic name remapping using a parameter change callback requires re-constructing the associated publisher/subscriber on a name change.
This is by no means a comprehensive list - I'm looking for feedback from other developers/maintainers on this issue.