Package Details: gazebo 10.1.0-4

Git Clone URL: https://aur.archlinux.org/gazebo.git (read-only, click to copy)
Package Base: gazebo
Description: A multi-robot simulator for outdoor environments
Upstream URL: http://gazebosim.org/
Licenses: Apache
Submitter: None
Maintainer: billypilgrim
Last Packager: billypilgrim
Votes: 28
Popularity: 0.45
First Submitted: 2008-10-18 22:59
Last Updated: 2020-01-16 12:11

Dependencies (33)

Sources (3)

Latest Comments

« First ‹ Previous ... 4 5 6 7 8 9 10 11 12 13 14 ... Next › Last »

nicolino commented on 2018-09-10 14:17

Hi,

I have tried to install various source version of ogre (the various ogre* packages on AUR) but no one of them was perfectly compatible with the current version of gazebo.

Recap:

Current version of gazebo with precompiled ogre binary: does compile but does not work entirely: exception + segfault when loading complex models from the online repo (i.e. something that has a texture). The actual point of failure is when gazebo calls the ogre subsystem to load the .material files: Ogre::ResourceGroupManager::getSingleton().openResource() that lie inside the ogre libraries (/usr/lib/libOgreMain.so).

So the sources of ogre are needed to go through them with a debugger.

Current version of gazebo with various combinations of source ogre: does not compile. Gazebo sort of "wants" ogre 1.11 but it is not available as a AUR package.

I am thinking of getting and installing ogre from THE OGRE repository, but it is more or less against Arch policy (outside AUR).

Ideas?

Best Regards

NOTE: To go back to previous version of gazebo (9.0), that was compatible with ogre 1.10, requires OLD BOOST.

NOTE2: Apparently, there is not a version 1.11 on the ogre website (https://bitbucket.org/sinbad/ogre/src).

nicolino commented on 2018-09-10 12:21

Hi,

The very last version of gazebo has still the same segmentation fault after the exception in loading material files.

I am recompiling ogre-git with debug symbols and seeing what's wrong.

However, the time window for which I can dedicate resources to drill into this subject is closing, please consider taking charge.

@jlecoeur:

I do not know why, but the ogre patch is missing from the package (also commented in the PKGBUILD). I have managed to make the last version compile by downloading the modified ogre-1.11.patch (thanks AGAIN to @nodabba): https://gist.github.com/n0dabba/bd586b466da068e2eb9a24c003d507c1, putting it in the source dir and decommenting the PKGBUILD.

@Teasp00n:

No, the patch (ogre-1.11) is still good AND necessary.

The problem is inside the (precompiled as in binary package) Ogre libraries.

Best Regards

jlecoeur commented on 2018-09-10 10:07

The build is still broken

Scanning dependencies of target gazebo_rendering
[ 43%] Building CXX object gazebo/rendering/CMakeFiles/gazebo_rendering.dir/ApplyWrenchVisual.cc.o
In file included from /tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/MovableText.hh:27,
                 from /tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/ApplyWrenchVisual.cc:24:
/tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/ogre_gazebo.h:34:10: fatal error: OGRE/OgreWindowEventUtilities.h: No such file or directory
 #include <OGRE/OgreWindowEventUtilities.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [gazebo/rendering/CMakeFiles/gazebo_rendering.dir/build.make:63: gazebo/rendering/CMakeFiles/gazebo_rendering.dir/ApplyWrenchVisual.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2583: gazebo/rendering/CMakeFiles/gazebo_rendering.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

tsp commented on 2018-09-08 13:34

Did you mean to remove the ogre-2.11 patch from the sources?

nicolino commented on 2018-09-08 11:51

Hi,

sorry for the mess, I am of the EE bunch, not ITC, my approach to coding is more or less "BRUTAL".

New version of gazebo crashes every-single-time a specific subset of models is loaded from the online repository.

The specific subset of models is identified by the presence, in all of its component models, of extra materials. In other words: textures and relative .material files.

I have managed to run gzclient through gdb (gzserver is running on its own) and I found out that the crash is generated by an exception catched in the file gazebo/rendering/RenderEngine.cc, the same in which the patch about the extra plugins (see below) had to be applied.

The exception is generated in the try block of RenderEngine:479 and, in detail, at line 509:

509            Ogre::DataStreamPtr stream =
510              Ogre::ResourceGroupManager::getSingleton().openResource(
511                  fullPath.string(), "General");

Inspecting the variable, fullPath is correct, but executing call fullPath.string() throws out a syntax error (in the debugger).

Browsing through the Boost Libraries Reference (https://www.boost.org/doc/libs/1_67_0/libs/filesystem/doc/reference.html) I have found out that there is not a unparametrized string() function.

There is indeed an unparametrized template <class String> String generic_string() const indeed, and inspecting with call fullPath.generic_string() returns the correct file path.

Recompiling with generic_string still catches an exception from the very same function Ogre::ResourceGroupManager::openResource().

After that, gdb loses its track inside /usr/lib/libOgreMain.so with Cannot find bounds of current function before returning with the exception catched and me losing my patience.

I do not know from how long this was going on but I reckon never being able to open certain models (FROM THE ONLINE REPO AVAILABLE INSIDE THE PROGRAM) in gazebo. After clicking on the model, nothing happened.

I suspect that the exception has always been thrown. The difference is that with the new boost and ogre, this time the program returns execution.

So:

1) Am I missing something important in a very, very dumb way?

2) In case there is a real problem with the code:

2a) Does anyone have the possibility to debug the rest of the OgreMain?

2b) Should we notify upstream?

If you want to replicate the experiments remember to recompile the code with -g -O0 as, in other cases, optimization changes in the source are significant.

Best Regards.

nicolino commented on 2018-09-06 09:33

Hi,

I would like to remind that I did not concoct the patch, I just found the useful part in the @nodabba comment and highligted it.

Best Regards

kikislater commented on 2018-09-04 07:23

So is it possible to put nicolino patch in build ?

cptnapalm commented on 2018-08-28 22:49

Just to be an additional confirmation, the portion of the patch pointed out by nicolino does, in fact, cures the 'png' codec problem during compilation.

nicolino commented on 2018-08-14 19:06

Thanks nodabba,

now Gazebo compile and runs with latest boost and ogre.

This part:

diff -ruN original/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc 
patched/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc
--- original/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc      2018-01-25 23:25:48.000000000 +0100
+++ patched/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc       2018-06-02 21:21:19.426983596 +0200

@@ -425,6 +425,11 @@
     std::string extension = ".so";
 #endif

+#if (OGRE_VERSION >= ((1 << 16) | (11 << 8) | 0))
+    plugins.push_back(path+"/Codec_EXR");
+    plugins.push_back(path+"/Codec_FreeImage");
+#endif
+
     plugins.push_back(path+"/RenderSystem_GL");
     plugins.push_back(path+"/Plugin_ParticleFX");
     plugins.push_back(path+"/Plugin_BSPSceneManager");

did the trick.

Best Regards

nodabba commented on 2018-08-14 17:51

I was able to compile and run gazebo with the following modified ogre-1.11.patch: https://gist.github.com/n0dabba/bd586b466da068e2eb9a24c003d507c1 Current patch was lacking of one more fix (see https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111 for more info). Thanks @greboide for link.