i've also run into these same problems in the past, and in the end my
solution was to write a small python script that generates the launch
XML file and launches it internally. You can see a very short example
in the LaunchNodes function at

https://code.ros.org/svn/wg-ros-pkg/trunk/stacks/openrave_planning/openrave_database/kinematicreachability_ros.py

basically the python code looks something like:

launchscript = roslaunch_caller.ScriptRoslaunch(launch_xml_text)
launchscript.start()

and by adding #!/usr/bin/env python in the beginning, it can be
executed like a normal program.

rosen,

2010/4/17 Blaise Gassend <blaise@willowgarage.com>:
> Actually, I just rechecked, and you had answered me.
> https://code.ros.org/trac/ros/ticket/1669
>
> The ability to get parameters using a command is indispensable when you
> are trying to automagically determine the correct device to open. I have
> seen a case where it would have been nice to do a <rosparam> with a
> command because there were potentially a whole bunch of parameters
> involved (turns out there were only two, but that was just luck).
>
> The case I saw where a more general $(command ) tag would have been
> useful was when I was trying to get pr2.launch so that it could be
> optionally be pushed into a namespace. The idea was to do:
>
> ROS_NAMESPACE=prl roslaunch pr2.launch
>
> Some remappings (diagnostics, diagnostic aggregation, TF) needed to get
> done to make this work well, and I could really have used a $(command )
> tag to allow slashes to be added or removed as appropriate. (In the end
> limitations in diagnostic aggregation also prevented me from making it
> happen.)
>
> The <command> or <exec> tag would be really useful when you want to run
> something that isn't ROS aware and don't want it confused by its __name
> and __log arguments.
>
> As for the problem of sequencing commands, would it really be so bad to
> say that relying on command order execution will lead to undefined
> behavior, and adding an option to roslaunch to run things in a random
> order with random startup delays so that it is easy to regression test?
>
> (I'm talking about whether it is a good feature here, not about whether
> you have had the chance to implement.)
>
> Cheers,
> Blaise
>
> On Fri, 2010-04-16 at 09:05 -0700, Ken Conley wrote:
>> On Fri, Apr 16, 2010 at 8:50 AM, Blaise Gassend
>> <blaise@willowgarage.com> wrote:
>>         I have asked Ken why there is no $(command ) macro in
>>         roslaunch but
>>         never got an answer... I have seen cases beyond parameters
>>         where it
>>         would have been handy... but perhaps hacky.
>>
>>
>> Must have slipped my mind because I don't recall a ticket. My only
>> issues with command hacks is that it is much easier to put something
>> in there that is non-portable, and validation is much, much trickier.
>> It has its uses, though.
>>
>> I've always wanted to a top-level <exec> or <command> tag to
>> complement the <node> tag as many things that are called <node>s in
>> roslaunch are not actually ROS nodes (and can have different assumed
>> behaviors). We attempted to design this prior to ROS 1.0, but it
>> quickly spiraled out of control with respect to scope. Unlike nodes,
>> commands are sequence-able because they normally terminate, unlike
>> nodes which do not. Once you attempt to add sequencing to roslaunch
>> for a particular tag, things the design space gets arbitrarily large
>> (especially when considering remote launches).
>>
>> I was hoping to have more time to overhaul the roslaunch syntax this
>> iteration, but it looks like that won't happen until D-Turtle.
>>
>>  - Ken
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>