Bind the EntityComponentManager

[diegoferigo]

This issue is mostly a placeholder / reminder for this approach that might be considered in the future.

At the moment we are able to operate on the ECM from everywhere because we have a plugin that stores the pointer to the ECM in a singleton. Thanks to our single-process architecture, we can access the singleton throughout the program.

In particular, the class that provides the C++ Robot interface (IgnitionRobot) uses this resource to set and get the components handled in the ECM.

I realized that complete bindings to Ignition Gazebo could take this idea and extend it to all the components, not only those specific to the robot. However, since the API of the EntityComponentManager class are not very Python-friendly, creating helper classes that abstract the access to entities and component seems convenient. It is an approach that is already used upstream, for instance Model.hh. Though, the upstream helpers provide only limited functionality for our scope, we could think to create more complete ECM wrappers and expose them directly to Python.

Together with the GazeboWrapper class, these new ECM wrappers would provide a complete set of APIs to expose the simulator to other languages. Given that the ECM is the main entrypoint to simulated data, this is for sure the most generic approach we could find. In order to use it from other project (even C++), we should export properly this component as standalone. I would not like to split this component to another repo for maintainability discomfort.

I read upstream (cannot find where) that there's the idea to return the pointer to the ECM directly from the Server object. If it will be implemented, we can remove the need to use a dedicated plugin to gather its address.

cc @traversaro

[diegoferigo]

Since this is quite a big task that requires a careful thinking of the exposed API (since they will be the main user entrypoint), I don't think we should aim to get it included in the upcoming v1. We still have other priorities, though it's worth discussing this polishing since it would provide a generic interface to the simulator that can be exploited also from other projects within our organization.

[diegoferigo]

I also think that this approach, together with our new vendored Physics system and few new components that we might add in the future, would simplify the implementation of features as domain randomization #41.

[traversaro]

Together with the GazeboWrapper class, these new ECM wrappers would provide a complete set of APIs to expose the simulator to other languages. Given that the ECM is the main entrypoint to simulated data, this is for sure the most generic approach we could find. In order to use it from other project (even C++), we should export properly this component as standalone. I would not like to split this component to another repo for maintainability discomfort.

I totally agree.

[diegoferigo]

New bindings implemented in #158 🎉 They will reach the nightly channel in few weeks.