Improve Blockfactory interface with wrapped C++ code making it more generic

[nunoguedelha]

This epic will track the steps that aim at improving the Blockfactory interface with the wrapped C++ code. This goal was motivated by the drawbacks of using the Blockfactory for generating blocks that can be called from other imperative languages, among which we find the following:

• You need to write for each block some simulink related code (XML files). These files could eventually be generated automatically (Automatically generate required Simulink library files #10).
• This interface with the wrapped C++ code is currently very Simulink centric, inheriting from its constraints. For instance, setting the inputs is done through an opaque BlockInformation, instead of a setInputs function. You need to define the specific BlockInformation for each block.

A new improved interface could be defined for future block implementations, while a glue code could be created for migrating the existing blocks from the new interface to the new one. Simulnik has its own interface for blocks, implemented through the S-function block. The abstraction to a more generic C++ interface is then made at the Blockfactory framework level. A possible evolution of the Blockfactory interface could result in the creation of a new S-fucntion implementing that new C++ API.

This work has to account for the Simulink requirements, among which we have:

• There are specific initialization phases of the S-function block, defined through callback functions called in specific sequence.
• Some of these specific phases are dedicated to the definition of parameters to be passed to the wrapped C++ function, number and size of input/output ports.
• Signal sizes can be defined as dynamic (variable) or fixed if they are known a priori.
• The callback mdlOutputs calls the wrapped C++ code and maps its output to the block output. When the block processing sequence reaches that callback, Simulink already knows the signal dimensions according to the flow and allocates the required buffers.

In order to reach the goal of improving the Blockfactory interface with the wrapped C++ code, we should define an MVP (Minimum Viable Product) and iterate on it, for the sake of having a more trackable and incremental task.

The task breakown would be as follows:

• Go through the Blockfactory tutorial in order to get acquainted with its workflow, including the steps to create a new library, and eventually the how the Blockfactory API is mapped to the S-Function interface in Simulink.
• Start with an existing block as a first application example (for instance example/include/SignalMath.h).
• Identify possible improvements to the Blockfactory API.

One of the points to be addressed in this last step would be the choice between having an interface that takes multiple parameters and different inputs, or instead, an interface that uses a single input argument and a single output argument with all the buffers, as it is currently implemented.

[nunoguedelha]

CC @DanielePucci @GiulioRomualdi @nunoguedelha @prashanthr05 @traversaro @diegoferigo @lrapetti @kouroshD @Giulero @S-Dafarra

[traversaro]

From the point of view of the C++ user, some example of "blocks" interfaces from which we can take inspiration are:

• FMI4cpp : https://github.com/NTNU-IHB/FMI4cpp#api
• Drake : https://github.com/RobotLocomotion/drake/blob/v0.24.0/examples/simple_discrete_time_system.cc

[nunoguedelha]

Other interesting information shared by @diegoferigo :

• Distinction between the actor processing the data / entity handling the memory allocation: https://journals.sagepub.com/doi/10.1177/1729881420921625

[nunoguedelha]

Just to clarify, my next step, after having completed the tutorial and looked into https://github.com/robotology/blockfactory/blob/master/example/include/SignalMath.h, would be to implement the OSQP block, if you guys still agree on that. This means that http://github.com/robotology/wb-toolbox/issues/180 would be reassigned to me.

@traversaro @diegoferigo @CarlottaSartore

[nunoguedelha]

I could start working on this after the 3rd March.