ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

First, you have to understand that there is no magic in roslaunch, this is just a way to start processes automatically.

For instance, the code you provided in the previous post is more or less rewritten into the following shell command:

ENV_EXAMPLE="some value" rosrun rospy_tutorials talker _talker_1_param:=a_value

And that's all!

So there is no "connection" between C and launch files. A launch file "launches" binaries and that's all, it also monitors their status but that's all. In particular, the node will never e able to influence in any way on the launch script.

The second part is the environment variables. Roslaunch allows you to define some variables to configure your scripts, it is particularly interesting when you need to start binaries which are not ROS nodes. Otherwise if you want to change the behavior of a launch file, I recommend that you use <arg ...=""/> instead. For ROS nodes, use or <rosparam/> instead.

Then, finally, the parameters. I found the doc on the parameters a bit obscure so let me explain again:

When you start the master, it maintains a map key -> value of parameters that you can set and get from any node (it is shared among all the nodes). Use rosparam list / rosparam set / rosparam get to see what parameters are available.

The parameters are public by default, but there is also "private parameters". These parameters are also shared but are put in a separate namespace to avoid naming collisions.

Example: you have a foo node which have two parameters: bar which is public and baz which is private.

You will see the following:

$ rosparam list
/bar          # the public parameter
/foo/baz      # the private parameter

Again, ALL parameters are shared among all nodes and are visible through rosparam for instance.

However, one interesting thing with private parameters is that they can be set on the command line when you start the node:

rosrun fooPkg foo _baz:="a value"

Here you set the private parameter baz to "some value".

The equivalent syntax when using a launch file is through the <param .../> tag. <rosparam .../> allows to load private parameters from a YAML file to avoid making your launch files too verbose.

Another thinkg which is confusing in the documentation is that the private parameters are documented as ~baz on the wiki for instance, so you have to know that the ~ is replaced by _ on the command line and disappear in the launch file.

First, you have to understand that there is no magic in roslaunch, this is just a way to start processes automatically.

For instance, the code you provided in the previous post is more or less rewritten into the following shell command:

ENV_EXAMPLE="some value" rosrun rospy_tutorials talker _talker_1_param:=a_value

And that's all!

So there is no "connection" between C and launch files. A launch file "launches" binaries and that's all, it also monitors their status but that's all. In particular, the node will never e able to influence in any way on the launch script.

The second part is the environment variables. Roslaunch allows you to define some variables to configure your scripts, it is particularly interesting when you need to start binaries which are not ROS nodes. Otherwise if you want to change the behavior of a launch file, I recommend that you use <arg ...=""/> instead. For ROS nodes, use or <rosparam/> instead.

Then, finally, the parameters. I found the doc on the parameters a bit obscure so let me explain again:

When you start the master, it maintains a map key -> value of parameters that you can set and get from any node (it is shared among all the nodes). Use rosparam list / rosparam set / rosparam get to see what parameters are available.

The parameters are public by default, but there is also "private parameters". These parameters are also shared but are put in a separate namespace to avoid naming collisions.

Example: you have a foo node which have two parameters: bar which is public and baz which is private.

You will see the following:

$ rosparam list
/bar          # the public parameter
/foo/baz      # the private parameter

Again, ALL parameters are shared among all nodes and are visible through rosparam for instance.

However, one interesting thing with private parameters is that they can be set on the command line when you start the node:

rosrun fooPkg foo _baz:="a value"

Here you set the private parameter baz to "some value".

The equivalent syntax when using a launch file is through the <param .../> tag. <rosparam .../> allows to load private parameters from a YAML file to avoid making your launch files too verbose.

Another thinkg thing which is confusing in the documentation is that the private parameters are documented as ~baz on the wiki for instance, so you have to know that the ~ is replaced by _ on the command line and disappear in the launch file.

First, you have to understand that there is no magic in roslaunch, this is just a way to start processes automatically.

For instance, the code you provided in the previous post is more or less rewritten into the following shell command:

ENV_EXAMPLE="some value" rosrun rospy_tutorials talker _talker_1_param:=a_value

And that's all!

So there is no "connection" between C and launch files. A launch file "launches" binaries and that's all, it also monitors their status but that's all. In particular, the node will never e able to influence in any way on the launch script.

The second part is the environment variables. Roslaunch allows you to define some variables to configure your scripts, it is particularly interesting when you need to start binaries which are not ROS nodes. Otherwise if you want to change the behavior of a launch file, I recommend that you use <arg ...=""/> instead. For ROS nodes, use or <rosparam/> instead.

Then, finally, the parameters. I found the doc on the parameters a bit obscure so let me explain again:

When you start the master, it maintains a map key -> value of parameters that you can set and get from any node (it is shared among all the nodes). Use rosparam list / rosparam set / rosparam get to see what parameters are available.

The parameters are public by default, but there is also "private parameters". These parameters are also shared but are put in a separate namespace to avoid naming collisions.

Example: you have a foo node which have two parameters: bar which is public and baz which is private.

You will see the following:

$ rosparam list
/bar          # the public parameter
/foo/baz      # the private parameter

Again, ALL parameters are shared among all nodes and are visible through rosparam for instance.

However, one interesting thing with private parameters is that they can be set on the command line when you start the node:

rosrun fooPkg foo _baz:="a value"

Here you set the private parameter baz to "some value".

The equivalent syntax when using a launch file is through the <param .../> tag. <rosparam .../> allows to load private parameters from a YAML file to avoid making your launch files too verbose.

Another thing which is confusing in the documentation is that the private parameters are documented as ~baz on the wiki for instance, so you have to know that the ~ is replaced by _ on the command line and disappear in the launch file.

edit: as for the C++ part, you can read the roscpp tutorial here about the parameters to know how to retrieve them and use them in your code. Again, I do not recomment that you rely on environment variables to configure your node.

First, you have to understand that there is no magic in roslaunch, this is just a way to start processes automatically.

For instance, the code you provided in the previous post is more or less rewritten into the following shell command:

ENV_EXAMPLE="some value" rosrun rospy_tutorials talker _talker_1_param:=a_value

And that's all!

So there is no "connection" between C and launch files. A launch file "launches" binaries and that's all, it also monitors their status but that's all. In particular, the node will never e able to influence in any way on the launch script.

The second part is the environment variables. Roslaunch allows you to define some variables to configure your scripts, it is particularly interesting when you need to start binaries which are not ROS nodes. Otherwise if you want to change the behavior of a launch file, I recommend that you use <arg ...=""/> instead. For ROS nodes, use or <rosparam/> instead.

Then, finally, the parameters. I found the doc on the parameters a bit obscure so let me explain again:

When you start the master, it maintains a map key -> value of parameters that you can set and get from any node (it is shared among all the nodes). Use rosparam list / rosparam set / rosparam get to see what parameters are available.

The parameters are public by default, but there is also "private parameters". These parameters are also shared but are put in a separate namespace to avoid naming collisions.

Example: you have a foo node which have two parameters: bar which is public and baz which is private.

You will see the following:

$ rosparam list
/bar          # the public parameter
/foo/baz      # the private parameter

Again, ALL parameters are shared among all nodes and are visible through rosparam for instance.

However, one interesting thing with private parameters is that they can be set on the command line when you start the node:

rosrun fooPkg foo _baz:="a value"

Here you set the private parameter baz to "some value".

The equivalent syntax when using a launch file is through the <param .../> tag. <rosparam .../> allows to load private parameters from a YAML file to avoid making your launch files too verbose.

Another thing which is confusing in the documentation is that the private parameters are documented as ~baz on the wiki for instance, so you have to know that the ~ is replaced by _ on the command line and disappear in the launch file.

edit: as for the C++ part, you can read the roscpp tutorial here about the parameters to know how to retrieve them and use them in your code. Again, I do not recomment recommend that you rely on environment variables to configure your node.