Bipedal-locomotion-framework: 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.

[traversaro]

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. We can also define a template file, from which we can automatically obtain a full configuration file for a specific robot.

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 .

[S-Dafarra]

Proposal

• [x] Add an IK interface

Description

This may be something similar walking-oriented with different backends, exploiting the several IK implementations we have around.

[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

• [x] Implement ~Common~ Conversions library containing common definitions and conversions

Description

This library will be a placeholder for common ~definitions like aliases/typedefs and~ conversion functions
manif2iDynTree/iDynTree2manif. (In progress).

[S-Dafarra]

Proposal

• [ ] Implement Common library containing common definitions and conversions

Description

This library will be a placeholder for common definitions like aliases/typedefs and conversion functions
manif2iDynTree/iDynTree2manif. (In progress).

This is a good point. I am having right now the same problem between Eigen/iDynTree/matioCpp

[prashanthr05]

Proposal

• [x] Implement ContactDetector

Description

This component will maintain a container of Contact Detection methods (example Schmitt Trigger, at the moment) for a prescribed number of contact frames and update the contact states using relevant measurements/inference techniques.

Remark

Contacts related components already exist in Planners. We need to decide where to put this feature.

[S-Dafarra]

Proposal

• [ ] Implement ContactHandler

Description

This component will maintain a container of Contact Detection methods (example Schmitt Trigger, at the moment) for a prescribed number of contact frames and update the contact states using relevant measurements/inference techniques.

Remark

Contacts related components already exist in Planners. We need to decide where to put this feature.

I am not sure handler is a good name in this case. In any case, I guess that the Contact library can be linked with no big issues.

[prashanthr05]

Proposal

• [ ] Implement ContactHandler

Description

This component will maintain a container of Contact Detection methods (example Schmitt Trigger, at the moment) for a prescribed number of contact frames and update the contact states using relevant measurements/inference techniques.

Remark

Contacts related components already exist in Planners. We need to decide where to put this feature.

I am not sure handler is a good name in this case. In any case, I guess that the Contact library can be linked with no big issues.

How about ContactSensor or ContactDetector?

[S-Dafarra]

How about ContactSensor or ContactDetector?

I like ContactSensor, as it can be substituted by an actual sensor, but also ContactDetctor is reasonable. Up to you then :grin:

[traversaro]

I would go for ContactDetector, as a sensor is something that provide the input values for ContactDector.

[S-Dafarra]

I would go for ContactDetector, as a sensor is something that provide the input values for ContactDector.

If that's decided, @prashanthr05 can you edit the proposal comment? In this way, we can hide these comments

[prashanthr05]

I would go for ContactDetector, as a sensor is something that provide the input values for ContactDector.

If that's decided, @prashanthr05 can you edit the proposal comment? In this way, we can hide these comments

Done, thanks!

[prashanthr05]

Proposal

• [x] Refactor Contacts out of Planners library

Description

Compilation of Planner depends on QHull and Casadi while Contacts only require manif. It would be helpful if we separated atleast the compilation of these two libraries.

[S-Dafarra]

Proposal

• [ ] Refactor Contacts out of Planners library

Description

Compilation of Planner depends on QHull and Casadi while Contacts only require manif. It would be helpful if we separated atleast the compilation of these two libraries.

This should require only a slight CMake refactory, basically setting https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L9-L15
out of the if
https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L5

[prashanthr05]

Proposal

• [ ] Refactor Contacts out of Planners library

Description

Compilation of Planner depends on QHull and Casadi while Contacts only require manif. It would be helpful if we separated atleast the compilation of these two libraries.

This should require only a slight CMake refactory, basically setting

https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L9-L15

out of the if
https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L5

That's what I have done at the moment, shall I open a PR?

Additionally, I have added a compilation option depending on the availability of manif

[S-Dafarra]

Proposal

• [ ] Refactor Contacts out of Planners library

Description

Compilation of Planner depends on QHull and Casadi while Contacts only require manif. It would be helpful if we separated atleast the compilation of these two libraries.

This should require only a slight CMake refactory, basically setting
https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L9-L15

out of the if
https://github.com/dic-iit/bipedal-locomotion-framework/blob/67b78ab1f6942df37077c038f8c09242d2a09f46/src/Planners/CMakeLists.txt#L5

That's what I have done at the moment, shall I open a PR?

Additionally, I have added a compilation option depending on the availability of manif

Well, if you have it already, why not making it land soon then :grin:

[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.

[traversaro]

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.

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.

[prashanthr05]

Proposal

• [x] Add a generic ROSPublisher class to YarpUtilities using only YARP libraries similar to what is done in human-dynamics-estimation/Publishers

Description

This class will not contain a periodic thread structure, instead just function calls to publish joint states, wrenches, pose transforms (all within one class) over ROS topics through yarp::os::Publisher. This will be useful for online visualization using RViz. An example function call in the API would be,

bool publishJointStates(const BipedalLocomotion::GenericContainer::Vector<std::string>& jointList,
                                      const BipedalLocomotion::GenericContainer::Vector<double>& jointPositions);

[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()

[S-Dafarra]

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()

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]

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)

That's true the problem is that the parameter handler does not know if a parameter is optional or mandatory (and in my opinion, it shouldn't know it).

For instance, if the yarp implementation of parameter handler is used the following error is printed in case of missing field
https://github.com/dic-iit/bipedal-locomotion-framework/blob/2d14797c257a8e8a7e41df50816558f3fa8972dc/src/YarpUtilities/include/BipedalLocomotion/YarpUtilities/Helper.tpp#L71-L77

Here we may try to avoid printing but just propagating the string containing the error
```
if (!config.check(key, value))
{
Outcome out;
out.log = "[BipedalLocomotion::YarpUtilities::getElementFromSearchable] "
"Missing field named ";
out.isError = true;
return out;
}
````
In this case, the consumer class can avoid printing the error if it's not important

[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 https://github.com/dic-iit/bipedal-locomotion-framework/issues/137#issuecomment-724610989

[S-Dafarra]

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)

Indeed, I agree :grin: 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.