Home | Tutorials | Wiki | Issues
Ask Your Question
0

DRCSIM: Can't figure out how to run Gazebo on remote machine and get vision input.

asked 2013-03-31 17:32:15 -0500

cga gravatar image

updated 2013-03-31 21:54:44 -0500

I want to set up Gazebo to run remotely on one machine, and do control from another machine (the DRCSIM setup). This seems to run into a problem which must have been solved in cloudsim: how does the rendering for the simulated cameras get done? Whose GPU is used (the remote gazebo machine or the local ROS machine)? Note I am not trying to run a gzclient at all. I want ROS to work over the network (which it seems to do just fine). I can't get gzserver to simulate cameras when launched remotely.

If I log in on the console of machine 1 and type

source /usr/local/share/drcsim/setup.sh
roslaunch atlas_utils qual_task_1.launch

on machine 1 and run something that just displays images from the topic /multisense_sl/camera/left/image_raw on machine 2, everything works fine. I see the robot on machine 1's display and the simulated camera view of gates on machine 2.

If I log in on the console of machine 1 and run a gzserver instead:

source /usr/local/share/drcsim/setup.sh
roslaunch atlas_utils qual_task_1.launch gzname:=gzserver

on machine 1 and run something that just displays images from the topic /multisense_sl/camera/left/image_raw on machine 2, everything works fine. I see no client or image on machine 1 and the simulated camera view of gates on machine 2.

If I try to use machine 1 remotely I fail. First without trying to own the display:

ssh machine1
source /usr/local/share/drcsim/setup.sh
roslaunch atlas_utils qual_task_1.launch gzname:=gzserver

I get the error message:

Error [RenderEngine.cc:608] Can't open display: 
Warning [RenderEngine.cc:87] Unable to create X window. Rendering will be disabled
Error [MultiCameraSensor.cc:81] Unable to create MultiCameraSensor. Rendering is disabled.

I can rostopic echo /clock on machine 2, but I can't view the images.

Using -X (which should be irrelevant because I want to own machine 1's display. I am not displaying anything from machine 1 directly on machine 2).

ssh machine1 -X
source /usr/local/share/drcsim/setup.sh
roslaunch atlas_utils qual_task_1.launch gzname:=gzserver

I get the same error message, and I can rostopic echo /clock on machine 2, but I can't view the images.

Okay. Now I leave myself logged on to the console of machine 1, which I don't want to do since I want others to be able to use Gazebo remotely on this machine. Logging in with ssh with and without -X work as long as I say on machine1:

export DISPLAY=machine1:0.0

This does not work if someone else is logged in on the console of machine 1 and owns the display, or if no one is logged in to the console of machine 1 (including me). I get the error message:

Error [RenderEngine.cc:608] Can't open display: machine1:0.0
Warning [RenderEngine.cc:87] Unable to create X window. Rendering will be disabled
Error [MultiCameraSensor ...
(more)
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
2

answered 2013-04-04 12:58:49 -0500

gerkey gravatar image

You can see how CloudSim does it in startup_scripts.py. Search for "nvidia" and then start reading. Basically, we:

  • install nvidia drivers
  • configure X to use nvidia drivers
  • configure lightdm to auto-login a particular user, which is the user we'll be running Gazebo as via ssh later

Then, even on reboot, your chosen user will be logged in, owning the X display. The last step is, when ssh'ing in, set your DISPLAY explicitly:

export DISPLAY=:0
edit flag offensive delete link more
0

answered 2013-04-01 09:14:07 -0500

SL Remy gravatar image

I haven't used cloudsim, but in a similar cloud environment I use xvfb and set the DISPLAY env variable accordingly.

I haven't had much success with xvfb-run, so I start xvfb, place it in the background and then make use of it.

edit flag offensive delete link more

Comments

This was a good idea, but it didn't work. Xvfb :1 launched fine, and export DISPLAY=:1.0 or just :1 allowed xterms to be created on the fake display, but gzclient was not fooled. It kept giving the error messages: Error [RenderEngine.cc:623] Unable to create glx visual Warning [RenderEngine.cc:87] Unable to create X window. Rendering will be disabled Error [MultiCameraSensor.cc:81] Unable to create MultiCameraSensor. Rendering is disabled. Note this error message is slightly different from abov

cga gravatar imagecga ( 2013-04-02 22:22:34 -0500 )edit

Xvfb :1 -pixdepths 16 32 also failed with the same error message about unable to create glx visual. The attribute list is: {GLX_RGBA, GLX_DOUBLEBUFFER, GLX_DEPTH_SIZE, 16,GLX_STENCIL_SIZE, 8, None } so if anyone has suggestions as to how to satisfy this attribute list let me know.

cga gravatar imagecga ( 2013-04-02 22:36:08 -0500 )edit

Hmm.. I've been using this approach for the past 8 months.. (haven't yet upgraded to gazebo 1.4 though) Xvfb :1 -screen 0 1024x768x24

SL Remy gravatar imageSL Remy ( 2013-04-05 10:54:15 -0500 )edit

Perhaps things have improved, but I haven't had much luck in the past using a virtual frame buffer with applications like Gazebo that do a lot of OpenGL calls.

gerkey gravatar imagegerkey ( 2013-04-05 12:07:37 -0500 )edit

I've been running both gazebo and stage on cloud hosted VM's, first with OpenNebula and then with Openstack. I have seen that Gazebo (at least upto 1.3) randomly crashes after running for a couple of hours. I've heard that this may also be happening in cloudsim.. but haven't been able to get confirmation.

SL Remy gravatar imageSL Remy ( 2013-04-07 12:53:52 -0500 )edit

I've run Stage for months with no random crashes. The version of Stage that I use includes the camera sensor, so openGL calls are being used.

SL Remy gravatar imageSL Remy ( 2013-04-07 12:55:53 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2013-03-31 17:32:15 -0500

Seen: 6,724 times

Last updated: Apr 04 '13