Robotics StackExchange | Archived questions

Gazebo7 hangs with black screen while "Preparing your world"

Hi,

I'm really stuck with the this problem and need help to figure out what's wrong...

I've set up two identical laptops (Dell XPS 13) in an identical way (Ubuntu 16.04 Gnome, ROS Kinetic). I've installed sudo apt install ros-kinetic-care-o-bot on both laptops.
Now I source /opt/ros/kinetic/setup.bash and then run roslaunch cob_bringup_sim robot.launch robot:=cob4-7 robot_env:=empty on both machines, i.e. only using latest release of the related packages.

While gazebo shows up the Care-O-bot with two arms on laptop A, gazebo stays black on the other laptop B (even after waiting a while to allow downloading additional models) and keeps showing the splash screen "Preparing your world..." forever.
Ironically, both laptops successfully show the Care-O-bot base when running roslaunch cob_bringup_sim robot.launch robot:=cob4-3 robot_env:=empty (base-only configuration) from debian packages.

I've already swapped the SSDs between the laptops to verify it's not a hardware (RAM, GPU,...) issue:
The simulation stays black for cob4-7 using SSD B in both laptop A and laptop B - while simulation of cob4-3 works usinging SSD B on both laptop A and laptop B.
I've also already re-installed gazebo, ros various other packages...nothing gained.

One thing I saw is that ~/.gazebo/ogre.log on SSD A shows entries like:

17:36:46: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_torso' of type 'FileSystem' to resource group 'General' with recursive option
17:36:46: Initialising resource group General
17:36:46: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_arm' of type 'FileSystem' to resource group 'General' with recursive option
17:36:46: Initialising resource group General
17:36:47: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/drive_wheel' of type 'FileSystem' to resource group 'General' with recursive option
17:36:47: Initialising resource group General
17:36:50: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_base' of type 'FileSystem' to resource group 'General' with recursive option
17:36:50: Initialising resource group General
17:36:50: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_head' of type 'FileSystem' to resource group 'General' with recursive option
17:36:50: Initialising resource group General
17:36:50: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/sensors' of type 'FileSystem' to resource group 'General' with recursive option
17:36:50: Initialising resource group General
17:36:52: Texture: com.png: Loading 1 faces(PF_R8G8B8,200x100x1) with 5 generated mipmaps from Image. Internal format is PF_X8R8G8B8,200x100x1.
17:36:54: Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 5 generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
7: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_torso' of type 'FileSystem' to resource group 'General' with recursive option
17:36:47: Initialising resource group General
17:36:47: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/cob4_head' of type 'FileSystem' to resource group 'General' with recursive option
17:36:47: Initialising resource group General

while I don't see these lines in ~/.gazebo/ogre.log on SSD B. (see attached)
In particular, I don't see the upper body parts (torso, arms) when running cob4-7 from SSD B.

I only see

18:49:20: Added resource location '/opt/ros/kinetic/share/cob_description/meshes/sensors' of type 'FileSystem' to resource group 'General' with recursive option
18:49:20: Initialising resource group General

in ~/.gazebo/ogre.log of SSD B, where the sensors are in the same package as the torso and arms....but even the sensors only appear AFTER *** Stopping GLX Subsystem *** is seen in the log.
Thus, my current guess it that it gets stuck loading those resources

So far, this is the only difference I noticed, which would explain the black gazebo window.
I don't see any other warning/error/exception that seems related...I also don't have any other troubles with laptop B and SSD B what-so-ever.

Thus, I'm really out of ideas how to fix this. In particular because I've identical setups and use only released debian version of cob_bringup_sim and its dependencies.

Thanks, Felix

C:\fakepath\ssda_ogre.log.yaml
C:\fakepath\ssdb_ogre.log.yaml


Additional Information:

By the way the problem is the same when using roslaunch cob_bringup_sim robot.launch from source

The output of gz topic -l while gazebo shows black screen is:

fxm@alpamayo:~$ gz topic -l
/gazebo/default/default/sensorring_cam3d_frame_sensor/cmd
/gazebo/default/diagnostics
/gazebo/default/factory
/gazebo/default/factory/light
/gazebo/default/ground_plane/link/wrench
/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/roads
/gazebo/default/robot/arm_left_1_link/wrench
/gazebo/default/robot/arm_left_2_link/wrench
/gazebo/default/robot/arm_left_3_link/wrench
/gazebo/default/robot/b_caster_r_wheel_link/wrench
/gazebo/default/robot/b_caster_rotation_link/wrench
/gazebo/default/robot/base_footprint/base_contact_sensor/contacts
/gazebo/default/robot/base_footprint/base_laser_front/scan
/gazebo/default/robot/base_footprint/base_laser_left/scan
/gazebo/default/robot/base_footprint/base_laser_right/scan
/gazebo/default/robot/base_footprint/wrench
/gazebo/default/robot/fl_caster_r_wheel_link/wrench
/gazebo/default/robot/fl_caster_rotation_link/wrench
/gazebo/default/robot/fr_caster_r_wheel_link/wrench
/gazebo/default/robot/fr_caster_rotation_link/wrench
/gazebo/default/robot/torso_2_link/wrench
/gazebo/default/robot/torso_3_link/head_cam/cmd
/gazebo/default/robot/torso_3_link/head_cam/image
/gazebo/default/robot/torso_3_link/wrench
/gazebo/default/scene
/gazebo/default/sensor
/gazebo/default/skeleton_pose/info
/gazebo/default/sky
/gazebo/default/undo_redo
/gazebo/default/user_cmd
/gazebo/default/user_cmd_stats
/gazebo/default/visual
/gazebo/default/world_control
/gazebo/default/world_stats
/gazebo/server/control
/gazebo/world/modify
base_bumper

While gazebo shows black screen, I can see the full RobotModel in rviz and I can also move the base and the torso via JointTrajectoryController - however, I don't see any motion when commanding the arms although the JointState of the arms actually do change...

(Just saw that all base and troso joints have an according wrench topic in the list above...but there are only 3 out of 7 wrench topics for arm_left and none for arm_right)

So it seems that the gzserver is up and running and also the model has been loaded correctly and the controllers are running...but what's the matter with the gzclient

I've all of my cores running at 100%....4 threads from the gzserver and 1 thread from the gzclient
Am I running out of resources? I've 16GB RAM...and I can get the load of gzserver down by tweaking my world file

 <scene>
   <grid>false</grid>
   <shadows>false</shadows>
 </scene>
 <physics type="ode">
   <max_step_size>0.001</max_step_size> <!-- 0.001 -->
   <real_time_factor>0.01</real_time_factor> <!-- 1.0 -->
   <real_time_update_rate>10</real_time_update_rate> <!-- 1000 -->
 </physics>

To me this is getting weirder and weirder...

Asked by Felix Meßmer on 2018-02-13 12:44:07 UTC

Comments

While Gazebo is hanging with a black screen, could you run gz topic -l and add the output to your question?

Asked by chapulina on 2018-02-13 15:27:48 UTC

Thanks for the hint....I've added some additional information above

Asked by Felix Meßmer on 2018-02-14 03:18:14 UTC

Answers

There's a bug that is affecting projects that customise the Gazebo world name in the SDF.

Relevant issue-tracker links are https://bitbucket.org/osrf/gazebo/issues/2429 and https://bitbucket.org/osrf/gazebo/issues/2053

Does the issue go away if you change the world name to 'default' in the world file that's being loaded?

Asked by dhood on 2018-02-23 14:34:29 UTC

Comments

Thanks for pointing me to these issues... Unfortunately, I can't debug this any further atm...but I can confirm that any second gzclient shows the environment correctly...

Asked by Felix Meßmer on 2018-02-23 16:26:59 UTC

This worked for me!!! i had renamed the world and it was working till i updated to the latest version. As of right now changing the world name back to "default" solved my problem, thanks!

Asked by dont_panic on 2018-07-04 08:07:38 UTC

Worked for me as well (I would just upvote but I need more points?!)

Asked by blubbi321 on 2020-03-29 06:55:00 UTC

Should probably add that all errors I saw were [Err] [Node.cc:105] No namespace found (because of custom models?) and they still persist even though the scenario seems to work

Asked by blubbi321 on 2020-03-29 06:58:43 UTC

Make sure the models that you launched is in the path home/.gazebo/models. If not, Download it from https://bitbucket.org/osrf/gazebo_models/downloads/.

Asked by longwoo on 2018-02-25 21:45:11 UTC

Comments

thanks that helps

Asked by demiryalin on 2019-06-05 00:48:40 UTC