Remove the dependecy of yarp from the walking-controllers libraries about walking-controllers HOT 9 CLOSED

Regarding the parameters, we could think about a separate class containing all the fields you need inside the controller. Then you can fill this struct in a different way depending on the application. In this way, the single components don't depend neither on yarp nor on libconfig, but the application that merges them all will.

from walking-controllers.

Probably, it is easier to have a F2F meeting for defining the desiderata @traversaro @S-Dafarra @prashanthr05

from walking-controllers.

Ideally, some blocks (e.g. RobotHelper) will depend on yarp. Other such that WalkingQPIK will be yarp-free

I totally agree, I just wanted to make sure that we properly separate the problems.

from walking-controllers.

Since we moved our effort into bipedal-locomotion-framework we can close this issue.

from walking-controllers.

Regarding parameters, a possible alternative approach (that could be made compatible with what proposed by @S-Dafarra) is to declare which parameters a blocksubmodule has, and just have a single function/class to load this parameters from a YARP .ini group/json file/yaml file or whatever format you prefer.
Example of this pattern:

• https://drake.mit.edu/doxygen_cxx/classdrake_1_1systems_1_1_parameters.html
• https://robotology.github.io/blockfactory/doxygen/classblockfactory_1_1core_1_1_parameter_metadata.html
• https://fmi-standard.org/docs/2.0.1-develop/#_getting_and_setting_variable_values

from walking-controllers.

the submodules of the walking (i.e. the inverse kinematics) should not depend upon yarp. This independence could be useful if someone wants to use our libraries in a yarp-free architecture. Currently, the main dependence of yarp are: the resource finder and the minJerkTraj.
For the former, we could use a standard library for loading parameters from configuration files — for instance libconfig which is compatible with Linux MacOs and Windows. For the latter, we could port the minJerkTraj into iDynTree.

Note that I would not mix the concern of "refactor walking-controllers as libraries" and "remove yarp dependencies". These are two important and useful improvements, but it is important to make clear that they do not depend too much on each other. Even if we move to something non-YARP for dealing with parameters (the biggest part that depend on YARP), I think it would make sense to still have ã few blocks submodules that depend on YARP, similarly to the situation in WB-Toolbox. Then the compilation for those blocks submodules can be disabled if necessary.

from walking-controllers.

Usually, people with ROS background develop their algorithms as stand-alone classes and then additionally create a ROS wrapper in order to do the configuration step.

Getting inspired also from the BlockFactory workflow and also ROS wrappers, I refactored the base estimators like this,
https://github.com/dic-iit/element_floating-base-estimation/issues/85#issue-493520220

Where, the Estimator API is basically the algorithms in a BlockFactory view. (configure, set input, get output and dynamic reconfigure (idea from ROS)).

The central block is the YARP wrapper, where I run the YARP device using a Periodic thread, that instantiates objects of classes RobotInterface and BaseEstimatorInterface. RobotInterface is a YARP bridge to get the measurements from the robot and BaseEstimatorInterface is basically the parameter bridge used to configure the Estimator algorithm from the Estimators API and run the algorithm by passing the measurements.

However, the Estimators API is completely a spin-off iDynTree library (sole dependency). SO, it would be worth identifying the core part of the walking-controller algorithm and thinning it into a separate interface-free API as first step.

Maybe this could be of some help

from walking-controllers.

@traversaro

Note that I would not mix the concern of "refactor walking-controllers as libraries" and "remove yarp dependencies". These are two important and useful improvements, but it is important to make clear that they do not depend too much on each other. Even if we move to something non-YARP for dealing with parameters (the biggest part that depend on YARP), I think it would make sense to still have ã few blocks submodules that depend on YARP, similarly to the situation in WB-Toolbox. Then the compilation for those blocks submodules can be disabled if necessary.

Ideally, some blocks (e.g. RobotHelper) will depend on yarp. Other such that WalkingQPIK will be yarp-free

from walking-controllers.

Probably, it is easier to have a F2F meeting for defining the desiderata @traversaro @S-Dafarra @prashanthr05

Great idea. As my availability is quite variable, feel free to do that without me. I would be happy to provide feedback directly on more issues and to the code.

from walking-controllers.