Revision history [back]

The best way to use ROS_IP and ROS_HOSTNAME is not to use them. These two variables are provided mostly as workarounds for cases where the network cannot handle the standard DHCP+DNS setup that works on many (even SOHO) routers. I.e. in the ideal case, the router should keep a local DNS database that is filled with hostnames and the IP addresses they got from DHCP.

If your network supports this ideal case, just set ROS_MASTER_URI=http://my-laptop:11311 on the robot and that's it.

...sometimes. If e.g. Ubuntu would not complicate things. If you have an Ubuntu computer in the network, it cannot contact LAN hosts by hostnames in the default configuration. We set up all of our Ubuntu machines with sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf which makes hostname resolution via DNS possible (the command enables a different mode of /etc/resolv.conf). This has been tested on 18.04 and most pobably also 20.04. Please, do some research before running this command on newer versions as the network stack may have different composition.

In case your network does not run this clever DNS+DHCP combination, or if it is buggy, the next option of choice is mDNS (avahi). I'm not sure if ESP32 supports it or not, though. On a default-configured Ubuntu, you can try contacting other hosts by addresses in the form ofhostname.local. The only requirement for this to work is that all machines run mDNS clients and that the network does not block mDNS discovery. If you want to go this way, that's where ROS_HOSTNAME comes into play. When it is empty, whenever a computer advertises a topic, it tells others the topic can be found on e.g. http://hostname:33333. If another computer tries to subscribe the topic, it tries to resolve hostname to an IP address and fails. Let ROS_HOSTNAME save the day! On the publishing computer, set ROS_HOSTNAME=hostname.local and voila, all published topics will now be advertised as http://hostname.local:33333 which other clients should be able to resolve. Theoretically, setting this on the publisher should be enough, but if you want e.g. services or actions to work, both communicating computers should have this setting, each with its own mDNS hostname.

ROS_IP is the "poor man's" last resort. I usualy treat it as "this is used by people who do not want to do any network configuration at all, except basic DHCP or static addresses". Yes, there are cases in which ROS_IP is the only option, but generally, it is the least preferred solution (as you've already pointed out, in a dynamic network, this is actually pretty hard to manage). If I'd consider using ROS_IP somewhere, it would be in a network with statically configured addresses. To complete the story, if you set ROS_IP=1.2.3.4, the all topics you advertise will be presented as http://1.2.3.4:33333. This does not require any additional servies or configuration on the side of subscribers, except for a working network connection.

One last note - never specify both ROS_IP and ROS_HOSTNAME. If you specify both, ROS_HOSTNAME wins and ROS_IP has no effect.

The best way to use ROS_IP and ROS_HOSTNAME is not to use them. These two variables are provided mostly as workarounds for cases where the network cannot handle the standard DHCP+DNS setup that works on many (even SOHO) routers. I.e. in the ideal case, the router should keep a local DNS database that is filled with hostnames and the IP addresses they got from DHCP.

If your network supports this ideal case, just set ROS_MASTER_URI=http://my-laptop:11311 on the robot and that's it. Please, also note that if the robot HW allows it, it is always a better idea to run the ROS master (aka roscore) on the robot than on your laptop. If ROS_MASTER_URI is not set, it defaults to http://0.0.0.0:11311 (it is sometimes also written as http://localhost:11311, however the default-created ROS master binds to all network interfaces and not just the loopback as localhost might suggest). So on the "master" computer, just run roscore and you don't have to care about setting ROS_MASTER_URI. The computer will be its own master.

...sometimes. If e.g. Ubuntu would not complicate things. If you have an Ubuntu computer in the network, it cannot contact LAN hosts by hostnames in the default configuration. We set up all of our Ubuntu machines with sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf which makes hostname resolution via DNS possible (the command enables a different mode of /etc/resolv.conf). This has been tested on 18.04 and most pobably also 20.04. Please, do some research before running this command on newer versions as the network stack may have different composition.

In case your network does not run this clever DNS+DHCP combination, or if it is buggy, the next option of choice is mDNS (avahi). I'm not sure if ESP32 supports it or not, though. On a default-configured Ubuntu, you can try contacting other hosts by addresses in the form ofhostname.local. The only requirement for this to work is that all machines run mDNS clients and that the network does not block mDNS discovery. If you want to go this way, that's where ROS_HOSTNAME comes into play. When it is empty, whenever a computer advertises a topic, it tells others the topic can be found on e.g. http://hostname:33333. If another computer tries to subscribe the topic, it tries to resolve hostname to an IP address and fails. Let ROS_HOSTNAME save the day! On the publishing computer, set ROS_HOSTNAME=hostname.local and voila, all published topics will now be advertised as http://hostname.local:33333 which other clients should be able to resolve. Theoretically, setting this on the publisher should be enough, but if you want e.g. services or actions to work, both communicating computers should have this setting, each with its own mDNS hostname.

ROS_IP is the "poor man's" last resort. I usualy treat it as "this is used by people who do not want to do any network configuration at all, except basic DHCP or static addresses". Yes, there are cases in which ROS_IP is the only option, but generally, it is the least preferred solution (as you've already pointed out, in a dynamic network, this is actually pretty hard to manage). If I'd consider using ROS_IP somewhere, it would be in a network with statically configured addresses. To complete the story, if you set ROS_IP=1.2.3.4, the all topics you advertise will be presented as http://1.2.3.4:33333. This does not require any additional servies or configuration on the side of subscribers, except for a working network connection.

One last note - never specify both ROS_IP and ROS_HOSTNAME. If you specify both, ROS_HOSTNAME wins and ROS_IP has no effect.

The best way to use ROS_IP and ROS_HOSTNAME is not to use them. These two variables are provided mostly as workarounds for cases where the network cannot handle the standard DHCP+DNS setup that works on many (even SOHO) routers. I.e. in the ideal case, the router should keep a local DNS database that is filled with hostnames and the IP addresses they got from DHCP.

If your network supports this ideal case, just set ROS_MASTER_URI=http://my-laptop:11311 on the robot ROS_MASTER_URI=http://the-master-computer:11311 on the non-master computer and that's it. Please, also note that if the robot HW allows it, it is always a better idea to run the ROS master (aka roscore) on the robot than on your laptop. If ROS_MASTER_URI is not set, it defaults to http://0.0.0.0:11311 (it is sometimes also written as http://localhost:11311, however the default-created ROS master binds to all network interfaces and not just the loopback as localhost might suggest). So on the "master" computer, just run roscore and you don't have to care about setting ROS_MASTER_URI. The computer will be its own master.

...sometimes. If e.g. Ubuntu would not complicate things. If you have an Ubuntu computer in the network, it cannot contact LAN hosts by hostnames in the default configuration. We set up all of our Ubuntu machines with sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf which makes hostname resolution via DNS possible (the command enables a different mode of /etc/resolv.conf). This has been tested on 18.04 and most pobably also 20.04. Please, do some research before running this command on newer versions as the network stack may have different composition.

In case your network does not run this clever DNS+DHCP combination, or if it is buggy, the next option of choice is mDNS (avahi). I'm not sure if ESP32 supports it or not, though. On a default-configured Ubuntu, you can try contacting other hosts by addresses in the form ofhostname.local. The only requirement for this to work is that all machines run mDNS clients and that the network does not block mDNS discovery. If you want to go this way, that's where ROS_HOSTNAME comes into play. When it is empty, whenever a computer advertises a topic, it tells others the topic can be found on e.g. http://hostname:33333. If another computer tries to subscribe the topic, it tries to resolve hostname to an IP address and fails. Let ROS_HOSTNAME save the day! On the publishing computer, set ROS_HOSTNAME=hostname.local and voila, all published topics will now be advertised as http://hostname.local:33333 which other clients should be able to resolve. Theoretically, setting this on the publisher should be enough, but if you want e.g. services or actions to work, both communicating computers should have this setting, each with its own mDNS hostname.

ROS_IP is the "poor man's" last resort. I usualy treat it as "this is used by people who do not want to do any network configuration at all, except basic DHCP or static addresses". Yes, there are cases in which ROS_IP is the only option, but generally, it is the least preferred solution (as you've already pointed out, in a dynamic network, this is actually pretty hard to manage). If I'd consider using ROS_IP somewhere, it would be in a network with statically configured addresses. To complete the story, if you set ROS_IP=1.2.3.4, the all topics you advertise will be presented as http://1.2.3.4:33333. This does not require any additional servies or configuration on the side of subscribers, except for a working network connection.

One last note - never specify both ROS_IP and ROS_HOSTNAME. If you specify both, ROS_HOSTNAME wins and ROS_IP has no effect.

The best way to use ROS_IP and ROS_HOSTNAME is not to use them. These two variables are provided mostly as workarounds for cases where the network cannot handle the standard DHCP+DNS setup that works on many (even SOHO) routers. I.e. in the ideal case, the router should keep a local DNS database that is filled with hostnames and the IP addresses they got from DHCP.

If your network supports this ideal case, just set ROS_MASTER_URI=http://the-master-computer:11311 on the non-master computer and that's it. Please, also note that if the robot HW allows it, it is always a better idea to run the ROS master (aka roscore) on the robot than on your laptop. If ROS_MASTER_URI is not set, it defaults to http://0.0.0.0:11311 (it is sometimes also written as http://localhost:11311, however the default-created ROS master binds to all network interfaces and not just the loopback as localhost might suggest). So on the "master" computer, just run roscore and you don't have to care about setting ROS_MASTER_URI. The computer will be its own master.

...sometimes. If e.g. Ubuntu would not complicate Sometimes the network works correctly, but the operating system complicates things. E.g. Ubuntu. If you have an Ubuntu computer in the network, it cannot contact LAN hosts by hostnames in the default configuration. We set up all of our Ubuntu machines with sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf which makes hostname resolution via DNS possible (the command enables a different mode of /etc/resolv.conf). This has been tested on 18.04 and most pobably also 20.04. Please, do some research before running this command on newer versions as the network stack may have different composition.

In case your network does not run this clever DNS+DHCP combination, or if it is buggy, the next option of choice is mDNS (avahi). I'm not sure if ESP32 supports it or not, though. On a default-configured Ubuntu, you can try contacting other hosts by addresses in the form ofhostname.local. The only requirement for this to work is that all machines run mDNS clients and that the network does not block mDNS discovery. If you want to go this way, that's where ROS_HOSTNAME comes into play. When it is empty, whenever a computer advertises a topic, it tells others the topic can be found on e.g. http://hostname:33333. If another computer tries to subscribe the topic, it tries to resolve hostname to an IP address and fails. Let ROS_HOSTNAME save the day! On the publishing computer, set ROS_HOSTNAME=hostname.local and voila, all published topics will now be advertised as http://hostname.local:33333 which other clients should be able to resolve. Theoretically, setting this on the publisher should be enough, but if you want e.g. services or actions to work, both communicating computers should have this setting, each with its own mDNS hostname.

ROS_IP is the "poor man's" last resort. I usualy treat it as "this is used by people who do not want to do any network configuration at all, except basic DHCP or static addresses". Yes, there are cases in which ROS_IP is the only option, but generally, it is the least preferred solution (as you've already pointed out, in a dynamic network, this is actually pretty hard to manage). If I'd consider using ROS_IP somewhere, it would be in a network with statically configured addresses. To complete the story, if you set ROS_IP=1.2.3.4, the all topics you advertise will be presented as http://1.2.3.4:33333. This does not require any additional servies or configuration on the side of subscribers, except for a working network connection.

One last note - never specify both ROS_IP and ROS_HOSTNAME. If you specify both, ROS_HOSTNAME wins and ROS_IP has no effect.