Revision history [back]

Verified the issues was really a silly resolving issue while posting replying to a github issue asking the resolvable devs the same thing. Just now seeing @gvdhoorn comment reaffirms my thoughts.

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 amore 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 the 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.

Using a DNS entry for the Docker bridge interface however is so much simpler, I'll probably keep to that method.

Verified the issues was really a silly resolving issue while posting replying to a github issue asking the resolvable devs the same thing. Just now seeing @gvdhoorn comment reaffirms my thoughts.

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 by setting ROS_IP; this of course comes at the cost of losing amore 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 the 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 (setting each services IP) would be a ~~better implementation,~~ slight improvement, yet still rigid and possibly conflicting with other networks.

Using a DNS entry for the Docker bridge interface however is so much simpler, I'll probably keep to that method.

Verified the issues was really a silly resolving issue while posting replying to a github issue asking the resolvable devs the same thing. Just now seeing @gvdhoorn comment reaffirms my thoughts.

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 by setting ROS_IP; this of course comes at the cost of losing ~~amore~~ 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 the 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 (setting each services IP) would be a slight improvement, yet still rigid and possibly conflicting with other networks.

Using a DNS entry for the Docker bridge interface however is so much simpler, I'll probably keep to that method.