robotology / gym-ignition

Framework for developing OpenAI Gym robotics environments simulated with Ignition Gazebo
https://robotology.github.io/gym-ignition
GNU Lesser General Public License v3.0
220 stars 26 forks source link

Develop YarpRobot: the YARP backend of a gym-ignition robot #134

Open diegoferigo opened 4 years ago

diegoferigo commented 4 years ago

The gym-ignition framework has as one of its main aims the possibility to run its environments transparently on both simulated and real-world robots. Our laboratory owns a iCub humanoid based on the YARP middleware.

Executing a decision-making task on the real robot means that we need to develop a new class to interface with Yarp-based robots. This implementation will be the third one, after IgnitionRobot ~and PyBulletRobot~ (removed since it will be replaced soon by the bullet ign-physics plugin).

Since the robot interfaces we currently support are a lot, we have to implement them step by step. Few of them have higher priority, like robot joints and links.

The YARP implementation can be augmented with iDynTree, if needed.


We have two ways to do it:

  1. Exploiting the YARP Python bindings
  2. Developing a new C++ implementation of gympp::Robot and bind it to Python

I would rather go towards 2 since in this way most of the Python code developed for IgnitionRobot could be reused.

diegoferigo commented 4 years ago

In the past 6 months, many things changed in our architecture:

I'm currently drafting a new implementation of ScenarI/O for the YARP middleware, together with a new real-time runtime #94. The aim is to play a policy on a real robot without the need to rewrite the entire Python environment. On the long run, implementing more and more methods of the interfaces, we could also fine-tune the policy by collecting experience from the real robot with minimal effort.

Since our robot stack is network-transparent, and we still have it fully functional for Gazebo Classic, I could prototype the YARP backend quite easily in simulation. The assumption is that I am ignoring that the real-time factor could not be 1. When everything we need will work with iCub simulated in Gazebo Classic, since we communicate through the network, everything in theory could be executed also on the real robot (assuming that the policy is robust enough).

In any case, I will start with simple Python scripts (these should not be affected by the reality gap) and then progressively transition towards more complex scenarios. Here below a simple demo:

out

cc @traversaro @DanielePucci @paolo-viceconte @raffaello-camoriano