Make the rosgraph_manipulator script generic/configurable with a yaml file

[ipa-nhg]

Related to: rosin-project/metacontrol_sim#42 (comment)

The current implementation of this tool can only be used for the concrete use case of the metacontrol_sim experiment. I can imagine more applications for a script that kill and restart again a node with new parameters. But also in case that the metacontrol solution has to be applied to new robot systems, currently the script has to be partially re-written. It makes sense to put some effort here to allow its easy reconfiguration.

The node starts an action server which gets as goal the name of the new configuration to be started. Then the rosgraph_manipulator stops one node (move_base for the current example), start the new triggered configuration (currently this is done by a command roslaunch config_name config_name.launch) and finally, if the killed node was running an action and the action was still active when it was killed, it has to re-send the goal action (this step should be optional and now there is a fix goal taken by a yaml file).

Analyzing this behavior and new potential uses I propose the following yaml file as configuration input:

configurations:
  - *ConfigName*:
    command:
kill_nodes: []
save_actions: []

for example:

configurations:
  - f1_v1_r1:
    command: roslaunch  f1_v1_r1 f1_v1_r1.launch
  - f1_v1_r2:
    command: roslaunch f1_v1_r2 f1_v1_r2.launch
.....

kill_nodes: ['/move_base']
save_actions: ['move_base']

Alternatively the command could be "rosrun wathever_node node" or "rosparam set /myAwesomeParameter 500"

The workflow of the node will be:

1. (If the list of save_actions is not empty ) Subscribe to the save_actions goal topics and store the last goal command
2. Once the rosgraph_manipulator action is triggered (/rosgraph_manipulator_action_server/goal)
   2.1 Check if the actions under save_actions are still active
   2.2 Kill all the nodes of the kill_nodes list
   2.3. Call the corresponding command for the selected configuration (roslaunch ...)
   2.4 If 2.1 send again the actions goals

I doubt if it is possible to subscribe to a topic without giving the type of the message (step 1) and the same to send an action goal. In theory we could use rospy.AnyMsg there but I have to check this. Otherwise I propose to move the save_actions feature to a separate node as special case.

[ipa-nhg]

ping @marioney @chcorbato

[marioney]

I think this can be very useful, so thanks for taking the initiative.

Analyzing this behavior and new potential uses I propose the following yaml file as configuration input:

configurations:
  - *ConfigName*:
    command:
kill_nodes: []
save_actions: []

I like the idea of using a .yaml to configure it. But this implies that every configuration requires the same nodes and actions to be killed / saved. I guess this will true for most cases, but maybe it should also be possible to add specific nodes/actions inside a configuration.

Alternatively the command could be "rosrun wathever_node node" or "rosparam set /myAwesomeParameter 500"

Not sure what you mean with this, shouldn't the nodes and parameters be inside the launch file? Actually, I'd prefer it if we restrict the command to a roslaunch, something like:

configurations:
   - *ConfigName*:
       package:
       launch_file:
       args:

The workflow of the node will be:

1. (If the list of save_actions is not empty ) Subscribe to the save_actions goal topics and store the last goal command

2. Once the rosgraph_manipulator action is triggered (/rosgraph_manipulator_action_server/goal)
   2.1 Check if the actions under save_actions are still active
   2.2 Kill all the nodes of the kill_nodes list
   2.3. Call the corresponding command for the selected configuration (roslaunch ...)
   2.4 If 2.1 send again the actions goals

This seems fine by me.

Otherwise I propose to move the save_actions feature to a separate node as special case.

That part I don't like, I'd prefer if we have a single workflow, as for the type of the action / topic, either we can use rospy.AnyMsg and get the type there, or maybe it's easier to just define it in the yaml file

[ipa-nhg]

Not sure what you mean with this, shouldn't the nodes and parameters be inside the launch file? Actually, I'd prefer it if we restrict the command to a roslaunch

For our current application, yes. We will always call a roslaunch command. But I can imagine other scenarios where other commands are more recommended. Kill a node isn't , from my point of view, a good practice, for those nodes where the parameters allow dynamical reconfiguration, it makes to me much sense to just set a new value to the parameter. For these cases the yaml file will look like:

configurations:
  - f1_v1_r1:
    command: rosparam set /controller_frequency 15
  - f1_v1_r2:
    command: rosparam set /controller_frequency 20
.....

kill_nodes: []
save_actions: []

And also the code will be the same, even simpler, because we just call subprocess to execute the command given by the configuration file.
Lastly I wanted to open the scope of potential uses of this node (even without the metacontrol), I can imagine self-recovery approaches using this software.

That part I don't like, I'd prefer if we have a single workflow, as for the type of the action / topic, either we can use rospy.AnyMsg and get the type there, or maybe it's easier to just define it in the yaml file

yes, the use of rospy.AnyMsg will be the first option. We can add the type to the yaml file but I am sure if his will work because we need first to import the message type.

[marioney]

#4 implements a solution, @ipa-nhg Should we close this?

[ipa-nhg]

@marioney yes! we can close this issue! 🎉