Gazebo Harmonic packages available on Ubuntu Noble

General
1

Hi all:

The Gazebo Harmonic Ubuntu packages for the recently released Ubuntu 24.04 (Ubuntu Noble) are now ready in the stable repository of packages.osrfoundation.org. The usual Gazebo Harmonic instructions for Ubuntu apply now for Noble.

Packages are available for amd64 and arm64.

On armhf: Dart 6.13 has dropped the support for 32 bits architectures so gz-physics lost its main physics engine in this platform and packages depending on gz-physics are not generated for Harmonic on armhf this time so the whole release is not complete.

Enjoy.

3 Likes
2

the gazebo harmonic can be installed but when starting something goes wrong!

error message are :

yjph@yjph-ubuntu24:~$ gz sim
QSocketNotifier: Can only be used with threads started with QThread
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1285] Unable to create the rendering window: OGRE EXCEPTION(3:RenderingAPIException): currentGLContext was specified with no current GL context in GLXWindow::create at ./RenderSystems/GL3Plus/src/windowing/GLX/OgreGLXWindow.cpp (line 165)
[GUI] [Err] [Ogre2RenderEngine.cc:1293] Unable to create the rendering window after [11] attempts.
[GUI] [Err] [Ogre2RenderEngine.cc:1191] Failed to create dummy render window.
[GUI] [Err] [Ogre2RenderEngine.cc:1192] Please see the troubleshooting page for possible fixes: Gazebo
Stack trace (most recent call last):
#31 Object “/lib/x86_64-linux-gnu/libgz-sim8-gui.so.8”, at 0x702f7b674fa0, in gz::sim::v8::gui::runGui(int&, char**, char const*, char const*, int, char const*, char const*)
#30 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a2df3e7, in QCoreApplication::exec()
#29 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a2d6a7a, in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
#28 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a335278, in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
#27 Object “/lib/x86_64-linux-gnu/libglib-2.0.so.0”, at 0x702f7b513a52, in g_main_context_iteration
#26 Object “/lib/x86_64-linux-gnu/libglib-2.0.so.0”, at 0x702f7b573716, in
#25 Object “/lib/x86_64-linux-gnu/libglib-2.0.so.0”, at 0x702f7b5145b4, in
#24 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a335c0e, in
#23 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a2db94a, in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
#22 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a2d8117, in QCoreApplication::notifyInternal2(QObject*, QEvent*)
#21 Object “/lib/x86_64-linux-gnu/libQt5Widgets.so.5”, at 0x702f7996bd44, in QApplicationPrivate::notify_helper(QObject*, QEvent*)
#20 Object “/lib/x86_64-linux-gnu/libQt5Core.so.5”, at 0x702f7a306342, in QObject::event(QEvent*)
#19 Object “/usr/lib/x86_64-linux-gnu/gz-gui-8/plugins/libMinimalScene.so”, at 0x702f60245524, in gz::gui::plugins::RenderWindowItem::Ready()
#18 Object “/usr/lib/x86_64-linux-gnu/gz-gui-8/plugins/libMinimalScene.so”, at 0x702f602451b4, in gz::gui::plugins::RenderThread::Initializeabi:cxx11
#17 Object “/usr/lib/x86_64-linux-gnu/gz-gui-8/plugins/libMinimalScene.so”, at 0x702f602539cf, in gz::gui::plugins::RenderThreadRhiOpenGL::Initializeabi:cxx11
#16 Object “/usr/lib/x86_64-linux-gnu/gz-gui-8/plugins/libMinimalScene.so”, at 0x702f602498b8, in gz::gui::plugins::GzRenderer::Initializeabi:cxx11
#15 Object “/lib/x86_64-linux-gnu/libgz-rendering8.so.8”, at 0x702f601e1ec2, in gz::rendering::v8::RenderEngineManager::Engine(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::map<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::less<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#14 Object “/lib/x86_64-linux-gnu/libgz-rendering8.so.8”, at 0x702f601e1c14, in gz::rendering::v8::RenderEngineManagerPrivate::Engine(EngineInfo, std::map<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::less<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits, std::allocator > const, std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#13 Object “/lib/x86_64-linux-gnu/libgz-rendering8.so.8”, at 0x702f601ea77f, in gz::rendering::v8::BaseRenderEngine::Init()
#12 Object “/usr/lib/x86_64-linux-gnu/gz-rendering-8/engine-plugins/libgz-rendering-ogre2.so”, at 0x702ee63f9746, in gz::rendering::v8::Ogre2RenderEngine::InitImpl()
#11 Object “/usr/lib/x86_64-linux-gnu/gz-rendering-8/engine-plugins/libgz-rendering-ogre2.so”, at 0x702ee63fc42b, in gz::rendering::v8::Ogre2RenderEngine::InitAttempt()
#10 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5eff7cf, in Ogre::ResourceGroupManager::initialiseAllResourceGroups(bool)
#9 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f0cf97, in Ogre::ResourceGroupManager::parseResourceGroupScripts(Ogre::ResourceGroupManager::ResourceGroup*)
#8 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f4c861, in Ogre::ScriptCompilerManager::parseScript(Ogre::SharedPtrOgre::DataStream&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#7 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f43f69, in Ogre::ScriptCompiler::compile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#6 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f43c52, in Ogre::ScriptCompiler::compile(Ogre::SharedPtr<std::__cxx11::list<Ogre::SharedPtrOgre::ConcreteNode, Ogre::STLAllocator<Ogre::SharedPtrOgre::ConcreteNode, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#5 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f546aa, in Ogre::MaterialTranslator::translate(Ogre::ScriptCompiler*, Ogre::SharedPtrOgre::AbstractNode const&)
#4 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f5599f, in Ogre::TechniqueTranslator::translate(Ogre::ScriptCompiler*, Ogre::SharedPtrOgre::AbstractNode const&)
#3 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5f5b64b, in Ogre::PassTranslator::translate(Ogre::ScriptCompiler*, Ogre::SharedPtrOgre::AbstractNode const&)
#2 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5fcd576, in Ogre::Technique::createPass()
#1 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5ec5aff, in Ogre::Pass::Pass(Ogre::Technique*, unsigned short)
#0 Object “/usr/lib/x86_64-linux-gnu/OGRE-2.3/libOgreNextMain.so.2.3.1”, at 0x702ee5df24a6, in Ogre::Hlms::createDatablock(Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, Ogre::HlmsMacroblock const&, Ogre::HlmsBlendblock const&, std::vector<std::pair<Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, Ogre::STLAllocator<std::pair<Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits, std::allocator > >, Ogre::CategorisedAllocPolicy<(Ogre::MemoryCategory)0> > > const&, bool, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)

3

Thanks for the quick testing @yjphhw.

Please do not report issues, it is hard to manage them properly. The robotics.stackexchange.com forum would be a better place for your issue, first to search if someone reported it before or to create a question there if you did not find any existing that applies. If you think that it is not a problem on your end but a real bug in the code, please use the gz-rendering issue tracker.

I would also recommend to search the Gazebo documentation for trying different documented solution. Particularly the Gazebo troubleshooting document could help you.

Good luck.

4

thanks for your reply. the problem is solved.

In login interface, at the right corner choose the Xorg Ubuntu.

5

Are there Noble packages for Fortress on the way?

6

There are no plans on releasing Fortress (which now supports Focal and Jammy) for Noble. Harmonic and the future Ionic are currently the releases that target Ubuntu Noble.

7

I’d like to thank you all for the great effort integrating Gazebo with ROS (again) up to the ROS buildfarm level :slight_smile:

I hope it will make it possible to release great Gazebo plugins as ROS buildfarm packages, as we were used to from the Classic days! (even better would be to be able to release non-ROS Gazebo plugins directly on Gazebo buildfarm, but that’s a different story).

We definitely have great plans for plugin releases (with unsure timeline :slight_smile: ).

I’m especially curious how will this integration change the adoption of the lower-level libraries (gz-math, gz-common) by ROS packages. I see a great potential there.

I’m just curious whether this integration is a result of a long-existing plan, or if it was started as a result of the feedback you gathered some time ago asking about the hurdles in migration to new Gazebo.

8

I’m having some problems getting this version of Gazebo with ROS paring. My goal is simply to have Gazebo and ROS installed, and I plan to develop a plugin.

I follow the installation instructions, which seem to work fine, but I can’t find the Gazebo binary.

I’ll describe what I’ve done:

  • I have a fresh Ubuntu 24.04 VM, ran sudo apt update, sudo apt ugprade.
  • I’ve installed ROS2 Jazzy as explained here Ubuntu (Debian packages) — ROS 2 Documentation: Jazzy documentation . I verify the ROS2 installation works by running the talker/listener example.
  • I proceed to install Gazebo harmonic for ROS users as listed here Gazebo . What I do is run sudo apt-get install ros-jazzy-ros-gz.
  • It runs succesfully, and I see that it installed package ros-jazzy-gz-sim-vendor, which is what I would expect to contain Gazebo’s binary, judging by the package name.

Now the issue:

  • If I search for “Gazebo” in my system, nothing shows up.
  • I try to run “gz sim”, “gz-sim”, “gz_sim”, “gz-sim-vendor”, but none of these commands are found.

I was able to follow these steps in Ubuntu 22.04 (and it’s respective ROS2 and Gazebo version), which then would get me the Ignition Gazebo program installed.

I guess my issue is related to the vendor packages changes for Ubuntu 24.04? I don’t understand what I should be doing instead, and I couldn’t figure out from the documentation alone.

Sorry if this isn’t the right place to post this, and thanks for any help!

9

Thanks for the quick testing @pedrofz.

Please do not ask issues here, it is hard to manage them properly. The robotics.stackexchange.com forum would be a better place for your issue, first to search if someone reported it before or to create a question there if you did not find any existing that applies.

For your case:

  • Be sure to have installed the ros-jazzy-gz-tools-vendor and ros-jazzy-gz-sim-vendor packages.
  • Source the setup.bash file in ROS: . /opt/ros/jazzy/setup.bash
  • The gz command should be avilable in PATH from /opt/ros/jazzy/opt/gz_tool_vendor/bin/gz and all the gz commands should be accesible.

Good luck.

10

Thanks, I’ll refer to the the other forum for further technical questions. Since we’re already here, I’ll just post a final update to that.

My issue is fixed. It was just that I had not sourced that file. It never occurred to me that the gazebo installation I had was related to the sourced file at all. Simply running . /opt/ros/jazzy/setup.bash made the gz commands available.

And just for completeness, the packages you mentioned were already installed (by the previous commands I had run).

Thank you for the support.

11

I hope it will make it possible to release great Gazebo plugins as ROS buildfarm packages, as we were used to from the Classic days! (even better would be to be able to release non-ROS Gazebo plugins directly on Gazebo buildfarm, but that’s a different story).

Yeah, we’ve started thinking about how we can better support community contributed plugins (see Third-party/external plugin repository · Issue #1995 · gazebosim/gz-sim · GitHub for the initial issue). One thought goes along the lines of what you suggested—releasing Gazebo plugins as ROS packages, maybe with some extra metadata that indicates that they are Gazebo plugins. Still in its early stages, but we plan to work on it in the next few months.

I’m especially curious how will this integration change the adoption of the lower-level libraries (gz-math, gz-common) by ROS packages. I see a great potential there.

Packages up-to gz-math (i.e, gz-cmake, gz-utils, and gz-math) are already part of ROS core since they are used in Rviz. This has been the case since Humble, but one-off vendor packages were created just for Rviz and were not updated when the upstream packages were updated. The new vendor packages bring all the Gazebo libraries, provide very convenient CMake shims, and will be in sync with the upstream packages, so, yes, I hope there will be more adoption.

I’m just curious whether this integration is a result of a long-existing plan, or if it was started as a result of the feedback you gathered some time ago asking about the hurdles in migration to new Gazebo.

From my perspective, we’ve been looking for ways to better integrate Gazebo and ROS for some time (e.g. use of ign-math in Rviz starting in Humble), and the vendor packages idea was brought up as one approach as we were brainstorming on how to package Gazebo for Jazzy since it wasn’t going to be available in upstream Ubuntu Noble. But the feedback we got, especially around the complexity caused by having the major version number in the names of packages, definitely encouraged us to pursue the vendor package idea. So I want to take this opportunity to thank everyone who filled out the survey!

1 Like