0
$\begingroup$

Rosanswers logo

I have roscore running in docker. I have a bunch of topics, some are started by nodes inside the docker container, some are outside of the container, on host. I need some of these topics to subscribe to eachother. I can subscribe from host to topics that are inside docker and I can echo what's being published to them. But in the container I can't echo topics that are published on host.

For example, what I can do:
Inside docker: rostopic pub /dummy std_msgs/String "data: 'dummy text'" -r 10
On host: rostopic echo /dummy and I see dummy text being printed

What I can't do:
On host: rostopic pub /dummy std_msgs/String "data: 'dummy text'" -r 10
Inside docker: rostopic echo /dummy dummy text should be printed, but nothing is coming out

What I have tried:

  • --net=host, -e ROS_IP=172.17.0.1 and -e ROS_MASTER_URI=http://172.17.0.1:11311 in in docker run which made the first part work (publish topic in docker and echo from host)
  • modifiy /etc/hosts in docker container and on host
  • all sorts of combinations for ROS_IP, ROS_MASTER_URI and ROS_HOSTNAME
  • running roscore on host and setting ROS_IP, ROS_MASTER_URI and ROS_HOSTNAME accordingly

rostopic list works fine on host and in docker no matter where roscore runs. I can ping host from docker and vice versa. I also tested with netcat, both ways works fine, yet topics don't want to send data from host to docker.

In docker I have ros indigo (I can't decide what ros version is used) and on host I have melodic (I can install indigo if anyone thinks that might a problem).

UPDATE:
By using --net=host, ROS_IP=127.0.0.1 and ROS_MASTER_URI=http://localhost:11311 and running the subscriber from docker before the publisher from host I got it working. But this means subscriber must always run before publisher for my scripts to work.


Originally posted by GeorgeMD on ROS Answers with karma: 33 on 2018-07-25

Post score: 3


Original comments

Comment by Michael Johnson on 2018-07-26:
What are the values for ROS_MASTER_URI and ROS_IP or ROS_HOSTNAME on the host machine? Normally this kind of issue is caused by a problem with the ROS_IP variable at one side or other.

Comment by GeorgeMD on 2018-07-27:
See the UPDATE, ROS_MASTER_URI=http://localhost:11311 and ROS_IP=127.0.0.1 on host. And in docker, where I start roscore ROS_MASTER_URI is the same. I also start docker with --net=host.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Using --net=host is indeed perhaps the simplest way of enabling ROS nodes across containers and host to easily communicate. Note that you will lose some degree of isolation for your containers given they would then share all the same network interfaces as the host. However, this allows the containers to communicate over the host's local loopback interface, avoiding the need to override any the default ROS URI IP environment variables on either the host or container.

https://docs.docker.com/network/host/

Here is an older but related question that addresses the same issue. Note however this question predates Docker v17.06 when the the host network driver was introduced, and thus approaches the issue differently. Had the host network driver existed, I would have just as well settled using that instead:

https://answers.ros.org/question/228292/exposing-ros-containers-to-host-machine/
https://gist.github.com/ruffsl/4a24c26a1aa2cc733c64

Side note: you should probably use the same distribution of ROS across all your nodes for compatibility, given that message types or minor APIs may have changed, resulting in more frustrating or subtle issues during run time.


Originally posted by ruffsl with karma: 1094 on 2018-07-25

This answer was ACCEPTED on the original site

Post score: 5


Original comments

Comment by GeorgeMD on 2018-07-27:
I marked this as the answer as it's true that only --net=host is what solved it after all. I left ROS_MASTER_URI and ROS_IP to the defaults. The only extra thing is I have to run subscriber first (inside docker) and publisher after (on host).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.