Open diegoferigo opened 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:
cc @traversaro @DanielePucci @paolo-viceconte @raffaello-camoriano
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
~andPyBulletRobot
~ (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:
gympp::Robot
and bind it to PythonI would rather go towards 2 since in this way most of the Python code developed for
IgnitionRobot
could be reused.