[roslaunch] Load parameters in node namespace from outside the node

Hello everyone,

in my package, I have the following (simplified) launch file called, say, "my_node.launch":

<!-- File my_node.launch -->
<launch>
<node pkg="my_pkg" type="my_executable" name="my_node">
<!-- Load private node params here ... -->
</node>
</launch>


This launch is included in another file, say "general_file.launch". What I would like to do is to load a bunch of parameters contained in a yaml file (say, "params.yaml") in the private namespace of "my_node" from "general_file.launch" - these parameters are not used by "my_node", but conceptually they belong to its namespace (not sure if it does make sense, happy to hear motivations against doing it).

The only workaround I was able to find is to add the name of the yaml file as argument in the "my_node.launch" and load the file inside the <node> tag, as follows:

<!-- File my_node.launch -->
<launch>
<arg name="param_file_name"/>
<node pkg="my_pkg" type="my_executable" name="my_node">
<!-- Load private node params here ... -->

<rosparam command="load" file="$(arg param_file_name)"/> </node> </launch> <!-- File general_launch.launch --> <launch> <include file="$(find my_pkg)/my_node.launch">
<arg name="param_file_name" value="$(find my_pkg)/params.yaml"/> </include> </launch>  Is that the only way to achieve it? Thanks in advance for the help. EDIT Just to expand a bit more on the conceptual setup. "my_node" is the "ROS driver" for a device (a node that writes command to / reads data from a port where the device is connected to). Our system has a set of different devices, each one having its own ROS driver; in order to implement some sort of "plug & play" mechanism, the ROS driver of each device publishes at the start-up an identifier which is used by other nodes in the system. To limit the number of configuration parameters, we decided to use the node name as the identifier of the ROS driver; this has the additional advantage that it is guaranteed to be unique in the system, so it seemed a sensible choice. The recipients of the device ID may need to load some configuration parameters associated with that device, and try to look for them in the namespace represented by the identifier, which happens to be the same as the ROS driver's private namespace. What I'm trying to achieve is to structure the configurations to avoid typing the same parameter multiple times across different launch files - this in order to take out possible configuration inconsistencies out of the loop when doing integration tests. edit retag close merge delete Comments 1 What I'm trying to achieve is to structure the configurations to avoid typing the same parameter multiple times across different launch files - this in order to take out possible configuration inconsistencies out of the loop when doing integration tests. What about loading parameters from a .yaml file? roslaunch supports that via rosparam elements. There should be no need to "type the same parameters multiple times". ( 2020-11-30 07:37:59 -0500 )edit 1 Answer Sort by » oldest newest most voted You can use the namespace attribute ns to the rosparam call in your general_launch.launch file. I.e. something along the lines of: <launch> <rosparam command="load" file="$(arg param_file_name)" ns="my_node"/>
<include file="\$(find my_pkg)/my_node.launch"/>
</launch>


About the conceptual setup: I'd say that parameters in a private namespace should only belong to that node. I.e.

/my_node/param_x --> used by my_node, is fine
/my_node/param_y --> NOT used by my_node, I wouldn't do that...


If you want to group them, because they belong to one functionality or component, or something, I'd suggest to put the node in another namespace (using e.g. the group tag). I.e.

/my_functionality/my_node/param_x --> used by my_node, is fine
/my_functionality/param_y --> NOT used by my_node, but belongs to the functionality, like a general parameter used by multiple nodes

more

Thank you for the suggestion. I edited the post to expand on the conceptual setup (I thought it is worth to give some more info about that).

( 2020-11-30 06:15:39 -0500 )edit

Stats

Seen: 542 times

Last updated: Nov 30 '20