Splitting the toolbox?

[diegoferigo]

Disclaimer what you're going to read here below is just a random thought had in a very random moment.

TL;DR Let's detach from the current codebase a tool that streamlines the process of blocks creation with automating code generation support.

---

WB-Toolbox, considering also the undergoing work that will be released as 3.1 which will include automatic code generation support (#82), changed quite a lot in the past few months. The new polished BlockInformation interface is going to be exploited heavily, and I think we're getting really close to an API stability for what concern the 3.1's WBToolboxLibrary component.

In the past the toolbox has always been strictly bonded with YARP, iDynTree, and iCub. The 2.0 release represented a big step towards classes, interfaces, and their abstraction capabilities, with the great porting done by @francesco-romano. The 3.0 release polished further the code, with major refactoring of the Signal and Log classes. Block's child classes have been simplified, and the introduction of Configuration and RobotInterface allowed to slim down the ToolboxSingleton to the extent of having minor functionalities.

The new 3.1 release will bring a brand new logic for parsing parameters (#84), which is very flexible and generic. BlockInformation is now almost API-stable. The three components (the generic library containing algorithms, its implementation for Simulink, its implementation for generated and standalone C++) have been already separated and potentially ready to get split apart. Furthermore, the upcoming support of automatic code generation will provide a generic and dynamic process to generate C++ code that inlines our classes. These classes can be used to wrap any kind of algorithm and linked with any kind of library.

Probably my point is getting more clear now. I don't see major obstacles of splitting the core of the toolbox, which provides all this machinery for wrapping algorithms and automatically generate C++ code, from all the rest (our blocks, that means YARP, iDynTree, iCub).

This might be a key for getting the community behind this project to grow and getting more engaged. We discussed many times the support of ROS. Considering our focus, it might be a big effort for us, but maybe under these circumstances we could use some help from the community by providing all the required tools.

After the abandonment of the robotology/wholebodyinterface and robotology/yarp-wholebodyinterface, I can see here a big potential that can be exploited by the robotics community and beyond. Any feedback?

cc @francesco-romano @traversaro @gabrielenava @S-Dafarra @DanielePucci @pattacini

[pattacini]

@diegoferigo, fully agree on this 👍

Separating algorithms from plumbing (YARP and potentially ROS) has been always present in my view.

However, I tend to consider iDynTree as part of the algorithms and as such belonging to the core functionalities.

[diegoferigo]

@pattacini This is something different than what discussed some time ago about confining YARP as an external module. With the first draft of the 3.1 release it is already possible if you choose as target for code generation the blocks which only depend on iDynTree. But, it you count them, they are the minority (6 out of 20).

What I propose here is something even more generic. The component to be split would depend only on Matlab/Simulink and Eigen, and provides all the plumbing, to use your terminology, for exposing generic algorithms to Simulink and generating C++ code from them.

Considering we do not extensively use ROS at the current moment, the maintenance of such blocks for us would be demanding, I'd rather prefer to provide the possibility to allow doing it separately in another toolbox which will be based on the component I'd proposing to split. In this scenario, the combined usage of this new toolbox together with our, would provide a setup ROS plus iDynTree without any drastic new architecture design from our side.

[pattacini]

Then, I think it is convenient to discuss in person about the roadmap. This appears as a quite long-term development.

[traversaro]

+1 to discussing in person.
However, two preliminary points:

• Splitting the core while keeping everything in this repo, and enabling installation of the "core" part without YARP, etc, etc: I think this should not create any strange problem, if it does not take too much work.
• Splitting the core and the blocks in two different repositories: this is extremely risky until we get a bit of experience on the new architecture. What I fear is that the coupling is not so light as we think, and in the end we will need to have double PRs for most new features that we want to add. To give you an example, this is exactly why MoveIt! division in several repositories was eventually reverted, see https://discourse.ros.org/t/migration-to-one-github-repo-for-moveit/266 .

[diegoferigo]

Today I started the activity related to the split of the core components. Particularly, I am splitting the following CMake components:

• ToolboxCore
• ToolboxCoder
• ToolboxMex

This means that only WBToolboxLibrary will be left here.

For what concern dependencies, also the embedded shlibbpp and the target MxAnyType will be migrated outside, leaving here only ClockRpc.

What I fear is that the coupling is not so light as we think, and in the end we will need to have double PRs for most new features that we want to add.

From February this project had a new major release (v4) and the component are even better separated. Since the blocks classes that this repository will contain only use the interfaces from the core, I think we can avoid such problems. Of course every API break of the core part should be handled properly also from this side.

[diegoferigo]

Split finalized in #166