[ros-users] launching all nodes in included launch file on specified machine
kwc at willowgarage.com
Fri Feb 11 19:45:55 UTC 2011
On Thu, Feb 10, 2011 at 7:21 AM, koen buys <buys.koen at gmail.com> wrote:
> On 8 February 2011 08:48, Ken Conley <kwc at willowgarage.com> wrote:
>> On Mon, Feb 7, 2011 at 11:34 PM, koen buys <koen.buys at mech.kuleuven.be> wrote:
>>> On 7 February 2011 18:08, Ken Conley <kwc at willowgarage.com> wrote:
>>>> Hi Dan,
>>>> If you declare a machine tag as a default, it is only active for nodes
>>>> that are evaluated after it. That enables the sort of behavior you
>>>> describe, I think.
>>>> In general, I want to redo the machine configuration (and am open to
>>>> others willing to contribute). It's not nearly as powerful as it
>>>> needs to be.
>>>> - Ken
>>> What changes do you have in mind? (I'm currently using it a lot)
>> The original design didn't really pan out. I didn't really understand
>> how more complex roslaunch systems would be constructed, so I
>> speculated and missed. The goal was to enable decoupling of machines
>> and nodes, but the resulting system was more static than intended.
>> In particular, some ideas to redo this:
>> * decouple node/machine config even more, e.g. read from machine
>> configurations onto the Parameter Server
> I still don't see clearly how this should happen, could you detail more?
Say, for example, I have three different launch files I want to run.
All three need the same machine configuration. In order to do this, I
have to modify each to include the same machines file. Another option
is that I 'load' the machines file and, when I go to launch the other
files, they can read that machine configuration and use it themselves.
Another example: on the PR2, we have a "robot.launch" file that brings
up the base system. This could define the various logical mappings
for machines. Any launch file on top of that would read those
The power of this approach is that machine configuration is available
to any tool, so you could build other tools that can now access the
full robot network, such as load-monitoring, etc...
>> * be able to apply a machine configuration in the include, e.g. Dan's
>> suggestion and also 
> this is also a feature that would prove it's use in our case.
It's sounds like this is the first thing to do. Are you interested in helping?
>> * enable defining machine names w/o requiring machines to be declared
> only based on hostnames could be handy, taking the user and the same
> ROS env variables to all
> machines it's executed on (this is typically the case in our lab)
Can you come up with a more specific feature request and ticket it?
More information about the ros-users