How to configure ROS_MASTER_URI & ROS_HOSTNAME

edit

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 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 ... (more)