Open traversaro opened 4 years ago
cc @robotology/iit-dynamic-interaction-control
Thanks @traversaro for proposing this intermediate step, it's the first real step towards the goal we always discuss of having a simulator instance directly running within the Matlab process.
The interfacing with YARP APIs is definitely a big task and I agree that passing through an implementation middleware-agnostic is the best solution. For whom will be assigned to this task, I add below some ideas of how this could be done. I am thinking of a new repository that provides:
I think this is feasible without a huge effort.
Some details:
I am interested in supervising the activity and provide guidance both from the Blockfactory and ScenarI/O sides (note to myself, I should finalize the exporting of the ScenarI/O CMake targets).
When this is done, as second stage, we can start thinking how to integrate it with our YARP-based infrastructure and merge (or copy) it to this repo. This is more complicated in my opinion and it would require also porting few plugins from gazebo-yarp-plugins (and few of them are quite complex). Depending on the first application we have in mind, we should also think if we need any YARP device running (and I'm thinking of wbd and similar, that are not compatible yet with Ignition Gazebo).
At least initially, I was thinking about just supporting a single model (that should cover ~90% of use cases, sorry @lrapetti for being the 10% : D ) that simplifies the implementation without using the singleton and having three different blocks for using what is a single discrete time system.
Ok it looks good to me as first prototype, even simpler then.
Though we should keep in mind that following this approach would require a more complex logic of input and output ports. Just supporting as inputs position and torques (and maybe initial configuration) and as outputs joint and base position and velocities, would require a non-trivial signal handling.
However, in the first development stage it's good enough.
Why position should be an input? Ok, got it, in the sense of setpoint of the joint position control.
Yes, I meant if you want to use something different than torque control.
At least initially, I was thinking about just supporting a single model (that should cover ~90% of use cases, sorry @lrapetti for being the 10% : D )
I think iRonCub adds some 10% to the percentage :) :(
At least initially, I was thinking about just supporting a single model (that should cover ~90% of use cases, sorry @lrapetti for being the 10% : D )
I think iRonCub adds some 10% to the percentage :) :(
In which sense? I think iRonCub is using a single model, no?
At least initially, I was thinking about just supporting a single model (that should cover ~90% of use cases, sorry @lrapetti for being the 10% : D )
I think iRonCub adds some 10% to the percentage :) :(
In which sense? I think iRonCub is using a single model, no?
From your comment I understood the development was aimed only at supporting iCubGazebo_V2_5
, which isn't used in ironCub - but sorry if I'm understanding fischi per fiaschi
At least initially, I was thinking about just supporting a single model (that should cover ~90% of use cases, sorry @lrapetti for being the 10% : D )
I think iRonCub adds some 10% to the percentage :) :(
In which sense? I think iRonCub is using a single model, no?
From your comment I understood the development was aimed only at supporting
iCubGazebo_V2_5
, which isn't used in ironCub - but sorry if I'm understanding fischi per fiaschi
Sorry, no: I meant that 90% of our use cases is that we just simulate one single model, not two models as for example done @lrapetti in robot-robot collaboration.
Summary
This issue track the implementation of a Gazebo/Ignition Gazebo simulation embedded in a WB-Toolbox block, taking inputs (low level joint control loops setpoints, etc, etc) and providing outputs (position, velocity of the robot, etc etc) using standard Simulink vector-based ports.
Motivation
To avoid the overhead and the non-determinism that affects most of the approaches related to interfacing Simulink-based simulation with Gazebo using network communication.
Additional context
This is similar to https://github.com/robotology/wb-toolbox/issues/164, but without the aspect of interfacing with the simulated model via standard YARP C++ device interfaces. This has the downside that the existing WB-Toolbox blocks can't be used as they are, but it probably is simpler to implement and it can permit to use Ignition Gazebo even before https://github.com/robotology/gazebo-yarp-plugins/issues/395 is solved.
Implementing such a block can probably be useful to rely on the ScenarI/O APIs on the top of Ignition Gazebo, developed in the gym-ignition repo, see https://github.com/robotology/gym-ignition/tree/devel/cpp/scenario .
This issue has been opened in this repo, but in may be possible that the block is eventually implemented in a different repo, I just opened here to have a reference point to discuss this.