Support Gazebo/Ignition Gazebo simulation embedded in the WB-Toolbox block, taking input over standard Simulink input/output ports

[traversaro]

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 #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 robotology/gazebo-yarp-plugins#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.

[traversaro]

cc @robotology/iit-dynamic-interaction-control

[diegoferigo]

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:

1. A Gazebo block that allows to setup the simulator (physics rate, model file, etc) and issues the step command
2. A block that can feed references to a named model
3. A block that can extract data from a named mode

I think this is feasible without a huge effort.

Some details:

• The Ignition Gazebo instance could be stored in a singleton, similarly to the YARP interfaces and iDynTree KinDynComputations, and expose a pointer to the simulated world
• The read / write blocks can access the world, extract a model, and operate on it

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).

[traversaro]

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.

[diegoferigo]

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.

[traversaro]

Why position should be an input? Ok, got it, in the sense of setpoint of the joint position control.

[diegoferigo]

Yes, I meant if you want to use something different than torque control.

[bemilio]

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 :) :(

[traversaro]

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?

[bemilio]

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

[traversaro]

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.