| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
This is a mix of a practical question and an academic question.
When, if ever, is it correct to set topic names from parameters? If it is, how do you handle aspects such as the default topic name and clashes with remappings in launch files?
My quick answer is "only when the number of topics being used is unknown". For example, in the navigation stack where you use parameters to control which sensor topics are subscribed to in order to detect obstacles.
At all other times I think remapping should be used.
However, if there are cases where remapping is not powerful enough, then parameters might be appropriate, but I would say that's a work around and instead we should try to improve remapping to allow for more complex cases. For example, in ROS 2 we described how you could use regex-like behavior in remapping, e.g. remap /front/*/image_raw to /front_new/\1/image_raw(see https://design.ros2.org/articles/stat...), which more cases than were allowed in ROS 1.
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". I deal with clashes of remapping by not using ...
My comments on your comments:
re: situation 1: that seems like a slightly different case, as the topic names are not "set from parameters" I feel. You have N items as part of a parameter dict, which then causes, eventually, N topics to be created.
re: situation 2: remapping with nodelets in a processing pipeline: that's actually exactly what the pattern is that is very often used :) See the nodelets in pcl_ros fi. They all have fixed input and output topics which get remapped to connect everything together.
I never want my complexity in an XML file I have to sit there and read through a debug.
so now you split the complexity between two places: the logic in the nodelet to create the topics based on parameters and the .launch + .yaml file that loads the parameters. I've seen many things go wrong with .launch and .yaml files ...
Re-reading your answer @stevemacenski, this:
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.
is a really strong opinion. Could you describe a bit more the "clashes of remapping"? I'm not sure I understand that.
@Geoff: could you perhaps give an example of how parameters would solve "clashes with remappings in launch files" (seeing as you brought it up)?
If remapping is considered part of an application level (or subsystem level) configuration activity, then I'm not entirely sure how clashes could occur. The "hand of god" putting the system together should be aware of those (and if perhaps not a priori, at least a posteriori).
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.
is a really strong opinion.
I agree that this an atypical opinion in my experience, and I actually think that if you're not using remapping then your nodes are not designed to be reused. That might acceptable in some cases, but generally I wouldn't recommend it.
For example, a driver node for a laser should publish to scan not /my/namespace/for/my/project/scan_unflitered, and remapping should be used to setup the topic name as you want. The author of the node should keep it generic, and users should not edit the source of the driver just to avoid using remapping.
Also if your node is using parameters to determine the topic name, e.g. two ...
I believe that configurations have no place in the launch system. Remapping implies that you have robot specific configurations inside of launch files. I think a certain level of configuration within the launch files are fine, things that are either direct arguments or derivatives of arguments into the launch file, or pulling from environmental variables, etc.
What I don't want, is hardcoded values in my launch files that makes them hard to be reused. If there's a configuration element, I want that in a parameter file that is easier to control and version control. The most frustrating type of debugging I do is when I have to read through XML and find that there was a remap and either its wrong, inconsistent with documentation, or misspelled. This was a major point actually from the ROSCon 2019 talk on common bugs found in ROS code.
Atypical?, that's my ...
@William, my assertion is that the code itself should have supported a topic parameter to not require the need for a remap. Not that you've remapped a topic in a launch file, it is now a hard-coded parameterization outside of the configuration files you need to keep an eye on if you are trying to share a codebase with potentially dozens of variations of robots. I find that additional thing to be unscalable.
The 2 situations you mention are both solved by parameters, that doesn't create launch dependencies on configurations.
@stevemacenski: if launch files are not what orchestrates your ROS application, what do you use? Because I believe that is the level @Geoff was mostly considering when he asked the question.
You seem to be thinking of launch files that wrap one or two nodes.
I still don't really understand how reading a .yaml is any easier than an .xml file, but that may be personal.
Well I think that asks another question that's not directly related. I'm talking about launch files that wrap one or two nodes, sure, but when you wrap then those in a launch file to bring up a robot / full application, you're largely missing reuse opportunities if there's remaps in the launch files. You then require to have different launch files for different configurations of robots rather than being able to have the nodes configure themselves based on parameters or globals.
XML contains the configurations of remaps, sure, but also contains a bunch of other stuff. If you're trying to change a configuration or debug a problem for why X data isn't getting to Y node, then all the other stuff (that I'd argue is what launch files are meant for) is "in the way" for configuration debug and management.
@Geoff: could you perhaps give an example of how parameters would solve "clashes with remappings in launch files" (seeing as you brought it up)?
I don't think they would. If you have a parameter to set a node topic, and then someone tried to use a remapping, I'm not sure which would take priority and either way it would lead to confusion. Not using the tool designed for the task you are doing to avoid clashing with your use of another tool to do that task seems backwards to me.
Asked: 2020-01-28 21:17:07 -0500
Seen: 1,313 times
Last updated: Jan 30 '20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Just a quick note: if remapping worked slightly better (ros/ros_comm#954, ros/ros_comm#236 and ros/ros_comm#209 fi) I would actually answer "never" to your question. As it is, using parameters may sometimes be the faster option to "get something to work".
Remapping is part of configuration of the application, not the node. It's an activity that happens outside of the node itself, as it is part of the composition step of your application.
If you start using parameters for this, separation of concerns seems violated to me, as suddenly nodes become responsible for 'knowing' how to integrate into a composite. That's not something I'd like.
Edit: just noticed the
eloquenttag. As there is also amelodictag, I linked to issues inros_comm.I tried to start a conversion and I was down voted for it :(
The voting here is whether you agree or disagree with the stated answer to try to build a consensus on what is the best approach. It's not a measure of the value of your statements or the validity of your concerns. But if an individual doesn't think that the answer is something that someone in the future should follow that's why they would downvote it.