In issue #95 I proposed a new way to communicate with Ignition Gazebo. The current architecture of the bindings (mainly GazeboWrapper and IgnitionRobot classes) have been developed over time after many attempts to find a working solution. Though, they are not optimal and now that we have a deeper knowledge of the Ignition Gazebo architecture maybe we can do better.
In the past few days I prototyped new classes inspired by upstream resources such as ignition::gazebo::Model. I like the initial result, and I would like to move this idea forward.
This task is not trivial. However, is mainly a copy-and-paste of existing code, in other words, a refactoring. Here below a recap of the planned activities:
[x] Use the gympp namespace only for the C++ implementation of OpenAI Gym. This was the earliest attempt of our activities, and then we shifted the focus more towards Python. Though, I don't feel like to delete those files yet. All those resources should go in a separated folder. #157
[x] Design and implement the new bindings (with the long term plan to convert them to interfaces). #158
[x] Move the current plugins to the cpp folder and update them to work with the new Scenario APIs. #161
[x] Refactor GazeboWrapper. #163
[x] Split gympp and scenario bindings. #165
[x] Rethink how to insert C++ controller in a simulation. Likely Python agents run slower than the simulator, and the only way to decouple the controller (PID, computed torque, etc) is to make them standalone Systems. #167
[x] Add new fixed-base computed torque controller. #167
[x] Remove the C++ gympp::Robot interface and IgnitionRobot class and update GazeboRuntime to use the new bindings. #176
[x] Reach feature parity
cc @traversaro @paolo-viceconte @raffaello-camoriano
diegoferigo
commented
4 years ago
In issue #95 I proposed a new way to communicate with Ignition Gazebo. The current architecture of the bindings (mainly
GazeboWrapperandIgnitionRobotclasses) have been developed over time after many attempts to find a working solution. Though, they are not optimal and now that we have a deeper knowledge of the Ignition Gazebo architecture maybe we can do better.In the past few days I prototyped new classes inspired by upstream resources such as
ignition::gazebo::Model. I like the initial result, and I would like to move this idea forward.This task is not trivial. However, is mainly a copy-and-paste of existing code, in other words, a refactoring. Here below a recap of the planned activities:
gymppnamespace only for the C++ implementation of OpenAI Gym. This was the earliest attempt of our activities, and then we shifted the focus more towards Python. Though, I don't feel like to delete those files yet. All those resources should go in a separated folder. #157GazeboWrapper. #163gympp::Robotinterface andIgnitionRobotclass and updateGazeboRuntimeto use the new bindings. #176cc @traversaro @paolo-viceconte @raffaello-camoriano