@JRTG Dear Johan,
thank you for bringing this point up.
Actually, there are multiple simulation options for ROS, in addition to Gazebo, each with its strengths, including:
- Carla (with its ROS bridge)
- Unity Robotics
- NVIDIA Omniverse Isaac Sim
My team has extensively used Gazebo and Carla (we also did engine customizations, like adding a VR mode that was presented by WayRay at CES 2019) and evaluated Webots and Isaac Sim.
We also have in-depth knowledge of the Godot Engine: we built an AR rendering engine based on it for WayRay, where we also integrated both ROS1 and ROS2 with it, but we could not release those components to open-source.
At WayRay we also created a more lightweight vehicle simulator based on it (including VR mode), that we could use in situations where the photorealistic rendering of Carla (and Unreal) was not necessary, but could be run on less powerful machines and provided better developer experience (e.g. shorter build & startup times).
When designing a system, one can go in multiple directions:
- The Gazebo team, as you wrote, decided to create a completely modular system, where many modules can be replaced as needed.
- It is also a valid design choice to choose a generic engine like Unreal (for Carla), Unity, or NVIDIA Omniverse, and build the robotics simulation and ROS integration on top of that.
Our main design goals for our solution are as follows:
- We wanted to use the Godot Engine as the base because we know it well, and we think that it is a great development platform (this includes developer UX, authoring tools, runtime performance, and support for many different platforms). Godot also provides carefully selected extension points, e.g. it will be possible to integrate different Physics engines, if/when the need arises, and it already supports most GPU APIs out there.
- We also wanted to build on top of an open-source base, which meant that Unity and Unreal were not an option.
- We also would like it to support different GPUs, not just NVIDIA.
- The solution needs to be lightweight, so it can run on less powerful machines or even on standalone VR headsets, like the Meta Quest series which we also have experience with.
- We are currently targeting the simulation of relatively simple AMRs only (wheeled base + sensors), not a completely generic solution. Of course, if there is interest (and support) from the community, we would be very much interested in extending the scope.
- We are also interested in providing AR and VR experiences e.g. overlaying point-cloud data from a robot on a real or simulated scene.
You also asked, why aren’t we contributing to Gazebo, instead of starting something new.
One of the reasons we are working with the Godot Engine is to leverage the power of its community. We are also Godot contributors with already accepted patches and other contributions under discussion. And with Godot, we can leverage a larger ecosystem, not just in the context of robotics simulation, but also many others that require related technologies like 3D games, AR / VR experiences, …etc.
So we are building on top of an existing system, just not on top of Gazebo.
This reply is already becoming very long, but I would be happy to continue the discussion. I would also be happy to talk to anyone from the community, who is interested in supporting the project.
For example, I think that industry standards like IFC (from Architecture / Construction) and USD (and its related standards like MaterialX) are very important to support natively in our open-source tools. This will enable easy round-trip engineering between architects and robotics engineers to test automation systems in buildings in virtual environments that have not yet been built and provide valuable feedback during the design phase. The IFC side is coming along nicely with BlenderBIM and more recently FreeCAD, but there is still much to do on the USD front.