List of possible additions/improvements to the framework

[S-Dafarra]

We can use this issue as a possible desideratum of things to be added or changed in the Framework. This may help to give a direction to the development, and also provide a direction to other developers that want to contribute.

I would like to have a sort of voting mechanism, like a "User Voice" in order to prioritize one activity with respect to another in case there are no other priorities. Hence, each proposal should be in a separate message. In order to separate proposals from common messages, I suggest the following layout

Proposal:

• proposal name

Description

Short description

cc @GiulioRomualdi @traversaro @prashanthr05 @diegoferigo @DanielePucci

[S-Dafarra]

Proposal:

• Automatic configuration of a PolyDriverList

Description

The yarp implementation of the RobotInterface classes need a PolyDriverList as input. We can define a class that automatically configures it given a configuration file. This file may have the driver name as the name of the group, and inside all the parameters to configure the driver. Multiple groups will configure multiple drivers. We can also define a template file, from which we can automatically obtain a full configuration file for a specific robot.

[GiulioRomualdi]

@traversaro wrote

I may be wrong, but part of this functionality is already available in the yarp::robotinterface::experimental::XMLReader::getRobotFromFile method, see for example:
https://github.com/robotology/yarp/blob/97c737ca7b34ea762c9608f92964544787378511/tests/libYARP_robotinterface/RobotinterfaceTest.cpp#L262 .

[GiulioRomualdi]

The implementation of the IK can be found in https://github.com/dic-iit/bipedal-locomotion-framework/tree/master/src/IK

[S-Dafarra]

Proposal

• Unify plotting

Description

Recently @GiulioRomualdi developed an application that uses python in order to plot. It would be nice to exploit libraries like https://github.com/alandefreitas/matplotplusplus. It would be cool to start using also Ignition Gazebo as a visualizer.

[S-Dafarra]

Proposal

• Unify logging

Description

Use https://github.com/dic-iit/matio-cpp when it is necessary to log data, eventually creating an interface if needed.

[S-Dafarra]

Proposal

• Implement a contact sampler

Description

Like for https://github.com/robotology/unicycle-footstep-planner, it would be nice to have a class or more that are able to generate footsteps given some input data.

[prashanthr05]

Proposal

• Make model related computations in the algorithms not depend on iDynTree. (In the sense, currently we use iDynTree, but this feature should allow us to plug also some other library in place of iDynTree for Model computations)

Description

In FloatingBaseEstimators library we have a nested class ModelComputations that specifically refactors out iDynTree relevant kindyn/model computations from the actual estimation algorithm. The idea would be to refactor this ModelComputations class into a separate common library which can be called by any other library. This way, in case in the future, we want to handle Pinnochio related model computations, we can try to make this library an interface to handle such a switch.

[GiulioRomualdi]

@traversaro wrote:

In general, I would not try to abstract the interface before having in practice a second backend, because doing otherwise typically results in an interface that is just a simple copy of the underlying interface, with no additional benefit, and that will require modifications once a second backend is actually added. Once we have a new backend (for example based on https://github.com/dic-iit/idynfor) it totally make sense to have this abstraction.

[S-Dafarra]

Proposal:

• Add a GenericContainer::Matrix exploiting iDynTree::MatrixView and add the possibility to get a matrix from a configuration file

Description

Right now we are able to parse vectors from conf file, but not matrices. The reason may be that there is not a dual of GenericContainer::Vector for matrices and, as it was for vectors, it is not possible to know if the input matrix is resizable or not.

[GiulioRomualdi]

Proposal

• Add a common way to handle errors.

Description

Right now if the errors are handled by returning false and printing errors in the terminal with cerr. This is sometimes annoying since there is no differences between errors that are fatal and common errors. For instance, while configuring a class it may happen that one of the optional parameters is not found. In this case, it would be nice to avoid printing errors.
Furthermore, we may use some classes in a yarp module. There it would be nice to print errors with yError()

[GiulioRomualdi]

@S-Dafarra wrote

I would separate the handling of optional parameters from the way of printing errors. (In principle, if a parameter is optional and not found, it should not print any error at all)

[GiulioRomualdi]

Related Issue #120 and PR: #330

[GiulioRomualdi]

Proposal

• Implement a simple telemetry system inside blf

Description

Thanks to @S-Dafarra now we may think to use matio-cpp inside our infrastructure. I was thinking to add a virtual method in the Advanceable class called log() (the name can be changed ;) ) This method may take as input a matio-cpp object to store the data.

bool Advanceable::log(matiocpp& logger);
............

class Foo::Advanceable
{
Eigen::Vector x;

    bool log(matiocpp& logger)
    {
       logger.store(x);
       return; 
    }
}

Then from the main application (Foo1, Foo2 and Foo3 inherit from Advanceable)

Foo1 a;
Foo2 b; 
Foo3 c;
...
a.log(logger);
b.log(logger);
b.log(logger);

I don't know if this is actually possible with the current implementation of matiocpp

I just realized that it's a duplicate of #137 (comment)

[GiulioRomualdi]

@S-Dafarra wrote

Indeed, I agree 😁 In any case, I would wait a little bit more for this as we may actually get this feature soonish: https://github.com/robotology-playground/yarp-telemetry.