0
$\begingroup$

Rosanswers logo

FUERTE

I have a few machines correctly connected in ROS (core is able to ssh to them and launch nodes).

I'm writing a node which for now resides in my ROS workspace (/home/myuser/ROS_WORKSPACE). I'm able to manually launch the node and it works. However roslaunch can't find it, it shows its search paths are

[LabRob-Panda-01-0]: ERROR: cannot launch node of type [Saetta_Base/base]: Saetta_Base
ROS path [0]=/opt/ros/fuerte/share/ros
ROS path [1]=/opt/ros/fuerte/share
ROS path [2]=/opt/ros/fuerte/stacks

It's obviously missing my workspace path. The user which I use for the ssh connection is the same I use to check things and do stuff on the robots so its .bashrc is ok. I tried copying the node itself in the stacks folder, but I guess some of the code (which I'm slowly porting from the old hardware and application) tries to write on a file and segfaults badly.

So I tried forcing loading the user's own bashrc this way

<machine name="Panda01" address="LabRob-Panda-01" user="panda" default="false" env-loader="/home/panda/.bashrc" timeout="60" />

But this only gets this

launching remote roslaunch child with command: [env ROS_MASTER_URI=http://Sciame-Server:11311/ /home/panda/.bashrc roslaunch -c LabRob-Panda-01-0 -u http://Sciame-Server:36969/ --run_id 4b77a00a-75ed-11e2-b3b8-001d608763ac]
remote[LabRob-Panda-01-0]: ssh connection created
remote[LabRob-Panda-01-0]: env: /home/panda/.bashrc: Permission denied

So I created my own

/home/panda/rosenv.sh

but roslaunch can't find it.

Meanwhile using

env-loader="/opt/ros/fuerte/env.sh"

works correctly.

The solution happears to be the following: create an executable shell script in the user home folder on the remote machine. Something like rosenv.sh

sh /opt/ros/<distrib>/env.sh
export ROS_PACKAGE_PATH+=:/path1:/path2

Make it executable (chmod +x) and have your roslaunch refer to this new file in it's env loader

<machine name="MachineName" address="Address" user="user"  env-loader="/home/user/rosenv.sh" />

But roslaunch can't proceed if I use this script: meaning it freezes waiting for something on that remote machine. Reverting to /opt/ros/fuerte/env.sh allows roslaunch to proceed. So how can I get roslaunch to look in my workspace?


Originally posted by Claudio on ROS Answers with karma: 859 on 2013-02-08

Post score: 2


Original comments

Comment by dornhege on 2013-02-08:
Does it work after manually sourcing .bashrc after logging in?

Comment by Claudio on 2013-02-08:
I don't even have to source it, I just need to login with the same user I'm giving roslaunch, and it works.

This user has, in his home configuration, all the paths to the ros_workspace including the paths to the single projects. Somehow roslaunch doesn't inherit that.

Comment by joq on 2013-02-09:
Is it installed and built on the remote machine?

Comment by Claudio on 2013-02-10:
Joq the node is built on the remote machine, it's not "installed" as it is a devel version and moreover the remote machine is ARM so no real install packages are available.

Anyway the ros packages and stacks I downloaded and installed do work correctly (for example the hokuyo laser node).

Comment by dornhege on 2013-02-11:
Is it maybe just missing the node from the package path?

According to http://ros.org/wiki/roslaunch/Architecture .bashrc, etc. are ignored.

Comment by Claudio on 2013-02-12:
So it is intentional not to allow workspace nodes to be launched by roslaunch? I'll wait for an insight before flagging yours as the correct answer.

Comment by dornhege on 2013-02-12:
I'd say it is not intentional to prevent workspace nodes. It is either an artifact from the way it is run via ssh, additionally requiring you to specify those things or intentionally disabled to make users aware of what setup is run on the remote machine. (You can still run workspace nodes).

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I had a similar problem a while ago (IIRC, I was using Diamondback or Electric). The issue wound up being that the first line in the remote computer's .bashrc caused it to exit immediately if it wasn't an interactive shell, thus ignoring all the later export commands. Might something similar be going on for you?


Originally posted by lindzey with karma: 1780 on 2013-02-09

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by Claudio on 2013-02-10:
Thanks for the idea, do you know how can I test this?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.