Revision history [back]

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Two approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Two approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Two Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Edit2: and obviously, if your target binary does not expect any arguments at all, then all of the above is unnecessary, as the args that roslaunch adds will not be processed anyway.

#!/usr/bin/env python
import sys
import subprocess
from rospy import myargv

if __name__ == "__main__":
    argv = myargv(argv=sys.argv)
    # argv[0] is path to this script
    sys.exit(subprocess.call(argv[1:]))

<node name=".." type=".." pkg=".." args="nc localhost 12345" />

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Edit2: and obviously, if your target binary does not expect any arguments at all, then all of the above is unnecessary, as the args that roslaunch adds will not be processed anyway.

Edit3: (very) minimal Python2 example:

#!/usr/bin/env python
import sys
import sys, subprocess
from rospy import myargv

if __name__ == "__main__":
    argv = myargv(argv=sys.argv)
    # argv[0] is path to this script
    sys.exit(subprocess.call(argv[1:]))

when used with a launch file that contains something like:

<node name=".." type=".." pkg=".." args="nc localhost 12345" />

will make nc try to connect to localhost:12345 with roslaunch waiting for it to exit (as it would with 'regular' ROS binaries).

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Edit2: and obviously, if your target binary does not expect any arguments at all, then all of the above is unnecessary, as the args that roslaunch adds will not be processed anyway.

Edit3: (very) minimal Python2 example:

#!/usr/bin/env python
import sys, subprocess
from subprocess, rospy import myargv

argv = myargv(argv=sys.argv)
sys.exit(subprocess.call(argv[1:]))

sys.exit(subprocess.call(rospy.myargv(argv=sys.argv)[1:]))

when used with a launch file that contains something like:

<node name=".." type=".." pkg=".." args="nc localhost 12345" />

will make nc try to connect to localhost:12345 with roslaunch waiting for it to exit (as it would with 'regular' ROS binaries).

Yes, that is possible, but you will have to take care of some details.

roslaunch (and rosrun is the same) will add a nr of extra arguments to the command line it generates when starting ROS nodes, and those will also be passed to 'non ros applications'. Examples of those extra command line arguments (CLAs) are the node name (as __name:=..) and the location of the log file the node is expected to use (as __log:=..).

Ordinary programs typically do not use such arguments and their CLA parsers will get confused.

Three approaches I've seen:

1. write a bash script that wraps the 'non-ros binary': this script takes in all CLAs, strips out the ROS-specific ones and then invokes the target binary with the remaining arguments. Advantage: simple to create. Disadvantage: it is not really convenient to manipulate strings (ie: command lines) with bash, and these scripts often assume a fixed order of CLAs, which is not guaranteed, leading to brittle implementations.

2. write a small Python wrapper that can use rospy.myargv(..) to remove ROS-specific CLAs and then use subprocess to start the target binary (while passing on the remaining CLAs).

3. same as the previous, but in C++ and using ros::removeROSArgs(..).

I'm not aware of publicly available implementations of any of the above options, but they could already exist. Writing them yourself should not be too hard though.

Note: to use either the rospy or roscpp CLA parsing functions the wrappers do not have to be ROS nodes themselves.

Edit: as roslaunch can only start binaries that are located in packages, the wrappers would have to live in a ROS package themselves. But that is hardly a constraint.

Edit2: and obviously, if your target binary does not expect any arguments at all, then all of the above is unnecessary, as the args that roslaunch adds will not be processed anyway.anyway (but you would still need some way to start your target binary 'from' a ROS package).

Edit3: (very) minimal Python2 example:

#!/usr/bin/env python
import sys, subprocess, rospy 
sys.exit(subprocess.call(rospy.myargv(argv=sys.argv)[1:]))

when used with a launch file that contains something like:

<node name=".." type=".." pkg=".." args="nc localhost 12345" />

will make nc try to connect to localhost:12345 with roslaunch waiting for it to exit (as it would with 'regular' ROS binaries).