ROS connectivity and usernames

asked 2012-01-11 20:29:21 -0600

Ibrahim
307 ●14 ●22 ●29

I think I've just discovered a really dumb mistake on my part and I want confirmation as to whether this matters. On two machines (one of which is the ROS_MASTER, c1), my username is ibrahim, but on some other machines that are connected to the ROS_MASTER through openvpn on the PR2 basestation, my username is ibrahima. On the machines with username ibrahima I can read topics fine, but I can't access services. Does ROS assume that you can ssh with the same username into other machines? I have set up an ssh config file (~/.ssh/config) such that I can ssh without having to type the proper username but I still can't get services to work. For example, if i run rosservice call static_map where static_map is running on the basestation, it says it's Unable to communicate with service /static_map. I've set ROS_IP on the other machines to be the VPN IP address and not the WAN IP, which fixed things like running rosnode info on a node running on a VPN-connected machine but this doesn't seem to help with services.

Is it just the username being an issue, or are there more steps needed to set up VPN connected computers besides setting up the connection and setting the proper ROS_MASTER_URI, ROS_IP, and any necessary entries in /etc/hosts

edit retag flag offensive close merge delete

add a comment

1

answered 2012-03-05 11:27:20 -0600

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

ROS communications do not require username or authentification. Read the technical overview

The only thing which requires SSH username and keys is roslaunch. All other communications simply require port numbers.

There appears to be an issue with something like routing or name lookup and services. If you can describe how to reproduce it we can take a closer look.

edit flag offensive delete link

Comments

1

Agreed; this is probably a problem with name resolution on your network. Running 'rosservice info <service>' should show you which hostname clients are using when creating service clients. You should make sure that this name resolves properly on all machines.

ahendrix ( 2012-03-05 16:03:49 -0600 )edit

It was probably a routing issue, I actually am not sure at the moment if the issue still exists because I'm not in the lab at the moment but I think somehow I figured it out or it magically fixed itself.