-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gazebo 11 does not run correctly with Ogre 1.12 from conda-forge #2700
Comments
Original comment by Silvio Traversaro (Bitbucket: traversaro).
|
2 similar comments
Original comment by Silvio Traversaro (Bitbucket: traversaro).
|
Original comment by Silvio Traversaro (Bitbucket: traversaro).
|
Original comment by Silvio Traversaro (Bitbucket: traversaro).
|
Original comment by Silvio Traversaro (Bitbucket: traversaro).
|
Original comment by Silvio Traversaro (Bitbucket: traversaro). If you check the environment used by Stephen Just to run Gazebo with Ogre 1.12 linked in microsoft/vcpkg#8178 (comment), you can notice that he added |
Original comment by Silvio Traversaro (Bitbucket: traversaro). I managed to run Gazebo built against Ogre 1.12 provided by vcpkg (in particular vcpkg version |
Original comment by Silvio Traversaro (Bitbucket: traversaro). Another (unrelated) problem that was present with Ogre 1.12 is the one mentioned (and fixed) in https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/3204/fix-ogre-fontmanager-getbyname-use-in-ogre/diff . |
Original comment by Silvio Traversaro (Bitbucket: traversaro). This change is explicitly mentioned in the Ogre 1.12 Changelog (https://github.com/OGRECave/ogre/blob/master/Docs/1.12-Notes.md#stable-media-files):
|
I recently try again with the latest ogre installed from vcpkg and the latest commit in the @seanyen @wolfv Just to understand, the gazebo package on conda-forge is still using ogre1.10 ? |
@traversaro There was an attempt to build Gazebo 11 with OGRE 1.12. Despite it is built, I ran into some issues at runtime which seems to be associated with:
However, it seems to me that in your testing, it is actually working fine with the Vcpkg OGRE port. I think I might need to retry it again. |
Finally, I was able to reproduce the problem on an almost vanilla Ubuntu 20.04, using the Gazebo 11 with ogre 1.12 binary that we recently added in conda-forge (see conda-forge/gazebo-feedstock#85):
|
By manually adding
|
I found this but it shouldn't matter as we already have 1.12.12 in conda-forge: https://forums.ogre3d.org/viewtopic.php?f=2&t=96240 |
Also see #2986 where the same error occurs. |
Interesting, this may suggest that is a general problem with Ogre 1.12.12, and not a Conda-specific problem. Indeed, in the vcpkg-based build of Gazebo (that work fine, at least in Windows) we are using Ogre 1.12.9 (https://github.com/microsoft/vcpkg/blob/45fc55825db2a5bcaffccff1e6afadc519d164ea/ports/ogre/vcpkg.json), so this could be a change/regression related to Ogre 1.12.12 . Indeed, looking at https://repology.org/project/ogre/versions the only distros with 1.12.12 seem to be some OpenSUSE one and Rosa Linux, so it is possible that no one else found this problem. However, I inspected a bit the Ogre code (in https://github.com/OGRECave/ogre/blob/v1.12.12/Components/RTShaderSystem/src/OgreShaderProgramManager.cpp#L251) and the error is related to a shader program that was not able to compile. This is compatible with the fact that the same Ogre version is used in RViz2, and there it seems to work fine, so the problem could be related to some Gazebo-specific shader. So to continue the debugging, we should at least collect some info on which shader compilation is failing, and hopefully on the specific compilation error. Probably this will require to build both Ogre and Gazebo from source. |
Hi, I tried building with ogre 1.12.9 with gazebo 11.6.0 but still same issue. Not sure if it is expected from the comment above. |
Interesting, thanks for reporting. I wonder why instead the 1.12.9 via vcpkg on Windows works fine. |
Do you think I can use strace to debug this? Never use it before. |
If the shader compilation involve any kind of system call, using strace could indeed provide some useful information, but I do not know enough of shader compilation to know if this is the case before checking. |
FYI @mboisson depending on the ogre version you have in Easybuild, you may be affected by this problem as well. |
Just FYI, ign-rendering is not a dependency of Classic Gazebo. |
Hi, I use Ogre 1.9.0 and Gazebo 11.7.0, Gazebo does not show Now Gazebo is working and does not freeze now. I can keep trying with newer Orge to see which version broke. |
Great, if you could to this it would be quite useful. |
I will keep trying more, here is the test so far.
Ogre
1.9.0 work |
So I found out that this bug occurred when Ogre change from 1.12.4 to 1.12.5. |
Maybe this PR (OGRECave/ogre#1398) is the culprit? |
@WilliamLewww just in case and if you have time, do you have any idea on what could be causing this? Asking as you seem to have quite an experience with Ogre and shaders. If you don't have time to read all the thread, no problem! |
I was able to reproduce similar results to the ones @kevinsmia1939 got. I'm hoping that OGRE just changes their syntax for their program scripts and not the actual behavior of the program parser. I'll look more into the error with v1.12.12 to find what is causing the issue. |
Thanks a lot @WilliamLewww, that's great! |
Related comment: conda-forge/libignition-gazebo-feedstock#6 (comment) . |
So, I tried to investigate this issue on Windows, with Gazebo 11.8.1 and Ogre 1.12.13 . First of all, on Windows (on Conda) the correct way to extend the
because by default the OGRE's After that, the error is the usual one on the error in GPU program, but thanks to the experience in gazebosim/gz-sim#1116 I know where to look when you have a OGRE problem: in the
The relevant error seems that
but that did not changed the problem. So, I searched for
Using the same reasoning, I tried to blindly updating the following Gazebo files:
However, after this substitutions I still get the
At this point, I guess I would need to understand something about shaders to actually progress on this issue. |
An additional point that I would like to undestand, but I was not able to understand, is why the Gazebo version (11.3.0) built with ogre (1.12.9) from vcpkg that one can get from https://github.com/robotology/robotology-superbuild-dependencies-vcpkg is able to work even without the need to change I tought it was something related to the |
@traversaro Yes, I am able to launch Gazebo 11.7.0 without any errors, building with OGRE 1.12.9 from vcpkg as you guessed. I'm not directly using the binary, but I am able to launch and use the Navigation2 example: However, I am setting I am building using the master branch of my fork of vcpkg. I was planning to make a PR to upstream after cleaning it up a bit and once microsoft/vcpkg#20565 was merged. If you'd like to test, you can download the release, extract the $env:GAZEBO_RESOURCE_PATH = "C:/opt/ros/foxy/x64/share/gazebo-11;" + $env:GAZEBO_RESOURCE_PATH
$env:GAZEBO_PLUGIN_PATH = "C:/opt/ros/foxy/x64/bin/gazebo-11/plugins;" + $env:GAZEBO_PLUGIN_PATH
$env:GAZEBO_MODEL_PATH = "C:/opt/ros/foxy/x64/share/gazebo-11/models;" + $env:GAZEBO_MODEL_PATH
$env:OGRE_RESOURCE_PATH = "C:/opt/ros/foxy/x64/tools/gazebo11"
$env:PATH += ";C:/opt/ros/foxy/x64/tools/gazebo11" Then, you can launch the nav2 example with $env:GAZEBO_MODEL_PATH+="C:/opt/ros/foxy/x64/share/turtlebot3_gazebo/models"
$env:TURTLEBOT3_MODEL="waffle"
ros2 launch nav2_bringup tb3_simulation_launch.py |
Thanks a lot for the detailed response @Ace314159 ! I can't believe that microsoft/vcpkg#8014 is going to be finally solved. |
I haven't followed all the updates here, but are there any changes needed for gazebo11 to work with ogre 1.12? |
After checking internally with the Gazebo team, we want to thanks everyone for the efforts regarding to the migration of the software to ogre-1.12. This migration is something that has not been tested by Open Robotics in any manner and could cause any kind of problems, from building errors up to any kind of rendering issues. We are specially concerned about problems with the terrain materials. Please be careful, we can not guarantee that the software keeps working as it does with ogre-1.9. Feel free to keep forwarding feedback and patches (issues are welcome although we can not assure to have the human resources to fix them in a short period of time). If by any reason Open Robotics find the resources needed to accomplish the migration, we'll update this same issue. |
Beside everything that @j-rivero wrote, i.e. that Ogre 1.12 is in any case not feature parity with Ogre 1.9 for what regards integration with Classic Gazebo (but I guess I do not need to explain this to you : ) ), this is the current experienced outcome when using Ogre 1.12 (I just report distro and ogre version, but perhaps other factors play a role) :
|
I made some progress with Ogre 1.12.10 on Debian unstable. From reading the code I don't think setting |
Are there any new updates? How can I help with debugging, maybe my logs will be useful? My setup: Ubuntu 20.04, ROS 2 Galactic, Gazebo (11.10.1-1~focal). With the update to the gazebo11 (ver 11.10.1) in the last ROS 2 Galactic sync my launch files and Gazebo overall stopped working correctly (services are timed out). I described it with details in this issue: #3173. @jspricke Can these errors be connected? |
Hello @ljaniec, sorry for the late response: I do not think your problem is connected, if you are using the official Gazebo binaries from apt you are probably using Ogre 1.9 from apt packages. |
I was able to compile Gazebo on windows with my fix PR with ogre 1.12.9 and qwt 6.1.5 and graphviz 2.49.1. For compiling:
This compile gazebo but I didn't succeeded to run it. Also vcpkg tool can help you to compile your 3rd libraries for windows and linux. Maybe for mac with extra work. |
I made a PR that compile gazebo in windows: |
Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).
There have been two reports of problems in running Gazebo compiled against Ogre 1.12, one by Sean Yen (seanyen-msft) ( https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/issues/2686/terrain-rendering-does-not-support-shadows (#2686)#comment-56374947 ) and the other by Wolf Vollprecht (Wolf) ( conda-forge/gazebo-feedstock#11 (comment) ), and in both cases the error message is:
In both cases, they were using the Ogre 1.12 installed by conda-forge. Based on this error, and the fact that apparently Stephen Just ( https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/3130/change-gazebo-rendering-heightmap-class-to/diff#comment-125305344, microsoft/vcpkg#8178 (comment) ) was able to run a patched Gazebo 10 linked with Ogre 1.12 using vcpkg, I suspect that the error is that Ogre is not able to find some resource, possibly because some Ogre resource directory is not correctly set, but this is just an hypothesis.
Based on his work on https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/3130/change-gazebo-rendering-heightmap-class-to/diff#comment-125305344, perhaps Martin Pecka (peci1) may be able to provide some input on this.
The text was updated successfully, but these errors were encountered: