Open nunoguedelha opened 3 years ago
CC @DanielePucci @GiulioRomualdi @nunoguedelha @prashanthr05 @traversaro @diegoferigo @lrapetti @kouroshD @Giulero @S-Dafarra
From the point of view of the C++ user, some example of "blocks" interfaces from which we can take inspiration are:
Other interesting information shared by @diegoferigo :
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
I could start working on this after the 3rd March.
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:
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:
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:
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.