# Question about roslaunch and remote processes

Hi everyone,

This is a repost of two questions formulated to ros-users@code.ros.org , to make the answers easier to find for other users. The original thread is

https://code.ros.org/lurker/message/20110725.175028.97fe0f40.en.html

Firstly, the output=screen attribute seems to be ignored, since I don't get any output with lines like:

<launch>
<node machine="fugu-c" pkg="memsense_imu" type="imu_node"
name="imu_node" output="screen">
<rosparam file="\$(find fugu_configurations)/imu/params.yaml" />
<param name="frame_id" value="imu" />
</node>
</launch>


I am sure (because I wrote it myself) that the node is using the rosconsole macros for output. According to the wiki, one of the reasons to use the macros instead of the standard c++ streams is the possibility to get output from remotely launched processes. Does anyone know what may be happening?

The machine file looks like this:

<launch>
ros-root="/opt/ros/diamondback/ros/"
ros-package-path="/home/user/ros:/opt/ros/diamondback/stacks" />
</launch>


And the second one, it seems that the roslaunch mechanism does not honour the ROS_HOSTNAME variable for remote machines. In the .bashrc file of the remote machine this variable is set to 'fugu-c.local', to allow the remote machine name to be resolved properly using Avahi (that seems to become quite standard in the latest distributions, this is the reason for the .local suffix). However when launching the above file, connection is stablished with the remote machine, even the core is found if running there, but any node is launched. This is the output:

started roslaunch server http://10.42.43.1:51495/
remote[fugu-c.local-0] starting roslaunch
remote[fugu-c.local-0]: creating ssh connection to fugu-c.local:22, user[user]
remote[fugu-c.local-0]: ssh connection created

SUMMARY
========

PARAMETERS
...
MACHINES
* fugu-c

NODES
/
imu_node (memsense_imu/imu_node)
ROS_MASTER_URI=http://fugu-c.local:11311
core service [/rosout] found
error launching on [fugu-c.local-0, uri http://fugu-c:39451/]: Name or service not known
Launch of the following nodes most likely failed: memsense_imu/imu_node


Apparently, the uri is computed as the result of the hostname command on the remote machine, which returns only 'fugu-c' instead of 'fugu-c.local'. I expected that setting the ROS_HOSTNAME would overwrite this behaviour (actually it works for finding the remote core). If this is a bug or a possible improvement, where should I submmit it? If not, any idea on how to handle this? By now, we added the corresponding entry to /etc/hosts to overcome the problem, but I would expect a better solution.

edit retag close merge delete

Sort by » oldest newest most voted

Output from remote processes is not redirected to local console. An option is to use rxconsole to get it. A further discussion is what can you do when you don't have a graphical (X11) session.

And to the second question, the problem is that the .bashrc of the remote machine is not sourced when launching remote processes, so the remote nodes to be launched are not awared of the ROS_HOSTNAME variable.

In the above example, ssh to the remote machine works due to the address atributte in the machine file, and the master is found beacuse it is launched manually in the remote machine and the ROS_MASTER_URI variable is set to http://fugu-c.local:11311 in the local machine (manually or by .bashrc). But then the remote node uri is http://fugu-c:39451, which can not be resolved.

An option is to set an environment variable ROS_HOSTNAME in the machine file. With this new configuration, remote launching works pretty well:

<launch>
ros-root="/opt/ros/diamondback/ros/"
ros-package-path="/home/user/ros:/opt/ros/diamondback/stacks" >
<env name="ROS_HOSTNAME" value="fugu-c.local" />
</machine>
</launch>


If the roscore is run on the local machine, the ROS_MASTER_URI may be set in the machine file, too.

Thanks to Tully and Christian for their answers in the original thread. All the merit is theirs.

more

1

Are there any solutions for Fuerte or later ? This solution is valid for Electric and previous versions of the ros due to the manual <env name=""/> is not valid anymore.

( 2016-03-10 09:37:21 -0500 )edit

@osencan the manual suggests, you use the env-loader attribute instead. You can then put the initialisation of these environment variables into the script you specify in there. (drawback: you cannot set these parameters from local environment vars... haven't found a workaround for that yet)

( 2017-01-29 16:19:29 -0500 )edit