robotology / gym-ignition

Framework for developing OpenAI Gym robotics environments simulated with Ignition Gazebo

Home Page:https://robotology.github.io/gym-ignition

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Simplify logic to get the Entity Component Manager and Event Manager

diegoferigo opened this issue · comments

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.

Closed via #379.