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

• 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

• 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

• 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 😁

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