Ask Your Question
2

ROS2: rviz in docker container

asked 2018-08-20 15:11:53 -0500

alsora gravatar image

updated 2018-08-20 20:08:51 -0500

jayess gravatar image

Hi,

I'm trying to use Rviz2 from within a Docker container.

I'm working on top of this Docker image

FROM osrf/ros2:bouncy-desktop

This is my run script

#!/bin/bash

XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth

touch $XAUTH

xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

docker run -it --rm \
 -e XAUTHORITY=${XAUTH} \
 -e DISPLAY=$DISPLAY \
 -e QT_GRAPHICSSYSTEM=native \
 -v $XSOCK:$XSOCK:rw \
 -v $XAUTH:$XAUTH:rw \
 ros2_docker \
 bash

Everything works fine, but then I needed to make the Docker container communicate with other machines on the host network. I accomplished that by adding the following option to docker run --net=host \

This solves the connectivity issue, but has the side effect of making rviz not working anymore. If I try to run rviz, I only get the following error.

 ros2 run rviz2 rviz2

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
dbus[1041]: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
  D-Bus not built with -rdynamic so unable to print a backtrace

Any idea about how to fix this? Thanks

edit retag flag offensive close merge delete

Comments

That's peculiar. I'm using nvidia docker, yet I can reproduce your rviz(1 or 2) XDG_RUNTIME_DIR error when adding --net=host for both melodic and bouncy images.

ruffsl gravatar imageruffsl ( 2018-08-20 16:10:05 -0500 )edit

XDG_RUNTIME_DIR doesn't seem to be necessary the issue, given it otherwise would normally default to something like '/tmp/runtime-root'. The privilege issue with managing the dbus connection seem to be the setback here.

ruffsl gravatar imageruffsl ( 2018-08-20 16:31:06 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2018-08-20 16:22:20 -0500

ruffsl gravatar image

updated 2018-08-20 16:27:56 -0500

I'm not yet totally sure yet as to why, but it appears that using the host network driver then necessitates adding the privileged flag if one also wishes to use the host's X11 unix socket simultaneously. I.e. just add --privileged upon using --net=host with the docker run command when expecting to forward containerised GUIs to the host's X11 display.

A small example I used to check this:

Dockerfile

FROM osrf/ros2:bouncy-desktop

# nvidia-container-runtime
ENV NVIDIA_VISIBLE_DEVICES \
    ${NVIDIA_VISIBLE_DEVICES:-all}
ENV NVIDIA_DRIVER_CAPABILITIES \
    ${NVIDIA_DRIVER_CAPABILITIES:+$NVIDIA_DRIVER_CAPABILITIES,}graphics

run.bash

#!/bin/bash

XSOCK=/tmp/.X11-unix

docker run -it --rm \
 --runtime=nvidia \
 -e DISPLAY=$DISPLAY \
 -v $XSOCK:$XSOCK \
 -v $HOME/.Xauthority:/root/.Xauthority \
 --privileged \
 --net=host \
 osrf/ros2:bouncy-desktop-nvidia "$@"

terminal

docker build -t osrf/ros2:bouncy-desktop-nvidia .
bash run.bash ros2 run rviz2 rviz2

Note that if you're not using nvidia, you can use intel's embedded graphics just as well instead:
http://wiki.ros.org/docker/Tutorials/...

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-08-20 15:11:53 -0500

Seen: 864 times

Last updated: Aug 20 '18