You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Ignition Gazebo, the Server class contains one or multiple SimulationRunner objects (in most cases, just one), each simulating an independent world. The data storage of each SimulationRunner is implemented in a Entity Component System.
Historically, the ECS has always been hidden from the user (gazebosim/gz-sim#248). Though, the entire Gazebo ScenarIO logic is based on the fact that we can access and alter this data storage. Until now, we had to rely on a kind of dirty workaround: a plugin that implements only the ECMProvider::Configure callback that gets the pointer to the ECM (and the event manager) and stores it in a singleton. Then, within the same process, the singleton could be used to get these pointers and consume them.
It's easy to see that the combination of plugins + singletons + python could create problems. In fact, we struggled with some hairy issues in the past (see a recap in #354 that, even if not specific to this, is highly related).
Luckily, the new upstream gazebosim/gz-sim#936 allows us to gather the ECM without the need of using the plugin + singleton 🎉 If I understood, the ECMProvider class of the plugin can be allocated together with the Server (e.g. in the GazeboSimulator class) and its system directly added. Then, the ECM and event manager can be gathered from the ECMProvider object with new getters, and stored, if needed, in our GazeboSimulator class.
Likely this solves for good the need to alter the dlopen flags as described in #7 (very old issue!). Though, if it does not harm anyone, I'd leave this workaround there in any case.
The text was updated successfully, but these errors were encountered:
In Ignition Gazebo, the
Server
class contains one or multipleSimulationRunner
objects (in most cases, just one), each simulating an independent world. The data storage of eachSimulationRunner
is implemented in a Entity Component System.Historically, the ECS has always been hidden from the user (gazebosim/gz-sim#248). Though, the entire Gazebo ScenarIO logic is based on the fact that we can access and alter this data storage. Until now, we had to rely on a kind of dirty workaround: a plugin that implements only the
ECMProvider::Configure
callback that gets the pointer to the ECM (and the event manager) and stores it in a singleton. Then, within the same process, the singleton could be used to get these pointers and consume them.It's easy to see that the combination of plugins + singletons + python could create problems. In fact, we struggled with some hairy issues in the past (see a recap in #354 that, even if not specific to this, is highly related).
Luckily, the new upstream gazebosim/gz-sim#936 allows us to gather the ECM without the need of using the plugin + singleton 🎉 If I understood, the
ECMProvider
class of the plugin can be allocated together with theServer
(e.g. in theGazeboSimulator
class) and its system directly added. Then, the ECM and event manager can be gathered from theECMProvider
object with new getters, and stored, if needed, in ourGazeboSimulator
class.Likely this solves for good the need to alter the dlopen flags as described in #7 (very old issue!). Though, if it does not harm anyone, I'd leave this workaround there in any case.
The text was updated successfully, but these errors were encountered: