ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Exporting ROS master to a server at another location

asked 2020-11-03 05:32:00 -0500

MartinJensen37 gravatar image

Hello! I want to know if it is possible to export ROS master to a server that is sitting in another building. Both the server and my local computer are sitting over the same network at my University and it is possible to ping each over the network. I'm trying to export the ROS master to the server so it can do processing on the information posted to the topics and sending commands back to the local computer. If it is possible to export the ROS master, how would I go about this?

I've tried setting it up as follows:

Server (172.27.15.xx):

export ROS_HOSTNAME=172.27.15.xx
export ROS_IP = 172.27.15.xx

Local PC (

export ROS_IP =

I simply get 'host is not set to this machine' and the ip of the rosmaster is set to localhost.

Thanks in Advance!

edit retag flag offensive close merge delete


Same goes for you: do not set ROS_IP and ROS_HOSTNAME both. If you don't have working DNS, use ROS_IP.

gvdhoorn gravatar image gvdhoorn  ( 2020-11-03 10:48:28 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-11-03 09:35:36 -0500

I run into this issue often enough to where I created a gist for it:

Note that one pitfall is that the ROS_HOSTNAME used by either machine needs to be resolvable by the other machine. This is because ROS uses that hostname to register with the master, and when a direct connection between the two machines is being established (e.g., for rostopic echo), that hostname is given to the machines to start talking with each other. This is where I have seen people fail most often. If rostopic list works, but rostopic echo doesn't, then this latter problem is what you are dealing with most likely.

edit flag offensive delete link more


Please update your gist to not use both ROS_IP and ROS_HOSTNAME. Choose one.

If you have working DNS, use ROS_HOSTNAME. If not: use ROS_IP.

gvdhoorn gravatar image gvdhoorn  ( 2020-11-03 10:47:54 -0500 )edit

Thanks for the suggestion. Can you elaborate on why it is bad to set both?

chfritz gravatar image chfritz  ( 2020-11-03 10:50:24 -0500 )edit

It's not bad, but it's not a good idea imo.

ROS_HOSTNAME will take precedence over ROS_IP, so if you set both, ROS_IP will be ignored (code). So it's redundant in the best case, and can lead to strange errors in the worst (users with ROS_HOTSNAME and then ROS_IP with an IP which also has a typo, or an "old" IP (from a previous lease)). For this reason alone I recommend to set one, not both.

And personally I feel ROS_HOSTNAME should really only be used for hostnames (as that's what the name implies). I typically use ROS_IP on multi-homed systems where ROS_HOSTNAME can resolve to an IP which is not reachable on all interfaces. You could set ROS_HOSTNAME to an IP in that case as well, but then we get back to variable name.

gvdhoorn gravatar image gvdhoorn  ( 2020-11-03 11:08:25 -0500 )edit

This is where I have seen people fail most often. If rostopic list works, but rostopic echo doesn't, then this latter problem is what you are dealing with most likely.

I just had this exact thing happen, weirdly. I have an onboard computer and a remote computer. The onboard has nodes launched by robot upstart that the remote could list but not echo. Notably, I could pub from the onboard command line and echo on the remote just fine. Both computers were both setting the ROS_IP and ROS_MASTER_URI correctly. What eventually fixed the problem was noticing that the onboard computer's name was mistyped in the remote computer's /etc/hosts file (so it had the correct IP and the corresponding name was not the actual computer name). Correcting it to use the right computer name in the /etc/hosts did the trick and fixed the entire problem.

Is ...(more)

APettinger gravatar image APettinger  ( 2020-11-03 11:27:57 -0500 )edit

Question Tools


Asked: 2020-11-03 05:32:00 -0500

Seen: 1,394 times

Last updated: Nov 03 '20