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

edit

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 ... -->

    <!-- Load other configurations -->
    <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.