Access Gazebo installed on a mac host

[cthorey]

Hi,
First, thanks for the great work of maintaining these images.
I tried to reproduce the example in the deployment example.
Everything is working properly except when I tried to connect the gzclient (on my mac machine) to the container.

I just got

[Msg] Waiting for master.

I guess this is due to the fact that Per-container IP addressing is not possible on docker-for-mac. I tried to Port forwarding instead mapping 11345:11345 and then setting up GAZEBO_MASTER_URI=0.0.0.0:11345.

This appears to launch gazebo on my mac but then gazebo got stuck on the preparing your world screen.

Can you think of any workaround ?
Thanks

PS : I am running mac osx sierra with gazebo version 8.1.0 install on my mac. The container is also running gazebo version 8.1.0.

[scpeters]

For debugging the networking setup, it might be easier to use the gz command, like gz stats or gz topic -l. What is the IP address of the docker container that you are using?

[cthorey]

Thx for the quick answer,
it's 172.17.0.2.
The output of $(docker inspect --format '{{ .NetworkSettings.IPAddress }}' gazebo).

[cthorey]

If this is of any help, when forwarding the port and connecting from GAZEBO_MASTER_URI=0.0.0.0:11345, gazebo froze on preparing your world.

The output of gz stats is

libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >: boost: mutex lock failed in pthread_mutex_lock: Invalid argument
Abort trap: 6

and gz topic -l

gz topic -l
/gazebo/default/atmosphere
/gazebo/default/diagnostics
/gazebo/default/factory
/gazebo/default/factory/light
/gazebo/default/gui
/gazebo/default/joint
/gazebo/default/light
/gazebo/default/light/modify
/gazebo/default/log/control
/gazebo/default/log/status
/gazebo/default/model/info
/gazebo/default/model/modify
/gazebo/default/physics
/gazebo/default/physics/contacts
/gazebo/default/playback_control
/gazebo/default/pose/info
/gazebo/default/pose/local/info
/gazebo/default/pose/modify
/gazebo/default/request
/gazebo/default/response
/gazebo/default/undo_redo
/gazebo/default/user_cmd
/gazebo/default/user_cmd_stats
/gazebo/default/visual
/gazebo/default/wind
/gazebo/default/world_control
/gazebo/default/world_stats
/gazebo/server/control
/gazebo/world/modify

[ruffsl]

Perhaps the trouble stems from the way Docker for Mac uses a VM to host a linux kernel for the docker engine, and the oddities in passing through network traffic through the host->VM->container network interfaces. I have no Mac to test this, but there seem to be a lot of discussion on this topic:
https://forums.docker.com/t/access-host-not-vm-from-inside-container/11747

If you happen to need just one one containerized gzserver, have you tried using the --net=host run arg? This will bind the container to all interfaces available to the VM (I assume the network bridge interface it uses), circumventing any docker networking. Perhaps this would help to isolate the issue in VM network setup vs the docker network behind it.

[cthorey]

Yes, I indeed think this is where the problem comes from. Thx for the tip but, unfortunately, even using --net=host results in gzclient hanging on waiting for master.

[ruffsl]

Is the VM's network configured; i.e. are you able to use netcat to test socket connections from mac host to guest VM?
Also for intra docker engine networking, can a gz command in one container connect to a gzserver container, with both containers on the same docker engine/ virtual docker network?

[piotrmilos]

@cthorey Did you manage to solve the problem. I think I have exactly the same one :)

[cthorey]

@piotrmilos Unfortunately no, I switched back to a linux machine where everything works as expected.

[ruffsl]

Looks like this is a mac issue, not specific to these docker images. Closing for now, but feel free to comment if more debug info surfaces.

[pickledgator]

It appears that gazebo is using random TCP ports for its transport layer, and since Mac docker requires you to forward each of the ports individually to map them to the host, this complicates things. We're able to get the gzclient to communicate with the gzserver (running inside the docker), however, it hangs at loading the world. We can reproduce the error by running "gz stats" on the mac host -- which also hangs when trying to connect to the gzserver within the docker (however, gz list -l works fine). This is a minimal application which simply opens a transport subscriber to ~/world/stats. Is there any way to force gzserver to only use certain ports (or a range of ports) in it's random port mapping?

[j-rivero]

I assume that you are using gazebo8, aren't you? Probably @caguero could help us with your question.

[pickledgator]

I am actually using gazebo7, but we have also tried gazebo8 and saw the same problem.

[scpeters]

does mac docker support host networking?

[pickledgator]

The only thing we've been able to deduce is that Mac docker doesn't have a network bridge (docker0) like linux docker does. We've been able to get mac host applications to communicate with mac docker applications (by communicating with the mac host ip or localhost). And mac docker applications to communicate with host applications (by communicating with the mac host ip). However, gzclient and gzserver are having trouble being satisfied in some way or another -- which causes gzclient (or gz stats) to hang on connection. It's important to note that gzserver automatically selects the internal only docker ip network which is not mapped to the mac host network. Perhaps this is the problem. We tried to force GAZEBO_IP so that it uses the mac host ip correctly as "Publicized address" but this did not solve things either. Without any more debug info from either gz process, it's difficult to tell what's attempting, failing and hanging.

docker launch:

docker run --rm -it -p 11345:11345 --name sim sim

output:

[318533e5ea38:~/px4/Tools/sitl_gazebo/scripts] >>> ./gzserver_run.sh
USING:
  GAZEBO_PLUGIN_PATH /home/px4/Tools/sitl_gazebo/build:
  GAZEBO_MODEL_PATH /home/px4/Tools/sitl_gazebo/models:
===============================
Press [CTRL+C] to exit
===============================
Gazebo multi-robot simulator, version 7.8.1
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.17.0.2
[Err] [RenderEngine.cc:730] Can't open display:
[Wrn] [RenderEngine.cc:97] Unable to create X window. Rendering will be disabled
[Wrn] [RenderEngine.cc:301] Cannot initialize render engine since render path type is NONE. Ignore this warning ifrendering has been turned off on purpose.
[Wrn] [msgs.cc:1807] Conversion of sensor type[sonar] not suppported.
[Wrn] [msgs.cc:1807] Conversion of sensor type[sonar] not suppported.
[Wrn] [msgs.cc:1807] Conversion of sensor type[sonar] not suppported.
[Wrn] [msgs.cc:1807] Conversion of sensor type[sonar] not suppported.
[Wrn] [msgs.cc:1807] Conversion of sensor type[sonar] not suppported.
[Dbg] [gazebo_mavlink_interface.cpp:166] <joint_name> not found for channel[0] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:166] <joint_name> not found for channel[1] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:166] <joint_name> not found for channel[2] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:166] <joint_name> not found for channel[3] no joint control will be performed for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:155] joint [zephyr_delta_wing::propeller_joint] not found for channel[4] no joint control for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:155] joint [zephyr_delta_wing::flap_left_joint] not found for channel[5] no joint control for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:155] joint [zephyr_delta_wing::flap_right_joint] not found for channel[6] no joint control for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:166] <joint_name> not found for channel[7] no joint control will be performed for this channel.

gzclient launch:

➜  scripts: ./sim_client.sh
Gazebo multi-robot simulator, version 7.8.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 192.168.88.172
-- hangs here

[himty]

Old thread, but I got Gazebo in Docker to work by running both gzserver and gzclient in the Docker then using x11vnc and xvfb to get the display back to my computer, following dershow's hint for his workaround from here #167 (comment)

docker pull gazebo:latest
docker run -p 5900:5900 -d -v="/tmp/.gazebo/:/root/.gazebo/" --name=gazebo gazebo

docker exec -it gazebo bash  # get into the Docker

apt-get update
apt-get install x11vnc -y
apt update
apt install xvfb ufw -y
Xvfb :1 -screen 0 1600x1200x16 &
export DISPLAY=:1.0
gzclient &
x11vnc -display  

Then I opened a VNC viewer like "VNC Viewer for Google Chrome"
Address = localhost:5900

voila

[stevenlee090]

@himty thanks for the instructions! I was able to get mine working by following the same steps.

[mkusold]

Old thread, but I got Gazebo in Docker to work by running both gzserver and gzclient in the Docker then using x11vnc and xvfb to get the display back to my computer, following dershow's hint for his workaround from here #167 (comment)

docker pull gazebo:latest
docker run -p 5900:5900 -d -v="/tmp/.gazebo/:/root/.gazebo/" --name=gazebo gazebo

docker exec -it gazebo bash  # get into the Docker

apt-get update
apt-get install x11vnc -y
apt update
apt install xvfb ufw -y
Xvfb :1 -screen 0 1600x1200x16 &
export DISPLAY=:1.0
gzclient &
x11vnc -display  

Then I opened a VNC viewer like "VNC Viewer for Google Chrome"
Address = localhost:5900

voila

I'm having troubles following along. When I run the last line, I get:

root@d664dff42868:/# x11vnc -display 
not enough arguments for: -display

Do you know what I'm missing with the display argument?

==============================================
Update: I figured it out. the -display flag requires :1.0 after it. However, since you already exported the DISPLAY parameter anyway, you really don't need the flag at all. So it should be just x11vnc