Moving code from Python to C++: high-level overview

[diegoferigo]

Working at the gym-ignition level, our range of actions is sometimes limited. Before starting, it's worth refreshing that with step we refer to the physics step (i.e. 1 KHz), with run we refer to a configurable number of stepsPerRun executed in a single call (generally, 1). It's not always the case having the need, e.g. from Python, to run code at the physics rate, and it turns out that using stepsPerRun >> 1 and a sufficiently high physics rate is one of the keys for faster simulations without affecting accuracy. Most often, a high-level controller is running from Python, and it doesn't need to access the simulator with rates that high.

Remaining in the Python domain, there is a trade off. From one hand, using stepsPerRun=1 would potentially allow to do anything (including prototyping) that is doable with other solutions later discussed. From the other, it constrains the whole Python application to run at physics rate, when often is not necessary. This is clear for a whole-body controller. You may want to run it quite fast, and we're close to physics rate. Therefore, the entire application will run at the same rate.

Moving on, Ignition Gazebo has a remarkable propensity towards extensibility, and plugins can be developed and loaded during runtime providing callbacks injected in the simulator loop. Some information in migration_plugins.md. The correct terminology is that plugins provide System classes, and these classes have implemented callbacks. In order to move code from Python to C++, one could decide to develop their own plugin that can be loaded e.g. from the SDF or from our APIs (whether it's a model or world plugin). There are two ways:

1. Develop a plugin that can run in Ignition Gazebo standalone.
2. Develop a plugin that uses ScenarIO and its features and runs only in such environments.

In the first way, I would redirect to the official documentation. This should be the preferred way to develop plugins, so that all other users of the simulator can benefit from. I will follow up hereby with details about the second way.

The simplest example I can bring as a C++ plugin is ActuationDelay that simply takes any position reference before the physics step and puts them in a queue that simulates a delay in actuation. Plugins can live in an external repositories an being developed independently, as much as Python code. They can be also tested from Python, as in test_actuation_delay.py. A great starting point for structuring such repository is dic-iit/gazebo-scenario-plugins. Using ScenarIO was not strictly necessary in this case, but it was practical since the packaging toolchain handles the C++ compilation against the simulator and the external repository can be simply deployed by CI to PyPI.

Another, more complicated example, is our controllers stack. We developed a System called ControllerRunner that can execute controllers implemented with our interfaces. A practical example is ComputedTorqueFixedBase, used also in the Manipulation example. This, however, works only with controllers shipped within gym-ignition repository, and currently cannot load third-party controllers.