Revision history [back]

I'll go with a couple examples

Situation 1: You have a configurable number of sensors you'd like to subscribe to. You don't know at compile time what they are, or how many there are going to be. Examples: Navigation stack's voxel layer allowing many sensors. Remaps don't make sense because you'd then have to create unbounded N subscribers for every sensor topic because you don't know how many of N sensors a user might want. Another example in SLAM Toolbox allowing for multiple laser scanners for a similar purpose.

Situation 2: You have created something similar to a ROS1 nodelet that is intended to be part of a nodelet chain. You have a multi-stage processing pipeline for a depth camera or something for filtering or data processing. In that case, you have a fixed input and a fixed output for each stage, probably just manipulating the same data. In this situation, you could remap everything, but that's very, very ugly and complex in a launch file. I never want my complexity in an XML file I have to sit there and read through a debug. I will always create those topics as parameters so that there's a configuration file that has the namespaced node with the input_topic: XYZ and output_topic: ABC so that when I clearly read a configuration file, I can clearly see what's input goes to what output. And this is especially compact if there's a directional graph like structure to your processing pipeline. A simple yaml file is easier to read and maintain than an XML file with 10 stages. This situation is getting a little ranty but one more point: would you rather have 5 yaml files for different configurations or 5 launch files with different configurations?

Situation 3: You're writing something for outside consumption. That can be "outside" as in outside your organization (ei open source) "outside" as in outside this project (ei an external facing topic for the Navigation project like a sensor or output result). If its not "outside" in one of these ways, I will probably not create a parameter because the likelihood of me needing to change it are slim to none. And for the case I do, remapping is still available.

If a package contains any of these situations, I automatically parameterize all other topic names for inputs. Once you do one, it would be inconsistent to not do it with all. Since output topics are still consistent (a map is a map is a map, and only one of them, etc) I would not parameterize the output topic.

tl;dr, by my use, I pretty much always parameterize inputs, but nearly never do outputs, unless in Situation 2. Typically, I will parameterize topics related to sensor data almost instinctively because its "outside".

I'll go with a couple examples

Situation 1: You have a configurable number of sensors you'd like to subscribe to. You don't know at compile time what they are, or how many there are going to be. Examples: Navigation stack's voxel layer allowing many sensors. Remaps don't make sense because you'd then have to create unbounded N subscribers for every sensor topic because you don't know how many of N sensors a user might want. Another example in SLAM Toolbox allowing for multiple laser scanners for a similar purpose.purpose. Now, once you make a parameter for one, its inconsistent to not do them for all.

Situation 2: You have created something similar to a ROS1 nodelet that is intended to be part of a nodelet chain. You have a multi-stage processing pipeline for a depth camera or something for filtering or data processing. In that case, you have a fixed input and a fixed output for each stage, probably just manipulating the same data. In this situation, you could remap everything, but that's very, very ugly and complex in a launch file. I never want my complexity in an XML file I have to sit there and read through a debug. I will always create those topics as parameters so that there's a configuration file that has the namespaced node with the input_topic: XYZ and output_topic: ABC so that when I clearly read a configuration file, I can clearly see what's input goes to what output. And this is especially compact if there's a directional graph like structure to your processing pipeline. A simple yaml file is easier to read and maintain than an XML file with 10 stages. This situation is getting a little ranty but one more point: would you rather have 5 yaml files for different configurations or 5 launch files with different configurations?

Situation 3: You're writing something for outside consumption. That can be "outside" as in outside your organization (ei open source) "outside" as in outside this project (ei an external facing topic for the Navigation project like a sensor or output result). If its not "outside" in one of these ways, I will probably not create a parameter because the likelihood of me needing to change it are slim to none. And for the case I do, remapping is still available.available.

If a package contains any of these situations, I automatically parameterize all other topic names for inputs. Once you do one, it would be inconsistent to not do it with all. Since output topics are still consistent (a map is a map is a map, and only one of them, etc) I would not parameterize the output topic.

tl;dr, by my use, I pretty much always parameterize inputs, but nearly never do outputs, unless in Situation 2. Typically, I will parameterize topics related to sensor data almost instinctively because its "outside".

I'll go with a couple examples

Situation 1: You have a configurable number of sensors you'd like to subscribe to. You don't know at compile time what they are, or how many there are going to be. Examples: Navigation stack's voxel layer allowing many sensors. Remaps don't make sense because you'd then have to create unbounded N subscribers for every sensor topic because you don't know how many of N sensors a user might want. Another example in SLAM Toolbox allowing for multiple laser scanners for a similar purpose. Now, once you make a parameter for one, its inconsistent to not do them for all.

Situation 2: You have created something similar to a ROS1 nodelet that is intended to be part of a nodelet chain. You have a multi-stage processing pipeline for a depth camera or something for filtering or data processing. In that case, you have a fixed input and a fixed output for each stage, probably just manipulating the same data. In this situation, you could remap everything, but that's very, very ugly and complex in a launch file. I never want my complexity in an XML file I have to sit there and read through a debug. I will always create those topics as parameters so that there's a configuration file that has the namespaced node with the input_topic: XYZ and output_topic: ABC so that when I clearly read a configuration file, I can clearly see what's input goes to what output. And this is especially compact if there's a directional graph like structure to your processing pipeline. A simple yaml file is easier to read and maintain than an XML file with 10 stages. This situation is getting a little ranty but one more point: would you rather have 5 yaml files for different configurations or 5 launch files with different configurations?

Situation 3: You're writing something for outside consumption. That can be "outside" as in outside your organization (ei open source) "outside" as in outside this project (ei an external facing topic for the Navigation project like a sensor or output result). If its not "outside" in one of these ways, I will probably not create a parameter because the likelihood of me needing to change it are slim to none. And for the case I do, remapping is still available.

If a package contains any of these situations, I automatically parameterize all other topic names for inputs. Once you do one, it would be inconsistent to not do it with all. Since output topics are still consistent (a map is a map is a map, and only one of them, etc) I would not parameterize the output topic.

tl;dr, by my use, I pretty much always parameterize inputs, but nearly never do outputs, unless in Situation 2. Typically, I will parameterize topics related to sensor data almost instinctively because its "outside"."outside". I deal with clashes of remapping by not using remapping. I see that mostly as a debug tool and shouldn't be used in production settings when it can be helped.