[ros-users] Question about roslaunch and remote processes.

[Christian Dornhege]

Hi,

On 25.07.2011 19:50, Joan Pau Beltran wrote:
> Hi everyone,
>
> I have to questions about roslaunch and remote processes that seem to
> point some bugs out.
> We are using Diamondback as current release.
>

> 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).


The reason for this is that the .bashrc is not executed by the remote 
login. You should be able to fix this by using the <env> tag in the 
launch file.



> 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.

Cheers,
   Christian Dornhege
-- 
Albert-Ludwigs-University
Institute of Computer Science
Research Group Foundations of Artificial Intelligence
Georges-Köhler-Allee 52
79110 Freiburg
Phone: 0761 203 8074