Hi, <br><br>Good questions. In the future these are great questions for <a href="http://answers.ros.org">answers.ros.org</a>. If you wouldn't mind reasking them there I'd be happy to copy my answers there too. That forum provides a easier way to search and browse previously asked questions. And helps identify duplicate questions. <br>
<br><br>Meanwhile, answers inline. <br><br><div class="gmail_quote">On Mon, Jul 25, 2011 at 10:50 AM, Joan Pau Beltran <span dir="ltr"><<a href="mailto:joanpau.beltran@uib.cat">joanpau.beltran@uib.cat</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi everyone,<br>
<br>
I have to questions about roslaunch and remote processes that seem to<br>
point some bugs out.<br>
We are using Diamondback as current release.<br>
<br>
Firstly, the output=screen attribute seems to be ignored, since I don't<br>
get any output with lines like:<br>
> <launch><br>
> <node machine="fugu-c" pkg="memsense_imu" type="imu_node"<br>
> name="imu_node" output="screen"><br>
> <rosparam file="$(find fugu_configurations)/imu/params.yaml" /><br>
> <param name="frame_id" value="imu" /><br>
> </node><br>
> </launch><br>
I am sure (because I wrote it myself) that the node is using the<br>
rosconsole macros for output. According to the wiki, one of the reasons<br>
to use the macros instead of the standard c++ streams is the possibility<br>
to get output from remotely launched processes. Does anyone know what<br>
may be happening?<br></blockquote><div><br>Console outputs from remote machines are not displayed. To view the rosconsole macro outputs I recommend using the rxconsole <a href="http://www.ros.org/wiki/rxconsole">http://www.ros.org/wiki/rxconsole</a> It is the best way to take advantage of the powerful logging macros throughout the system. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
The machine file looks like this:<br>
> <launch><br>
> <machine name="fugu-c" address="fugu-c.local" user="user"<br>
> ros-root="/opt/ros/diamondback/ros/"<br>
> ros-package-path="/home/user/ros:/opt/ros/diamondback/stacks" /><br>
> </launch><br>
<br>
<br>
And the second one, it seems that the roslaunch mechanism does not<br>
honour the ROS_HOSTNAME variable for remote machines. In the .bashrc<br>
file of the remote machine this variable is set to 'fugu-c.local', to<br>
allow the remote machine name to be resolved properly using Avahi (that<br>
seems to become quite standard in the latest distributions, this is the<br>
reason for the .local suffix).<br>
However when launching the above file, connection is stablished with the<br>
remote machine, even the core is found if running there, but any node is<br>
launched. This is the output:<br>
> started roslaunch server <a href="http://10.42.43.1:51495/" target="_blank">http://10.42.43.1:51495/</a><br>
> remote[fugu-c.local-0] starting roslaunch<br>
> remote[fugu-c.local-0]: creating ssh connection to fugu-c.local:22,<br>
> user[user]<br>
> remote[fugu-c.local-0]: ssh connection created<br>
><br>
> SUMMARY<br>
> ========<br>
><br>
> PARAMETERS<br>
> ...<br>
> MACHINES<br>
> * fugu-c<br>
><br>
> NODES<br>
> /<br>
> imu_node (memsense_imu/imu_node)<br>
><br>
> ROS_MASTER_URI=<a href="http://fugu-c.local:11311" target="_blank">http://fugu-c.local:11311</a><br>
><br>
> core service [/rosout] found<br>
> error launching on [fugu-c.local-0, uri <a href="http://fugu-c:39451/" target="_blank">http://fugu-c:39451/</a>]: Name or<br>
> service not known<br>
> Launch of the following nodes most likely failed: memsense_imu/imu_node<br>
Apparently, the uri is computed as the result of the hostname command on<br>
the remote machine, which returns only 'fugu-c' instead of<br>
'fugu-c.local'. I expected that setting the ROS_HOSTNAME would overwrite<br>
this behaviour (actually it works for finding the remote core). If this<br>
is a bug or a possible improvement, where should I submmit it? If not,<br>
any idea on how to handle this? By now, we added the corresponding entry<br>
to /etc/hosts to overcome the problem, but I would expect a better solution.<br></blockquote><div><br>For the environment variables see this discussion. <a href="https://code.ros.org/lurker/message/20090301.023742.7fc6cb7b.en.html">https://code.ros.org/lurker/message/20090301.023742.7fc6cb7b.en.html</a><br>
<br>ROS does expect that your machines are setup correctly to talk to each other by hostname, setting it in /etc/hosts is a common local patch. <a href="http://www.ros.org/wiki/ROS/NetworkSetup">http://www.ros.org/wiki/ROS/NetworkSetup</a> <br>
<br>Tully<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
Thank you in advance!<br>
<br>
--<br>
Joan Pau Beltran<br>
Grup de Sistemes, Robňtica i Visió - DMI<br>
Universitat de les Illes Balears<br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com">tfoote@willowgarage.com</a><br>(650) 475-2827<br>