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
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
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