On Thu, Feb 10, 2011 at 7:21 AM, koen buys wrote: > On 8 February 2011 08:48, Ken Conley wrote: >> On Mon, Feb 7, 2011 at 11:34 PM, koen buys wrote: >>> On 7 February 2011 18:08, Ken Conley 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 definitions. 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 [1] > > 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? cheers, Ken