Contents

The Platform

The platform is a 2D hopper. The design of the robot was chosen to satisfy the following design requirements. A ideal platform must

  1. Be a relatively simple, inexpensive and easily reproducible setup.

  2. Poses a well-defined, but non-trivial control problem.

  3. have precedent in research (Raibert hopper 1, etc).

For a more comprehensive description of the design decisions taken during the creation of this platform please visit here.

OpenSim2Real provides these features in an end-to-end sim2real platform with the following features:

  1. Physical and Simulated robot.

  2. Abstracted interface between real and simulation.

  3. Gym reinforcement-learning framework for simulation and reality.

  4. Software drivers for interfacing with physical robot.

  5. Build system for physical robot back-end.

  6. Comprehensive documentation for researchers to replicate the platform.

System Level Diagram

../../_images/system_level_diagram.png

System-level diagram, illustrates the flow of information through different software components and between environment (Real or Simulated) and model. All the packages built by our team are highlighted in blue.

What’s our Real

The hardware platform is a single-legged robot called a Monopod. The physical robot was adapted from the open source robotic leg from the Open Dynamic Robot Initiative (ORDI) 2. The Monopod is a single-legged torque controlled robot system. It consists of two high-torque brushless DC motors and low-gear-ratio transmission suitable for impedance and force control. The Monopod is attached to a planarizer, a 2-meter long boom grounded at a 2-axis gimbal, in order to simulate infinite planar motion using 2D rotational movement with a large radius of rotation.

../../_images/monopod.png

A representation of the planarized monopod with a sketch of an arbitrary gait.

The observation space of the Monopod consists of 8-10 dimensions of position and velocity encodings. To learn more about the choice of robotic platform, and why this design was chosen, please visit here.

What’s our Sim

Note

This subsection was taken from the gym-iginition webpage. The reasoning for our use of gym-ignition parallel the reasons presented by gym-ignition 3.

In this section we want to go a bit deeper in the motivations that led us to select Ignition Gazebo as target solution for the simulation back-end of ScenarIO.

To begin, a bit of history. The Gazebo simulator that the entire robotic community has used for over a decade is different than Ignition Gazebo. We will refer to the old simulator as Gazebo Classic. Ignition Gazebo is the new generation of the simulator. It takes all the lesson learned by the development of Gazebo Classic and provides a more modular and extensible framework for robotic simulations. The monolithic structure of Gazebo Classic has been broken in standalone libraries, obtaining a suite called Ignition. Ignition Gazebo is just one of the libraries * that compose the suite. When we started the development of gym-ignition, Ignition Gazebo was “stable” enough to start using it. The clear advantage is support: Gazebo Classic will just receive bug fixing, all the development effort now shifted towards the new Ignition Gazebo. The price to pay, instead, is that Ignition Gazebo has not yet reached feature parity with Gazebo Classic, even though the gap is getting filled quickly.

*

Yes, you read correctly: library. Ignition Gazebo is a library. A ignition::gazebo::Server object can be instantiated and it can be stepped programmatically from your code. This type of architecture became quite popular recently because it gives you full control of the simulation. Ignition Gazebo, therefore, became a solution similar to the well known alternatives like pybullet and mujoco-py.

We have been and currently are Gazebo Classic users, as many other robotics research labs. Over time, we became familiar with the tools and methods of Gazebo Classic and built a lot of code and applications that depend on it. Unfortunately, despite someone has shown attempts, Gazebo Classic is not suitable for the large-scale simulations that are typical in modern reinforcement learning architectures. Ignition Gazebo offered us a viable solution for this use case that allows us to exploit the know-how we gained with Gazebo Classic.

The two main features that drove us towards the adoption of Ignition Gazebo are the following:

  1. Physics engines are loaded as plugin libraries and Ignition Gazebo operates on an API-stable interface. This architecture allows everyone to implement a new physics engine backend and run simulations exploiting all the other components of the Ignition suite (rendering, systems, …). While today only DART is officially supported, we believe this is one of the best attempts to obtain in the long run a framework that allows to switch physics engines with minimal effort. For reinforcement learning research, it could bring domain randomization to the next level.

  2. Simulations can be stepped programmatically without relying on network transport, guaranteeing full reproducibility. Reproducible simulations are paramount whether you are prototyping a new robot controller or you are running large-scale simulations for robot learning. Most of the client-server architectures cannot guarantee reproducibility since asynchronous network transports could provide different results depending on the load of your system. An effective solution is using the simulator as a library and stepping it programmatically from your code. Gazebo ScenarIO provides APIs to perform these kind of simulations with Ignition Gazebo.

There are a bunch of other nice features we didn’t cover in this section. Not all of them are currently exposed to ScenarIO Gazebo, please open a feature request if you have any suggestion or, even better, fire up a pull request!

To summarize, these are the features that motivated us to choose Ignition Gazebo:

  • Simulator developed for robotics

  • Simulator-as-a-library structure

  • Abstraction of different physics engines and rendering engines

  • Modular software architecture

  • Powerful and constantly improving SDF model description

  • Well maintained, packaged, and widely tested

  • Large big database of objects to create worlds: Ignition Fuel

  • Long term vision and support

Note

Ignition Gazebo is the target simulator of the new DARPA Subterranean Challenge. Have a look to their simulation results to understand what you can expect from using Ignition Gazebo.

1

Marc H. Raibert, Jr H. Benjamin Brown, and Michael Chepponis. Experiments in balance with a 3d one-legged hopping machine. The International Journal of Robotics Research, 3(2):75–92, 1984. URL: https://doi.org/10.1177/027836498400300207, doi:10.1177/027836498400300207.

2

F. Grimminger, A. Meduri, M. Khadiv, J. Viereck, M. Wüthrich, M. Naveau, V. Berenz, S. Heim, F. Widmaier, T. Flayols, J. Fiene, A. Badri-Spröwitz, and L. Righetti. An open torque-controlled modular robot architecture for legged locomotion research. IEEE Robotics and Automation Letters, 5(2):3650–3657, 2020. doi:10.1109/LRA.2020.2976639.

3

Diego Ferigo, Silvio Traversaro, Giorgio Metta, and Daniele Pucci. Gym-ignition: reproducible robotic simulations for reinforcement learning. In 2020 IEEE/SICE International Symposium on System Integration (SII), volume, 885–890. 2020. doi:10.1109/SII46433.2020.9025951.

previous

Open Sim2Real

next

Project Roadmap