[Question] ROS networking

[ruffsl]

Hello resolvable devs,

I've got a question for you: what is it about using resolvable that is perhaps "resolving" a docker networking issue that we've been having the the ROS community. I've made a gist describing the possible fix, and a question on ros.answers, but I'd like to invite you to inform us of what subtle nuance I may be missing.

Thanks!

[Lennie]

[deleted, the question I asked was wrong]

[ruffsl]

@Lennie , its a good question. In version 2 of the Compose file format, by default, Compose sets up a single network for your app using the project directory name as a prefix. This implicit default behavior is relatively new I believe. More detail here or in the resource links in the gist.

[Lennie]

Yeah, I had already edited my comment and removed the question on github. :-)

I didn't know it was the implicit default behaviour.

Anyway's I had a few drinks so maybe I don't understand completely, but could it be that the protocol sends a hostname along with the requests ? So (some of) the processes you are talking to ignore the input if you use an IP-address when talking from the host ?

Does it work if you add the IP-addresses/hostnames to /etc/hosts on the host ?

[ruffsl]

Ahh yes, I do believe that this was it.

• What I had considered was the domain resolution within the project network, making sure the containers could resolve the [master,talker,listener] host names between themselves by setting the ROS_HOSTNAME environmental variable.
• What I didn't consider was that this was that same domain name used used in generating the publisher's URI not only need to be resolvable by the ros master node, but as well as any subscriber (i.e. the host). Looking back at the wiki page, this was made clear. I just forgot this relationship pertains to more that just the just (master, publisher), (master, subscriber), but also (subscriber, publisher) after I switched from using domain names to IP address.

• There must be complete, bi-directional connectivity between all pairs of machines, on all ports.
• Each machine must advertise itself by a name that all other machines can resolve..

If instead, I where to use a more rigid setup, I can avoid the need of providing a DNS server for bridge network at the cost of losing a more flexible domain name assignment.

version: '2'

services:
  master:
    build: .
    environment:
      - "ROS_IP=172.19.0.3"
    command: roscore

  talker:
    build: .
    environment:
      - "ROS_IP=172.19.0.4"
      - "ROS_MASTER_URI=http://master:11311"
    command: rosrun roscpp_tutorials talker

  listener:
    build: .
    environment:
      - "ROS_IP=172.19.0.2"
      - "ROS_MASTER_URI=http://master:11311"
    command: rosrun roscpp_tutorials listener

<on host>
export ROS_IP=172.19.0.1
export ROS_MASTER_URI=http://172.19.0.3:11311
$ rostopic list
/chatter
/rosout
/rosout_agg
$ rostopic echo /chatter 
data: hello world 84
---
data: hello world 85
---
data: hello world 86
...

Note that the compose file above is quite fragile, as I'm assuming the containers will be assigned the same IP as before on my docker engine, such that ROS_IP remains correctly corresponding. Specify a custom IPAM config for the project's default network would be a better implementation, yet still rigid and possibly conflicting with other networks.