Migration from Gazebo-classic: Plugins
Classic Gazebo supports 6 different C++ plugin types, each providing access to different parts of the API, like physics, rendering, sensors, GUI, etc. Due to Ignition Gazebo's architecture based on an ECS , plugin interfaces are somewhat different, but more varied and in many cases much more powerful. Some plugins in Ignition are systems within Ignition Gazebo, while others are specific plugin types from other Ignition libraries.
- Plugin types other than systems may be added to Ignition Gazebo in the future.
For example, plugins which get and set properties of simulation entities would be Ignition Gazebo systems. On the other hand, there are now plugin interfaces which didn't exist in Gazebo, such as integrating a new physics or rendering engine, and these can be also used in projects outside of Ignition Gazebo.
Take a look at the comparison below:
|Classic plugin||Features||Ignition equivalent||Differences|
|World||Get/set properties of the world and its children||Gazebo system||Get/set components.|
|Model||Get/set properties of the model and its children||Gazebo system||Get/set components.|
|Visual||Get/set properties of the visual and its children||Gazebo system||Get/set components.|
|Sensor||Get/set sensor properties and readings||Gazebo system||Get/set components.|
|World / Model||Access physics-engine-specific features||Physics plugin||Loaded by ign-physics|
|Visual||Access rendering-engine-specific features||Rendering plugin||Loaded by ign-rendering|
|Sensor||Connect to callbacks||Standalone program||Subscribe to Ignition Transport messages.|
|All||Connect to simulation events||Gazebo system||Use |
|GUI||Add an overlay UI||GUI plugin||Support for overlays and docked widgets|
|GUI / System||Change the default UI||GUI plugin / SDF||All GUI elements can be removed or configured through SDF|
|System||Access command line arguments||TBD||-|
Another key difference is that systems will be able to access all entity properties at once, despite the entity type. So while in Gazebo you may need 3 different plugins to interact with physics, rendering and sensors, on Ignition you could, for example, set a camera's visual color, its velocity and frame rate, all from a single plugin.
Let's take a look at a typical Gazebo plugin which accesses a property from an entity and does something with it. In this case, it will print the current pose of a link.
In general, the plugin will need to:
- Get the link and store it.
- Register a callback that is called at every simulation update.
- At the callback, query the link's pose and print it.
On classic Gazebo, that would look something like this:
On Ignition Gazebo, that would be implemented as follows:
The example above uses headers like
Util.hh, which offer convenient APIs for some tasks that are common during simulation. However, the real power of the ECS architecture is the direct access to all entities and components. Let's take a look at how to do the same just using the ECM's API:
In summary, the key differences between classic and Igntion Gazebo are:
- Plugins must inherit from the
ISystemConfigureclass to be able to override the
Configurecallback that gives access to many things, such as the SDF pointer. This used to be done through the
- Plugins no longer need to manage connections to loop-related events. Instead, they implement an interface such as
- Plugins don't have direct access to physics objects such as
physics::Model. Instead, they can either deal directly with entities and their components by calling functions in the ECM, or use convenient objects such as
ignition::gazebo::Modelwhich wrap the ECM interface.
All these changes are meant to give plugin developers more flexibility to only use the features they need, and several layers of abstraction which can be chosen according to the developer's experience and specific use-case.