Multithread support #15
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
force-pushed
the
feature/multithread
branch
from
12ad30b
to
157fbef
Compare
traversaro
reviewed
Apr 16, 2019
traversaro
approved these changes
Apr 16, 2019
|
I updated the description of the PR, now it should be more clear. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
IgnitionEnvironmenetobjects), 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>.Configurestep such object. Therefore, theRobotSingletonis not anymore used to getgympp::Robotpointers, 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.IgnitionEnvironmentreads both files and merges the two. This process has few advantages:<plugin>elements are added directly in C++). Therefore, experiments can share the same sdf file.In order to test the multiprocess simulation I created a C++ example
LaunchParallelCartPole.cpp. Here below a teaser: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.