Introspection and interaction

[Christian Dornhege]

I would like to be able to interact with a currently running roslaunch.
Some examples of what might be usefull:

• Acquire information about nodes being started from what launch file
  
• Restart/kill/start a node
• change the respawn flag, arguments or basically anything passed on startup
• change output to screen

I don't know about roslaunch's internal implementation, but I think most of these should be easy to implement as services (maybe changing output to screen during runtime is not possible).

Use cases for this come up when running a large roslaunch and something unexpected happens. If that node is somewhere in a roslaunch, the only chance to interact with that is by whatever the node provides currently. Especially if respawn is true, it is not even possible to manually kill the node and start a new one indenpendently. Although that would obvisouly be possible by killing the complete roslaunch, restarting that might take a lot of time and the situation that caused the problem might not exist any more.

It also would enable nice GUI interfaces. node_manager_fkie seems to have some features, but I am not aware how/if they interact with roslaunch.

[Lorenz Mösenlechner]

+1

I think having a nice ROS api would be really helpful. However, I'm
not sure how to implement that properly. I guess it's not completely
trivial because there needs to be some kind of manager node that
provides the service interface for all running roslaunch instances. I
guess each roslaunch process needed to register each node it is
starting up at the manager and provide a callback mechanism to
interact with it. While this is definitely doable and maybe even not
too hard, I guess it would mean quite a lot of changes to the current
roslaunch implementation.

Lorenz

> --
>
>



--
Lorenz Mösenlechner | moes...@in.tum.de
Technische Universität München | Karlstraße 45
80335 München | Germany
http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910

[Christian Dornhege]

I was thinking that each roslaunch could provide services in a private namespace.

In that case one would need to know which roslaunch you are dealing with (maybe

by the id). That should be doable without much trouble (maybe the fact that a 

roslaunch needs to become a node).

For a centralized version like you suggested (which would be more 

convenient to work with), maybe it would be possible to build that independently

on top of each individual roslaunch. A manager node could determine all running

(and upcoming) roslaunch interaction services, connect to that and collect a node

list. I'm thinking something like an aggregator node that would thus not interefere

with roslaunch's core that much and would be easy to build a GUI on top.