Bipedal-locomotion-framework: Find a way for passing parameters for testing the components

[GiulioRomualdi]

Thanks to https://github.com/dic-iit/bipedal-locomotion-controllers/pull/13 https://github.com/dic-iit/bipedal-locomotion-controllers/pull/18 https://github.com/dic-iit/bipedal-locomotion-controllers/pull/21 the parameter handler library can be used in the entire repository and not only.

In order to pass the information to a component, the parameter handler interface can be used, however when the test is implemented an implementation of the aforementioned interface has to be provided.

In Estimators component we are currently using yarp for passing the parameters through the configuration files. In my opinion, it's a pity to add the dependency on yarp only for testing a component. I remember that back in time @traversaro suggested a lightweight library for handling the parameters from configuration files (but I don't remember the name of the library).

What do you think? @traversaro @S-Dafarra

[GiulioRomualdi]

The library suggested by @traversaro is toml

Reading the toml documentation seems there are several parsers for C/C++

• C (@cktan) - https://github.com/cktan/tomlc99
• C++ (@marzer) - https://github.com/marzer/tomlplusplus
• C++ (@skystrife) - https://github.com/skystrife/cpptoml
• C++ (@ToruNiina) - https://github.com/ToruNiina/Boost.toml
• C++ (@ToruNiina) - https://github.com/ToruNiina/toml11

[traversaro]

The library suggested by @traversaro is toml

Exactly. The tricky part I guess are:

• Handling of YARP INI's groups. Those are an important feature that was kind of inherited by YARP conf files into the parameter handler library, and it is imporant to decide how to map that to TOML or any other representation you may use
• Conversions: once you get something to work on testing (using toml or any other representation) you may want to easily use those parameters in the YARP module. In that case, it would be good to have a toml2yarp or toml2ini tool to convert from one format to another.

[GiulioRomualdi]

Handling of YARP INI's groups

Regarding the groups I think they are already handled by the standard

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # First class dates

I suppose that [owner] is the group name

Conversions

Yes, this is tricky.

For the time being, I was thinking only on a simple implementation of IParameterHandler based on toml for passing the parameters during tests.

[traversaro]

Yes, this is tricky.

I thought it was doable as you could define a templated functions to copy parameters from IParametersHandler<Type1> to a IParametersHandler<Type2>, no?

[S-Dafarra]

I thought it was doable as you could define a templated functions to copy parameters from IParametersHandler to a IParametersHandler, no?

I think this would be possible if it was possible to iterate across elements and groups. The problem is that the type of the element is unknown.

[traversaro]

I thought it was doable as you could define a templated functions to copy parameters from IParametersHandler to a IParametersHandler, no?

I think this would be possible if it was possible to iterate across elements and groups. The problem is that the type of the element is unknown.

I see, probably if we just write down the basic list of type that we support (one one for "type", so just one for Matrix, not both iDynTree and Eigen), we can try to write them down in the conversion function, and add more types if we need them.

[marzer]

Oh, interesting, the @marzer tag in the comment above seems to have subscribed me to this discussion. I had no idea github allowed such cross-repository summoning.

In any case, it's exciting to see toml++ mentioned in the wild. If you choose to use it I'd be happy to hear any feedback/suggestions you have.

[GiulioRomualdi]

Toml++ is a really nice library with a wonderful documentation. However, as written here, there seems to be no CMake support. (i.e. the include path should be manually added in the consumer library/application).

I don't know how we can handle this in our infrastructure. @S-Dafarra @traversaro, do you have any idea?

[traversaro]

Is toml++ is going to be used just internally or also in public headers? If only internally, it is quite easy to handle, we need just to create a Findtomlplusplus.cmake script, that defines a tomlplusplus::tomlpluspuls , or do the same via fetchcontent . If instead is used in public headers, we need to also install the Findtomlplusplus.cmake script. Let me know and I can add more details.

[GiulioRomualdi]

Given the current structure (i.e. yarp implementation) the library is required in the public headers.
If you think it is too complicated, I can use the pimp idiom for hiding the toml++ library

[traversaro]

Given the current structure (i.e. yarp implementation) the library is required in the public headers.
If you think it is too complicated, I can use the pimp idiom for hiding the toml++ library

No, it is not complicated, you just need to install the Findtomlplusplus.cmake and use it in the config file (an alternative is just to copy the code that will be in Findtomlplusplus.cmake in the bipedal-locomotion-controllers cmake config). To clarify, the Findtomlplusplus.cmake can be as simple as:
~~~cmake
find_path(tomlplusplus_INCLUDE_DIR toml++/toml.h)

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(tomlplusplus REQUIRED_VARS tomlplusplus_INCLUDE_DIR)
mark_as_advanced(tomlplusplus_INCLUDE_DIR)

if (tomlplusplus_FOUND)
if(NOT TARGET tomlplusplus::tomlplusplus)
add_library(tomlplusplus::tomlplusplus UNKNOWN IMPORTED)
set_target_properties(tomlplusplus::tomlplusplus PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${tomlplusplus_INCLUDE_DIR})
endif()
endif ()
~~~

You can increase a bit the complexity if you want to check the version, but for starting this one is ok.

[GiulioRomualdi]

I implemented the code written by @traversaro in https://github.com/dic-iit/bipedal-locomotion-controllers/issues/26#issuecomment-607929202

However when I try to include toml++/toml.h the following error is thrown by the compiler

In file included from /home/gromualdi/robot-code/robotology-superbuild/build/install/include/toml++/toml.h:11:0,
                 from /home/gromualdi/robot-code/bipedal-locomotion-controllers_estimators/src/ParametersHandler/include/BipedalLocomotionControllers/ParametersHandler/IParametersHandler.h:15,
                 from /home/gromualdi/robot-code/bipedal-locomotion-controllers_estimators/src/ParametersHandler/YarpImplementation/include/BipedalLocomotionControllers/ParametersHandler/YarpImplementation.h:21,
                 from /home/gromualdi/robot-code/bipedal-locomotion-controllers_estimators/src/ParametersHandler/YarpImplementation/src/YarpImplementation.cpp:13:
/home/gromualdi/robot-code/robotology-superbuild/build/install/include/toml++/toml_common.h:313:10: fatal error: charconv: No such file or directory
 #include <charconv>
          ^~~~~~~~~~
compilation terminated.
src/ParametersHandler/YarpImplementation/CMakeFiles/ParametersHandlerYarpImplementation.dir/build.make:62: recipe for target 'src/ParametersHandler/YarpImplementation/CMakeFiles/ParametersHandlerYarpImplementation.dir/src/YarpImplementation.cpp.o' failed
make[2]: *** [src/ParametersHandler/YarpImplementation/CMakeFiles/ParametersHandlerYarpImplementation.dir/src/YarpImplementation.cpp.o] Error 1
CMakeFiles/Makefile2:1302: recipe for target 'src/ParametersHandler/YarpImplementation/CMakeFiles/ParametersHandlerYarpImplementation.dir/all' failed
make[1]: *** [src/ParametersHandler/YarpImplementation/CMakeFiles/ParametersHandlerYarpImplementation.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

I'm on Ubuntu 18.04 and the gcc -v returns

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1) 

Compiling the code with gcc-9 solves the problem. gcc-9 -v returns

Using built-in specs.
COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-17ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191102 (Ubuntu 9.2.1-17ubuntu1~18.04.1)

Checking here, I was not able to find any hints.

@traversaro @S-Dafarra, what do you suggest now?

Here you can also find a minimal reproducible example.

[traversaro]

@traversaro @S-Dafarra, what do you suggest now?

charconv is C++17. So if toml++ requires C++17 probably we need to add:
~cmake
target_compile_features(tomlplusplus::tomlplusplus INTERFACE cxx_std_17)
~
after add_library(tomlplusplus::tomlplusplus UNKNOWN IMPORTED).

[S-Dafarra]

The problem is that charconv is not included in the libstdc version available with gcc-7 :thinking: .

[traversaro]

As bipedal-locomotion-controllers is still not part of the robotology-superbuild, if you want to require a newer version of GCC for me is ok, as long as you remain compatible with the default compiler of Ubuntu 20.04 (that I guess will be 9.3). The alternatives are to ship our own charconv header (at least temporary) or to avoid to use toml++.

[traversaro]

For the CMake configuration stuff, probably a better long term solution is described in https://github.com/marzer/tomlplusplus/issues/20 .

[traversaro]

The problem is that charconv is not included in the libstdc version available with gcc-7 🤔 .

Related issue:
https://github.com/marzer/tomlplusplus/issues/21

[GiulioRomualdi]

Thanks to #81 we can use the StdImplementation of the IparameterInterface for loading the parameters in the tests. We can close this issue.

If in the future we will require toml, a new issue will be opened

[GiulioRomualdi]

Toml support added in #328