meta-control / mc_rosgraph_manipulator Goto Github PK

Due to the configuration of the https://github.com/tud-cor organization, I cannot change the visibility or other core settings of this repo.

We are migrating the metacontrol software to long-term repositories (not linked to a particular project).

• I would like to have more control over those repos.
• Also, I do not find it handy that Github does not allow to group repos as GitLab does, so as to group all metacontrol related repos.

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.