Gazebo Source Installation

[lucarei]

Hi Andrej. I am still trying to install your project on my local machine (Ubuntu 20.04, ROS Galactic). I am sorry for basic questions but i am a newbie who is working a lot to obtain your results.

I have made progresses, i found different environment variables to be set that can help people to install smoothly this repo (i will share them when i finish a right install, to contribute to this project).

I had the following trouble: "Tried to convert SDF [world] into [plugin]". I solved it using gz-sim with commit hash 2938ede, as you suggested here (gazebosim/gz-sim#1555), following the tutorial written here (https://gazebosim.org/docs/fortress/install_ubuntu_src) for building gazebo fortress from source.

However, running the example "ros2 run drl_grasping ex_random_agent.bash", the simulation in Gazebo doesn't start correctly (other messages seems to be equal to what i obtain from the execution of your docker image, running the same command).

I had the following errors, i cannot find anything online:

I thought that the problem could be related to the other packages of Gazebo Fortress (https://raw.githubusercontent.com/ignition-tooling/gazebodistro/master/collection-fortress.yaml): maybe they are newer if compared to gz-sim (with hash 2938ede) and this version mismatches causes problems of compatibility inside Gazebo.

Then, i tried to recompile gz-sim together with older versions of the other packages (gz-cmake, gz-physics, gz-sensors etc) using commit hashes referred to periods prior to 14/04/2022 (data when date gz-sim with commit hash 2938ede was released). I used “gitk” in each gazebo package folder in order to restore a version of that package which could correspond to the same period of our needed commit of gzsim.

I don't know if this approach could be successful but up to now it doesn't work. Maybe you can give me the list of right commit hash for each package inside gazebo and i can overcome this issue. It is just a guess, nothing else.

In general, beside all the unuseful stuffs that i have mentioned, could you suggest me a solution?
Thank you for supporting me in this work.

[AndrejOrsula]

Hello @lucarei,

I had the following trouble: "Tried to convert SDF [world] into [plugin]". I solved it using gz-sim with commit hash 2938ede, as you suggested here (gazebosim/gz-sim#1555), following the tutorial written here (https://gazebosim.org/docs/fortress/install_ubuntu_src) for building gazebo fortress from source.

Oh yes, I remember this issue (sorry, I forgot to mention it in the previous issue). Downgrading gz-sim (ign-gazebo) to version 6.9.0 was the only solution I was able to find. After that, it resolved my issues with the simulation freezing right at the start. I was unsuccessful in trying to debug the issue with the latest release of 6.12.0 at the time, and I have not had time to investigate it again.

However, running the example "ros2 run drl_grasping ex_random_agent.bash", the simulation in Gazebo doesn't start correctly (other messages seems to be equal to what i obtain from the execution of your docker image, running the same command).

Unfortunately, I am not sure what could be causing this issue, as there are many parts at play.
First, I would also try to see if Gazebo examples are functional (and examples from gz_ros2_control).

Could you try to elaborate a bit more about what happens? Does the simulation freeze or crash immediately? Maybe there is some useful information.

I had the following errors, i cannot find anything online:

Hmm, I remember the 1-4 warnings, which are annoying - but I think should be harmless. I remember seeing the internal physics error despite everything working, so there is probably no connection with the issue. I don't recall the last warning, so I cannot comment on that.

When I was having the issue above, there were not really any useful debug messages either. So it can be difficult to find why it is not functional...

Then, i tried to recompile gz-sim together with older versions of the other packages (gz-cmake, gz-physics, gz-sensors etc) using commit hashes referred to periods prior to 14/04/2022 (data when date gz-sim with commit hash 2938ede was released).

Your approach is exactly what I would try as well. Maybe there are some other dependencies that introduced breaking changes for this repository? (this repository is quite an edge-case scenario for many packages)

Maybe you can give me the list of right commit hash for each package inside gazebo and i can overcome this issue.

Unfortunately, I do not have this list. Maybe you could try the vcstool list found under robotology-legacy/gym-ignition#430. I think that might be the best bet.

FYI: As this repository is directly dependent on gym-ignition, robotology-legacy/gym-ignition#430 also brings some insights about the current status of this repository. With this issue in mind, it is unlikely that this repository will be updated for Gazebo Garden as it would require a considerable amount of effort (especially with the breaking changes that are already present after Fortress 6.9).

As the last alternative, I would probably start with the prebuilt Docker image and use it as the development environment while committing changes directly to the Docker image itself (docker commit). I understand that this is far from ideal though.

[lucarei]

I am trying to give you a more accurate snapshot of my configuration/warnings obtained.

I start analyzing all the possible Gazebo installation methods, testing them with gz_ros2_control *1 example suggested by you.

1. Using package list given in robotology/gym-ignition#430: gazebo is correctly compiled but doesn't pass our test also if i set the correct environment variable (export IGN_GAZEBO_SYSTEM_PLUGIN_PATH=/home/lrros2/ws_dir/install/lib), as shown in following image.
   
   Moreover, the installed gz-sim version is 6.0.0 and not the desired 6.9.0, as Andrej said:

Downgrading gz-sim (ign-gazebo) to version 6.9.0 was the only solution I was able to find. After that, it resolved my issues with the simulation freezing right at the start.

2. Then i thought to use the list of point 1 (robotology/gym-ignition#430), substituting gz-sim with our desired one (with commit hash 2938ede, version 6.9.0). Colcon build fails:(

3. Using older version of packages (considering just date as reference) generate a series of difficult to resolve dependancies, as i said in the first message of this issue.

I used “gitk” in each gazebo package folder in order to restore a version of that package which could correspond to the same period of our needed commit of gzsim.

4. Final option (and maybe the best of them) is use the latest version of each package (fortress-source-official-tutorial) and downgrade just gz-sim to commit 2938ede (6.9.0). Using this option and compiling it, you will obtain just a stderr that disappear if you compile again it. Moreover, tests with gz_ros2_control works.
   

RESULT: Among my tests, option 4 could be the best. However, consider that i obtained all these 5 errors/warnings that i show you in the first message of this issue. For this reason i opened it. In the next message i will describe what happens running your project with configuration 4.

NOTE 1 (for other people): gz_ros2_control is a package already inside drl_grasping project.
NOTE 2: the 4th configuration was just tested by me without any previous knowledge, i haven't read other people who adopted this method.

[lucarei]

This is the second part: analysis of robot-model/reach-task/grasp-task/grasp-planetary-task with 4th configuration of gazebo.

1. Test for robot packages (both panda and lunalab, just robot packages and nothing else) works successfully in Gazebo-RVIZ (also moveit works even if i receive a failure error; i think is not related with this issue). Following image for proof.

2. Test with Panda/Reach (EX: ENV="Reach-Octree-Gazebo-v0"): it seems to work fine. However, there are the following drawbacks: presence of repetitive errors/warnings (as "internal error" or "failed to find world") AND warning in TF on RVIZ (No transform from world to drl_grasping_world).

3. Test with Panda/Grasp (EX: ENV="Grasp-Octree-Gazebo-v0"): here there are problems. Gazebo doesn't start. There are still the repetitive Error/Warnings (as "internal error" or "failed to find world"). Robot model seems to be not correctly loaded (TF on RVIZ). Cannot find models ( Model could not be inserted: 'a' cannot be empty unless no samples are taken ).

4. Test with LunaLab/Grasp ( EX: ENV="GraspPlanetary-Octree-Gazebo-v0"). Same issues of point (3). In addition there is this warning -> [WARN] [1680861700.124323815] [drl_grasping_0]: Model could not be inserted: Invalid path '' pointed by 'SDF_PATH_LUNAR_ROCK' environment variable.

FINAL NOTE: i thought that the presence of those error (as "internal error" or "failed to find world") were related to a wrong installation of Gazebo Fortress. For this reason i opened this issue. If it wasn't like I say, we can close this issue and it could be useful for others to install Gazebo for this project, following these footsteps. Please suggest me the right way to solve.

[lucarei]

UPDATE

Your project seems to work on 4th Gazebo Configuration (up to now, just testing "ex_random_agent.bash").

It is necessary to correctly download the models of the objects, otherwise the simulation cannot start finely. You might think that is related to Gazebo or other things since camera or TF were not correctly published but focusing on correct object models download fixes a bunch of problems.

You can use:

• bash files inside drl_grasping>scripts>utils>dataset.
• OR "process_collection.py" inside drl_grasping>scripts>utils (i used this to fix).

However, there are still the repetitive errors that i have shown to you as "Failed to Find World" (and the others listed in the first message of this issue). In fact, the world is not correctly loaded.

Here the list of commit hash for 4th configuration of Gazebo (i am not sure that it is completely right due to the previous errors):

1. gz-gui: 650d505baf812d2aa65150d06f54d4c2fea68499
2. gz-show: 8127d83af5242d48efe9f4d862acb7d7b910375b
3. gz-sim: 2938ede79feeb0fb1638370b910f06fb530be0ee (IMPORTANT)
4. sdformat: bacb133371fe2825b367bbd22acdc55834814e15
5. gz-cmake: c8666e3e35174ddaacfe52c5c2d441f80cb86ce9
6. gz-launch: aa5f470a24120832792c46e0150cfd017b3e1060
7. gz-plugin: ec0bd40c2eca69db56f799f446f489b66ca51144
8. gz-tools: c6932dbdc9df42ec19d46c52baa648e90a9eb3e3
9. gz-common: 029794255fb1d730d9b4a3c5323c45282721c17d
10. gz-math: 27cdb934a5c6008fedf4792225ab94a714c138ed
11. gz-rendering: 420f8f100c7526e92dec6aa13a9a7e6b1cc78da4
12. gz-transport: 8b7835c52b96cc566e4d7f23ce8363aa809b2b14
13. gz-fuel tools: a0fa5af21622fd4c72eab79e53a1e75e85068134
14. gz-msgs: 2838df72c191f7bdf71b5640169fbfca239cd9e2
15. gz-sensors: f25ac3c1ff50a27ec97442c97375d08514b49e57
16. gz-utils : 0f3aa90afe449af80b275301d218db9632a8df44

I'm closing this issue because the simulation started (and in general we obtained a way to install a working version of Gazebo 6.9), even if the errors are still there.

[AndrejOrsula]

Thank you @lucarei for this analysis and the list of commit hashes!

It is necessary to correctly download the models of the objects, otherwise the simulation cannot start finely.

If that's the case, it would appear that the automatic download of models from Fuel (Google Scanned Objects collection) is not working properly anymore. I don't know what is causing that, but I am happy you were able to find a workaround.

In fact, the world is not correctly loaded.

What part of the world is not loaded correctly?

[lucarei]

Thank you @lucarei for this analysis and the list of commit hashes!

No worries, it is a pleasure for me to work (and help) on your project.

What part of the world is not loaded correctly?

It was my mistake. I have seen the blank ground without any texture and i thought that something went wrong. I solved it as i described in following point 2, downloading texture files. Up to now, random example seems to work fine, i will work on training now.

NOTE: there are still the errors that i shown to you but everything works up to now so i decided to hide them modifying the log level.

TIPS for OTHER DEVELOPERS:

1. OBJECTS

it would appear that the automatic download of models from Fuel (Google Scanned Objects collection) is not working properly anymore.

Placing in a correct way the Google dataset is crucial, otherwise other stuffs cannot work (EX: RVIZ doesn't load TF for each link of the robot arm).
If you have troubles, you can manually download Google Dataset and place the models in the following path:

/home/your_user/.ignition/fuel/fuel.ignitionrobotics.org/googleresearch/models/your_models_folder

2. TEXTURE

You can download texture from an Andrej's repo: they are used in file random_ground.py.
If you have troubles, you can manually choose one desired texture using the following code inside random_ground.py:

albedo_map='/home/<your_user>/ws/src/pbr_textures/grass1_1k_2/grass1_1k_1_basecolor.png'
normal_map='/home/<your_user>/ws/src/pbr_textures/snow_1k_3/grass1_1k_1_normal.png'
roughness_map='/home/<your_user>/ws/src/pbr_textures/snow_1k_3/grass1_1k_1_roughness.png'
metalness_map='/home/<your_user>/ws/src/pbr_textures/snow_1k_3/grass1_1k_1_specularlevel.png'