-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Splitting the toolbox? #96
Comments
@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 |
@pattacini This is something different than what discussed some time ago about confining YARP as an external module. With the first draft of the What I propose here is something even more generic. The component to be split would depend only on 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 |
Then, I think it is convenient to discuss in person about the roadmap. This appears as a quite long-term development. |
+1 to discussing in person.
|
In preparation of the split of the core robotology#96
Today I started the activity related to the split of the core components. Particularly, I am splitting the following CMake components:
This means that only For what concern dependencies, also the embedded
From February this project had a new major release ( |
Split finalized in #166 |
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 as3.1
which will include automatic code generation support (#82), changed quite a lot in the past few months. The new polishedBlockInformation
interface is going to be exploited heavily, and I think we're getting really close to an API stability for what concern the3.1
'sWBToolboxLibrary
component.In the past the toolbox has always been strictly bonded with
YARP
,iDynTree
, andiCub
. The2.0
release represented a big step towards classes, interfaces, and their abstraction capabilities, with the great porting done by @francesco-romano. The3.0
release polished further the code, with major refactoring of theSignal
andLog
classes.Block
's child classes have been simplified, and the introduction ofConfiguration
andRobotInterface
allowed to slim down theToolboxSingleton
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
androbotology/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
The text was updated successfully, but these errors were encountered: