Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multithread support #15

Merged
merged 11 commits into from
Apr 17, 2019
Merged

Multithread support #15

merged 11 commits into from
Apr 17, 2019

Conversation

diegoferigo
Copy link
Member

@diegoferigo diegoferigo commented Apr 16, 2019

This PR adds multithread support to gym-ignition. It required few changes in the architecture, mainly related on how singletons were holding objects related to simulated models.

  1. If more simulations are running in parallel (by creating multiple IgnitionEnvironmenet objects), it means that there are in parallel multiple worlds containing the same sdf model. Before objects in the singleton were stored using the plain model name, instead, now, the names are scoped as <counter>::<modelname>.
  2. Previously, considering a single simulation, two plugins were running in a single world: the one that provides data to the agent (e.g. CartPole), and the one to exposes the robot state wrapping the ECM. This has been simplified. The class that implemented the second (robot state) is not anymore a plugin, it is a regular class. Gympp plugins (e.g. CartPole) that need to access the state of a robot will allocate in their Configure step such object. Therefore, the RobotSingleton is not anymore used to get gympp::Robot pointers, though it will be useful to expose the robot state to other entities (e.g. the python interpreter). This will be implemented in another PR.
  3. As a partial consequence of the previous points, robot and world have been separated. Both are sdf files, but the latter does not include anymore the former. IgnitionEnvironment reads both files and merges the two. This process has few advantages:
    • The world sdf file can be the same for all models (if there are no particular need of a structured world)
    • The model sdf file is generic, and has no information about the gympp plugin that operates on it. This means that also multiple plugins can act on the same model (<plugin> elements are added directly in C++). Therefore, experiments can share the same sdf file.
    • It removes the need to specify the models contained in the sdf file. This was required to give ign-gazebo the information to attach the gympp plugin to the right element. Now, since the model sdf is parsed, the model name is automatically retrieved.

In order to test the multiprocess simulation I created a C++ example LaunchParallelCartPole.cpp. Here below a teaser:

Screenshot_20190417_090140

Partially fixes #12, because this works well in C++ but unfortunately not from Python. In fact, python has this (horrible) "feature" called Global Interpreter Lock that prevents real multithreading (or well, MT is non effective for non-I/O intensive tasks as this one). For the time being this PR only targets C++, I'm going to experiment solutions in python that exploit multiprocess and IPC rather that multithreading.

This singleton collects the callbacks used for all the agents. It is the first step toward the support of multiple agents (each of them associated to one of these callbacks) acting on independent environments.
Ignition plugins that need a gympp::Robot pointer will contain an IgnitionRobot object and they configure it with their sdf configuration.
The callbacks are registered by the plugins during their Configure step.

Temporarily, the declaration of the gympp plugin is done in the sdf. As soon as robot and environment will be split, IgnitionEnvironment will handle that again.
Now setupGazeboWorld has to ben called before setupIgnitionPlugin
This commit:

- Get the EnvironmentCallbacks pointer from the singleton. Plugins autoregister themselves during their Configure step.
- Split robot and world. They are stored in two different files and not anymore merged by sdformat. This allows parsing the model sdf and automatically get the models. The plugin is then attached to the model element, and this permits to the plugin to correctly initialize the gympp::Robot object.
- The plugin is loaded again from cpp instead of sdf.
- The pose of the model will be handled in another PR.
@diegoferigo
Copy link
Member Author

I updated the description of the PR, now it should be more clear.

@diegoferigo diegoferigo merged commit ab841a3 into master Apr 17, 2019
@diegoferigo diegoferigo deleted the feature/multithread branch April 17, 2019 08:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow multiple parallel simulations
2 participants