No tf recieved inside docker

asked 2019-09-08 16:57:58 -0500

udeto gravatar image

updated 2019-09-08 16:59:36 -0500


I am trying to run Apollo 3.0 with the carla simulator with a ros bridge.

Currently I am stuck on the following issue:

In order to run the perception module apollo needs to recieve certain tf's. These tf are published by static transform publishers. However the apollo perception module throws the following error:

E0908 23:30:11.273775  6725] Cannot transform frame:  novatel to frame velodyne64 , err: . canTransform returned after 10 timeout was 10.. Frames: Frame velodyne16 exists with parent novatel.
Frame radar exists with parent short_camera.
Frame short_camera exists with parent velodyne64.
Frame radar_front exists with parent velodyne64.
Frame velodyne64 exists with parent novatel.
Frame long_camera exists with parent short_camera.
Frame localization exists with parent world.

I have had a closer look into this issue and saw that while the static transform publisher nodes and the tf topics are visible (with rosnode info ... and rostopic info ...) inside the docker environment, no tf data is received. I tried to run tf view_frames, tf_echo and tf_monitor inside and outside the docker. Outside the docker all the tf data was received correctly while inside the docker no tf data were received.

I am starting the docker environment like so:

${DOCKER_CMD} run -it \
        -d \
        --privileged \
        --name apollo_dev \
        ${MAP_VOLUME_CONF} \
        --volumes-from ${LOCALIZATION_VOLUME} \
        --volumes-from ${YOLO3D_VOLUME} \
        -e ROS_MASTER_URI= \
        -e ROS_IP= \
        -e DISPLAY=$display \
        -e DOCKER_USER=$USER \
        -e USER=$USER \
        -e DOCKER_USER_ID=$USER_ID \
        -e DOCKER_GRP="$GRP" \
        -e DOCKER_GRP_ID=$GRP_ID \
            -e DOCKER_IMG=$IMG \
    $(local_volumes) \
    --net host \
        -w /apollo \
        --add-host in_dev_docker: \
        --add-host ${LOCAL_HOST}: \
        --hostname in_dev_docker \
        --shm-size 2G \
    --pid=host \
    -v /dev/null:/dev/raw1394 \
        $IMG \

At this point I really have no idea why i cant receive any tf data inside the docker, while being able to see publishing nodes and the topics. Does anybody have an idea what the source of this issue is?

If you need any additional information, just let me know.

Thanks in advance!

edit retag flag offensive close merge delete


Can you ping the host from inside the docker container by name? If not, that could be the problem (ie: nodes running on host report unresolvable hostname to nodes-in-container -> no traffic).

gvdhoorn gravatar imagegvdhoorn ( 2019-09-09 02:09:58 -0500 )edit

What exactly do by "ping the host by name"? Do you mean the roscore?

udeto gravatar imageudeto ( 2019-09-09 05:09:10 -0500 )edit

"the host" == the machine running docker.

You set ROS_MASTER_URI=, which will work for the nodes inside the container, as the master will probably bind on all IPs or Docker routing will take care of reaching the hosts IP from within the container.

But nodes running outside the container will receive connection requests from nodes inside the container, and they may be returning a hostname that nodes inside the container cannot resolve.

By trying to ping the "host machine" (ie: the one running docker), you could get an indication for whether DNS is working (sufficiently) for nodes inside your container to be able to resolve the hostname that nodes outside the container may be returning.

ROS nodes connect directly, not through the master. So nodes must be able to resolve each others hostnames or only use IP addresses.

You're using --net host, so it ...(more)

gvdhoorn gravatar imagegvdhoorn ( 2019-09-09 05:13:53 -0500 )edit

Ok I understand, thank you! I checked and I am able to ping the machine running the docker environment by its hostname from inside the docker. So I figure the nodes should be able to resolve each others hostnames, right?

udeto gravatar imageudeto ( 2019-09-09 05:31:26 -0500 )edit

There is a good chance it should work, yes, but I've seen stranger things.

You could test whether setting ROS_IPoutside your Docker container makes any difference. Set it to the IP of the PC running docker.

Docker containers can essentially be considered "other hosts" when it comes to networking. So all the problems with DNS, routes and discoverability and communication that come up with multiple hosts can also affect Docker containers.

Running --privileged and with --net=host makes things somewhat easier, but there's still enough that may not work.

gvdhoorn gravatar imagegvdhoorn ( 2019-09-09 05:34:48 -0500 )edit

I tried setting the ROS_IP to the IP adress to the adress I got, when I ran hostname -I outside of the docker. But then I wasn't able to contact any nodes inside the docker container (i.e. nodes were not visible when running rqt_graph outside the docker container). Therefore I changed the ROS_MASTER_URI as well, and tried to run a roscore outside of the docker, but that didnt work either, as no ros related commands inside the docker lead to any output.

So I now changed both back to the IP address of the docker environment. I additionally checked weather I am able to ping the docker environment from outside the docker using its hostname. Turns out that while I am able to ping the host running the docker from inside the docker, I am not able to ping the docker environment from outside the docker. Is that ...(more)

udeto gravatar imageudeto ( 2019-09-09 11:07:48 -0500 )edit

I tried setting the ROS_IP to the IP adress to the adress I got,

just to make sure: you're not setting the -e ROS_IP of your container to the IP of the host. Are you?

That would not be what I meant. If you did, then set ROS_IP in the environment of the host (so not the container) to the IP of the host. Leave the ROS_IP of the Docker container as you already show it.

gvdhoorn gravatar imagegvdhoorn ( 2019-09-09 11:42:30 -0500 )edit

Well, yes I did do that :D

Now I tried to set ROS_IP of the environment to the host IP address with the command:

export ROS_IP=

Is that what you meant?

udeto gravatar imageudeto ( 2019-09-09 12:19:37 -0500 )edit