Suite of libraries for achieving bipedal locomotion on humanoid robots
Home Page: https://ami-iit.github.io/bipedal-locomotion-framework/
License: BSD 3-Clause "New" or "Revised" License
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "github-actions[bot]")
YarpUtilities::getVectorFromSearchable() function tries to resize the vector however fix sized vector cannot be resized.
Every time a new component is added the very similar CMakeLists.txt has to be copied from one component to the other (i.e. here or here). I really don't like this copy-paste of code because it may lead to errors.
I think that it could be a nice idea to implement a CMake function similar to the one written by @S-Dafarra for the unit tests .
cc @traversaro
This week I discussed with @prashanthr05 possible modification of the YARP implementation of the SensorBridge. I noticed that they may simplify the usage of the class while implementing an application that required the SensorBridge.
If for any chance the user does not set check_for_nan the result is undetermined.
https://github.com/dic-iit/bipedal-locomotion-framework/blob/a03502a65ec8ce9fd62181fccb13653818e43bf3/src/RobotInterface/YarpImplementation/src/YarpSensorBridge.cpp#L33-L35
Furthermore, the parameter handler can handle booleans. so in theory the code may be changed as
if (!ptr->getParameter("check_for_nan", m_pimpl->checkForNAN))
{
return false;
}Then the configuration file has to contain true / false (0, 1 don't work). Regarding this last sentence, I'm pretty sure on the ini files but I don't know for XML files.
The joints_list vector is required as a parameter by the configuration of the control board remapper interfaces in the SensorBridge
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridgeImpl.h#L195-L211
This is required because the sensor bridge can handle the joints ordered in a different manner respect to the polydriver. I like this feature but it would be nice if joints_list becomes an optional parameter. If passed the new order is used otherwise the polydriver joints order is used.
The SensorBridge does not have the ownership of the polydrivers. This may cause problems in case the polydrivers are deallocated (by mistake) in the consumer library/application. In the IRobotControl class, we solved this problem by saving the shared ptr to the polydriver
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/src/YarpRobotControl.cpp#L41
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/src/YarpRobotControl.cpp#L287
Unfortunately, in the SensorBridge we used yarp::dev::PolyDriverList that contains only the raw pointer to the polydrivers.
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridge.h#L104
I would suggest implementing our custom PolyDriverList where the raw pointers are converted to shared_ptr. Another possible solution is to propose the modification in yarp but I don't know if it's a good idea or not (we may break some already existing code)
It would be nice to change the getJointPositions function signature from
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridge.h#L229-L230
into
Eigen::Ref<const Eigen::VectorXd> getJointPositions(double* receiveTimeInSeconds);It simplifies a lot the usage in the consumer library. For instance you can do
myMagicFunction(m_sensorBridge.getJointPositions());instead of
Eigen::VectorXd joints;
m_sensorBridge.getJointPositions(joints);
myMagicFunction(joints);The main concern here is how to handle the default implementation in the SensorBridge class.
@S-Dafarra @prashanthr05 If you agree on some of these modifications I can already propose some PR.
The function getGroup() (see Interface and YarpImplementation) in ParametersHandler library return a std::unique_ptr<IParameterHandler<Derived>>. Sometimes this may be really annoying.
Indeed this prevents to pass the same parameters to different class initializations.
i.e.
class A
{
....
public:
void initialize(std::unique_ptr<IParameterHandler<YarpImplementation>> params);
};
int main()
{
...
std::unique_ptr<IParameterHandler<YarpImplementation>> group = params->getGroup("foo");
A a1, a2;
a1.initialize(std::move(group));
a2.initialize(std::move(group)); // <---------- Runtime error group has been moved
}The problem can be easily solved by returning an std::shared_ptr<IParameterHandler<YarpImplementation>> instead of an std::unique_ptr<IParameterHandler<YarpImplementation>> in getGroup function.
@traversaro @S-Dafarra do you have any other ideas?
When I try to compile the YarpUtilities library as static library I'm getting the following error:
gromualdi@iiticublap109:~/robot-code/bipedal-locomotion-controllers/build (fmaster)$ make
Scanning dependencies of target YarpUtilities
[ 16%] Building CXX object src/YarpUtilities/CMakeFiles/YarpUtilities.dir/src/Helper.cpp.o
[ 33%] Linking CXX static library ../../lib/libBipedalLocomotionControllersYarpUtilities.a
[ 33%] Built target YarpUtilities
[ 66%] Built target YarpUtilitiesTestMain
Scanning dependencies of target YarpUtilitiesTest
[ 83%] Building CXX object src/YarpUtilities/tests/CMakeFiles/YarpUtilitiesTest.dir/YarpUtilitiesTest.cpp.o
[100%] Linking CXX executable ../../../bin/YarpUtilitiesTest
../../../lib/libBipedalLocomotionControllersYarpUtilities.a(Helper.cpp.o): In function `bool BipedalLocomotionControllers::YarpUtilities::getVectorFromSearchable<std::vector<bool, std::allocator<bool> > >(yarp::os::Searchable const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<bool, std::allocator<bool> >&)':
/home/gromualdi/robot-code/bipedal-locomotion-controllers/src/YarpUtilities/include/BipedalLocomotionControllers/YarpUtilities/Helper.tpp:168: multiple definition of `bool BipedalLocomotionControllers::YarpUtilities::getVectorFromSearchable<std::vector<bool, std::allocator<bool> > >(yarp::os::Searchable const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<bool, std::allocator<bool> >&)'
CMakeFiles/YarpUtilitiesTest.dir/YarpUtilitiesTest.cpp.o:/home/gromualdi/robot-code/bipedal-locomotion-controllers/src/YarpUtilities/include/BipedalLocomotionControllers/YarpUtilities/Helper.tpp:168: first defined here
collect2: error: ld returned 1 exit status
src/YarpUtilities/tests/CMakeFiles/YarpUtilitiesTest.dir/build.make:125: recipe for target 'bin/YarpUtilitiesTest' failed
make[2]: *** [bin/YarpUtilitiesTest] Error 1
CMakeFiles/Makefile2:994: recipe for target 'src/YarpUtilities/tests/CMakeFiles/YarpUtilitiesTest.dir/all' failed
make[1]: *** [src/YarpUtilities/tests/CMakeFiles/YarpUtilitiesTest.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
As @traversaro suggested in #13 (comment), it is caused by a One Definition Rule violation.
The integrator class supports only iDynTree objects. This limitation is due to
https://github.com/dic-iit/bipedal-locomotion-framework/blob/8a3c44b020142bb68236057212a05ef82144af23/src/System/include/BipedalLocomotion/System/ForwardEuler.h#L48
In the next future, this may become a problem when we will extend the support the CasADi data types.
This issue is to keep track of the possible solutions.
Related issue: robotology/idyntree#510
The header files of the ParametersHandlerYarpImplementation component are installed in
-- Up-to-date: /home/gromualdi/robot-code/robotology-superbuild/build/install/include/BipedalLocomotionControllers/ParametersHandlerYarpImplementation/YarpImplementation.h
-- Up-to-date: /home/gromualdi/robot-code/robotology-superbuild/build/install/include/BipedalLocomotionControllers/ParametersHandlerYarpImplementation/YarpImplementation.tpp
This is in contrast with the #include directive in
https://github.com/dic-iit/bipedal-locomotion-controllers/blob/1835a1d1f5e9bc5e080447c12ec934e64484ca52/src/ParametersHandler/YarpImplementation/include/BipedalLocomotionControllers/ParametersHandler/YarpImplementation.tpp#L14
The bug has been introduced by #25. Indeed now the files are installed in a folder named as the component (i.e. ParametersHandlerYarpImplementation)
I would change the path and the file name
BipedalLocomotionControllers/ParametersHandlerYarpImplementation/YarpImplementation.h
into
BipedalLocomotionControllers/ParametersHandlerYarpImplementation/Implementation.h
Within the ISensoBridge interface, we decided to pass image data using Eigen refs given the availability of suitable conversions to OpenCV that can be used by the client applications. (Please see #87 (comment)) for the discussion. In short, OpenCV offers to and fro conversions with Eigen Ref (https://github.com/opencv/opencv/blob/e3d502310f6ae0cad79f3474b9ea2b25705985f9/modules/core/include/opencv2/core/eigen.hpp).
Within the YARP implementations, we handle the images using yarp::sig::Image and YARP's Eigen helpers do not offer suitable Eigen ref conversions for Images, see https://www.yarp.it/namespaceyarp_1_1eigen.html.
(YARP offers OpenCV conversions if the usage of OpenCV is enabled. However, we want to circumvent the dependency of OpenCV in any case, so this is not a suitable option)
We need to understand these conversions to complete the missing implementation for getting images in YarpSensorBridge. #106
I would like to have a logging library in the framework. I would need to log some rotation matrices from the MasImuTest I am currently developing. As far as I know, both @GiulioRomualdi, @prashanthr05 and @kouroshD developed a logger for different purposes. It would be better to unify these tools in a single library in this repo. Ideally, we should be able to save data to a mat file.
Any idea?
Description to be updated.
Copying relevant information gathered during the t2t meeting with @dic-iit/telexistence
This issue has some information
https://github.com/dic-iit/element_floating-base-estimation/issues/23
Espcially this comment
https://github.com/dic-iit/element_floating-base-estimation/issues/23#issuecomment-461381713
Guys another interesting pointer from Silvio,
https://github.com/dic-iit/element_floating-base-estimation/issues/85#issuecomment-531687562
https://github.com/kuka-isir/rtt_gazebo_embedded
I get the following error trying to compile BLF in a Mac OS X system
Scanning dependencies of target CatchTestMain
[ 2%] Building CXX object CMakeFiles/CatchTestMain.dir/Testing/Catch2Main.cpp.o
[ 4%] Linking CXX shared library lib/libCatchTestMain.dylib
[ 4%] Built target CatchTestMain
Scanning dependencies of target GenericContainerPlusYarpUnitTests
[ 6%] Building CXX object src/GenericContainer/tests/CMakeFiles/GenericContainerPlusYarpUnitTests.dir/GenericContainerTestPlusYarp.cpp.o
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/tests/GenericContainerTestPlusYarp.cpp:35:34: error: no viable constructor or deduction guide for deduction of template arguments of 'Vector'
GenericContainer::Vector container(iDynTree::make_span(vector));
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:130:5: note: candidate template ignored: substitution failure [with T = double]
Vector(iDynTree::Span<T> span)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:33:7: note: candidate template ignored: could not match 'Vector' against 'Span'
class Vector;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:146:5: note: candidate template ignored: could not match 'Vector' against 'Span'
Vector(const Vector<T>& other) = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:154:5: note: candidate template ignored: could not match 'Vector' against 'Span'
Vector(Vector<T>&& other)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:111:5: note: candidate function template not viable: requires 0 arguments, but 1 was provided
Vector() = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:118:5: note: candidate function template not viable: requires 2 arguments, but 1 was provided
Vector(iDynTree::Span<T> span, resize_function_type resizeLambda)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/tests/GenericContainerTestPlusYarp.cpp:63:34: error: no viable constructor or deduction guide for deduction of template arguments of 'Vector'
GenericContainer::Vector container(iDynTree::make_span(vector));
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:130:5: note: candidate template ignored: substitution failure [with T = double]
Vector(iDynTree::Span<T> span)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:33:7: note: candidate template ignored: could not match 'Vector' against 'Span'
class Vector;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:146:5: note: candidate template ignored: could not match 'Vector' against 'Span'
Vector(const Vector<T>& other) = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:154:5: note: candidate template ignored: could not match 'Vector' against 'Span'
Vector(Vector<T>&& other)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:111:5: note: candidate function template not viable: requires 0 arguments, but 1 was provided
Vector() = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:118:5: note: candidate function template not viable: requires 2 arguments, but 1 was provided
Vector(iDynTree::Span<T> span, resize_function_type resizeLambda)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:645:20: error: no viable constructor or deduction guide for deduction of template arguments of 'Vector'
return Vector(span, DefaultVectorResizer(input));
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/tests/GenericContainerTestPlusYarp.cpp:39:74: note: in instantiation of function template specialization 'BipedalLocomotion::GenericContainer::make_vector<yarp::sig::VectorOf<double> >' requested here
GenericContainer::Vector containerToBeCopied = GenericContainer::make_vector(copiedIn);
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:118:5: note: candidate template ignored: substitution failure [with T = double]
Vector(iDynTree::Span<T> span, resize_function_type resizeLambda)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:33:7: note: candidate function template not viable: requires 1 argument, but 2 were provided
class Vector;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:111:5: note: candidate function template not viable: requires 0 arguments, but 2 were provided
Vector() = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:130:5: note: candidate function template not viable: requires single argument 'span', but 2 arguments were provided
Vector(iDynTree::Span<T> span)
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:146:5: note: candidate function template not viable: requires single argument 'other', but 2 arguments were provided
Vector(const Vector<T>& other) = delete;
^
/Users/icub/src/bipedal-locomotion-framework/src/GenericContainer/include/BipedalLocomotion/GenericContainer/Vector.h:154:5: note: candidate function template not viable: requires single argument 'other', but 2 arguments were provided
Vector(Vector<T>&& other)
^
3 errors generated.
make[2]: *** [src/GenericContainer/tests/CMakeFiles/GenericContainerPlusYarpUnitTests.dir/GenericContainerTestPlusYarp.cpp.o] Error 1
make[1]: *** [src/GenericContainer/tests/CMakeFiles/GenericContainerPlusYarpUnitTests.dir/all] Error 2
make: *** [all] Error 2
The version of gcc
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
CMake version
cmake --version
cmake version 3.18.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
Any idea? @S-Dafarra @traversaro
Copying from #106
I Inherited the YarpSensorBridge from the Advanceable class as well. However, I have a feeling that to poll the measurements at each advance step and have a huge set of measurements stored internally would be expensive than polling for the specific measurement whenever the user calls the getXXX() method on a very specific sensor of a specific measurement type. Also since within the advance() step all the sensor reads are done serially (no sense of parallelism in internal reads as well), this might cause a huge overhead in the pipeline. I hope this doesn't turn out to be a huge design flaw in the future. If it does, we might have to reuse the read individual sensor methods in either a parallel way or to call the individual sensor reads while the user calls the getters.
(Imagine a single instance of SensorBridge configured with all sensor interfaces including cameras and multiple interfaces!)
We decided for the current requirements, we will stick with this workflow. But I will keep this issue here so that we can discuss potential implementation design changes in case the current design of YarpSensorBridge does not scale up efficiently for our future experiments.
The error is due to YCM
2020-08-31T08:46:01.5203225Z Cloning into 'ycm'...
2020-08-31T08:46:02.1291538Z Note: switching to 'a1fc6ad0d76ae18c8cce638c72516dcf1d7665cc'.
2020-08-31T08:46:02.1291668Z
2020-08-31T08:46:02.1292222Z You are in 'detached HEAD' state. You can look around, make experimental
2020-08-31T08:46:02.1292557Z changes and commit them, and you can discard any commits you make in this
2020-08-31T08:46:02.1292716Z state without impacting any branches by switching back to a branch.
2020-08-31T08:46:02.1292808Z
2020-08-31T08:46:02.1292944Z If you want to create a new branch to retain commits you create, you may
2020-08-31T08:46:02.1293261Z do so (now or later) by using -c with the switch command. Example:
2020-08-31T08:46:02.1293357Z
2020-08-31T08:46:02.1293625Z git switch -c <new-branch-name>
2020-08-31T08:46:02.1293817Z
2020-08-31T08:46:02.1293948Z Or undo this operation with:
2020-08-31T08:46:02.1294030Z
2020-08-31T08:46:02.1294267Z git switch -
2020-08-31T08:46:02.1294351Z
2020-08-31T08:46:02.1294489Z Turn off this advice by setting config variable advice.detachedHead to false
2020-08-31T08:46:02.1294572Z
2020-08-31T08:46:03.1888255Z -- YCM Version: 0.11.0 (0.11.0)
2020-08-31T08:46:03.1909899Z CMake Warning (dev) at /usr/local/share/cmake-3.17/Modules/GNUInstallDirs.cmake:225 (message):
2020-08-31T08:46:03.1910311Z Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
2020-08-31T08:46:03.1910574Z target architecture is known. Please enable at least one language before
2020-08-31T08:46:03.1910817Z including GNUInstallDirs.
2020-08-31T08:46:03.1911050Z Call Stack (most recent call first):
2020-08-31T08:46:03.1911261Z CMakeLists.txt:40 (include)
2020-08-31T08:46:03.1911700Z This warning is for project developers. Use -Wno-dev to suppress it.
2020-08-31T08:46:03.1911948Z
2020-08-31T08:46:03.2040330Z CMake Warning (dev) at find-modules/CMakeLists.txt:64 (message):
2020-08-31T08:46:03.2040978Z A "FindGLUT.cmake" module already exists in CMAKE_ROOT. Please remove it,
2020-08-31T08:46:03.2041373Z or move it to proposed.
2020-08-31T08:46:03.2042042Z This warning is for project developers. Use -Wno-dev to suppress it.
2020-08-31T08:46:03.2042350Z
2020-08-31T08:46:03.2042978Z CMake Warning (dev) at find-modules/CMakeLists.txt:64 (message):
2020-08-31T08:46:03.2043378Z A "FindGSL.cmake" module already exists in CMAKE_ROOT. Please remove it,
2020-08-31T08:46:03.2043730Z or move it to proposed.
2020-08-31T08:46:03.2044347Z This warning is for project developers. Use -Wno-dev to suppress it.
2020-08-31T08:46:03.2044625Z
2020-08-31T08:46:03.2045302Z CMake Warning (dev) at find-modules/CMakeLists.txt:64 (message):
2020-08-31T08:46:03.2045694Z A "FindOpenGL.cmake" module already exists in CMAKE_ROOT. Please remove
2020-08-31T08:46:03.2046046Z it, or move it to proposed.
2020-08-31T08:46:03.2046665Z This warning is for project developers. Use -Wno-dev to suppress it.
2020-08-31T08:46:03.2046968Z
2020-08-31T08:46:03.3536555Z -- Configuring done
2020-08-31T08:46:03.4278165Z -- Generating done
2020-08-31T08:46:03.4329061Z -- Build files have been written to: /home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build
2020-08-31T08:46:03.4501023Z Scanning dependencies of target modules
2020-08-31T08:46:03.4824884Z [ 2%] Files from modules installed in CMake build directory
2020-08-31T08:46:03.4867509Z [ 2%] Built target modules
2020-08-31T08:46:03.4909742Z Scanning dependencies of target find-modules
2020-08-31T08:46:03.5802942Z [ 5%] Files from find-modules installed in CMake build directory
2020-08-31T08:46:03.5846430Z [ 5%] Built target find-modules
2020-08-31T08:46:03.5888423Z Scanning dependencies of target cmake-proposed
2020-08-31T08:46:03.6100300Z [ 8%] Files from cmake-proposed installed in CMake build directory
2020-08-31T08:46:03.6143227Z [ 8%] Built target cmake-proposed
2020-08-31T08:46:03.6183877Z Scanning dependencies of target 3rdparty-qt-gstreamer
2020-08-31T08:46:03.6243005Z [ 10%] Downloading file cmake/modules/FindGObject.cmake from qt-gstreamer git repository (robotology-dependency fork) (ref 383c41d310b14c328ab6d5d02f478f9cca182bfb)
2020-08-31T08:46:03.9944059Z [ 13%] Downloading file cmake/modules/COPYING-CMAKE-SCRIPTS from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3)
2020-08-31T08:46:04.2579149Z [ 16%] Downloading file cmake/modules/FindGLIB2.cmake from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3)
2020-08-31T08:46:04.4249374Z [ 18%] Downloading file cmake/modules/FindGStreamerPluginsBase.cmake from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3)
2020-08-31T08:46:04.6023988Z [ 21%] Downloading file cmake/modules/MacroFindGStreamerLibrary.cmake from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3)
2020-08-31T08:46:04.7395110Z [ 24%] Downloading file cmake/modules/FindGStreamer.cmake from qt-gstreamer git repository (robotology-dependency fork) (ref 383c41d310b14c328ab6d5d02f478f9cca182bfb)
2020-08-31T08:46:04.9298408Z [ 27%] Files from qt-gstreamer git repository (ref a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3) downloaded
2020-08-31T08:46:04.9344531Z [ 27%] Built target 3rdparty-qt-gstreamer
2020-08-31T08:46:04.9384807Z Scanning dependencies of target 3rdparty-qgv
2020-08-31T08:46:04.9602218Z [ 29%] Files from 3rdparty-qgv installed in CMake build directory
2020-08-31T08:46:04.9642334Z [ 29%] Built target 3rdparty-qgv
2020-08-31T08:46:04.9681340Z Scanning dependencies of target 3rdparty-cmake-wiki
2020-08-31T08:46:04.9889777Z [ 32%] Files from 3rdparty-cmake-wiki installed in CMake build directory
2020-08-31T08:46:04.9933452Z [ 32%] Built target 3rdparty-cmake-wiki
2020-08-31T08:46:04.9972594Z Scanning dependencies of target 3rdparty-cmrc
2020-08-31T08:46:05.0009894Z [ 35%] Downloading file LICENSE.txt from CMakeRC (A Standalone CMake-Based C++ Resource Compiler) git repository (ref 966a1a717715f4e57fb1de00f589dea1001b5ae6)
2020-08-31T08:46:05.1824034Z [ 37%] Downloading file CMakeRC.cmake from CMakeRC (A Standalone CMake-Based C++ Resource Compiler) git repository (ref 966a1a717715f4e57fb1de00f589dea1001b5ae6)
2020-08-31T08:46:05.3446348Z [ 40%] Files from CMakeRC (A Standalone CMake-Based C++ Resource Compiler) git repository (ref 966a1a717715f4e57fb1de00f589dea1001b5ae6) downloaded
2020-08-31T08:46:05.3491093Z [ 40%] Built target 3rdparty-cmrc
2020-08-31T08:46:05.3532207Z Scanning dependencies of target 3rdparty-ovito
2020-08-31T08:46:05.3590396Z [ 43%] Downloading file cmake/FindQCustomPlot.cmake from OVITO (The Open Visualization Tool) git repository (ref 8689fcb1fdd2e8dc748e76d54d3b77a3f87d384c)
2020-08-31T08:46:05.5575524Z [ 45%] Downloading file LICENSE.txt from OVITO (The Open Visualization Tool) git repository (ref 8689fcb1fdd2e8dc748e76d54d3b77a3f87d384c)
2020-08-31T08:46:05.7887983Z [ 48%] Files from OVITO (The Open Visualization Tool) git repository (ref 8689fcb1fdd2e8dc748e76d54d3b77a3f87d384c) downloaded
2020-08-31T08:46:05.7931938Z [ 48%] Built target 3rdparty-ovito
2020-08-31T08:46:05.7974292Z Scanning dependencies of target 3rdparty-eigen
2020-08-31T08:46:05.8030761Z [ 51%] Downloading file cmake/FindEigen3.cmake from Eigen mercurial repository (ref 844c47cfd8d309fe4db5cc21dd7368759d0a7a00)
2020-08-31T08:46:05.8898358Z -- Cannot download file https://bitbucket.org/eigen/eigen/raw/844c47cfd8d309fe4db5cc21dd7368759d0a7a00/cmake/FindEigen3.cmake
2020-08-31T08:46:05.8899215Z Network problem or not existing file.
2020-08-31T08:46:05.8900154Z CMake Error at /home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/ycm_download_cmake_FindEigen3_cmake_real.cmake:9 (file):
2020-08-31T08:46:05.8900675Z file DOWNLOAD HASH mismatch
2020-08-31T08:46:05.8900985Z
2020-08-31T08:46:05.8901876Z for file: [/home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/downloads/cmake/FindEigen3.cmake]
2020-08-31T08:46:05.8902407Z expected hash: [5ad2b8e1ddbd9f0468b21e9d5343d05eda6b9dd1]
2020-08-31T08:46:05.8902820Z actual hash: [da39a3ee5e6b4b0d3255bfef95601890afd80709]
2020-08-31T08:46:05.8903226Z status: [22;"HTTP response code said error"].
2020-08-31T08:46:05.8903891Z Retrying.
2020-08-31T08:46:05.8904185Z
2020-08-31T08:46:05.9717958Z -- Cannot download file https://bitbucket.org/eigen/eigen/raw/844c47cfd8d309fe4db5cc21dd7368759d0a7a00/cmake/FindEigen3.cmake
2020-08-31T08:46:05.9718544Z Network problem or not existing file.
2020-08-31T08:46:05.9719646Z CMake Error at /home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/ycm_download_cmake_FindEigen3_cmake_real.cmake:9 (file):
2020-08-31T08:46:05.9720416Z file DOWNLOAD HASH mismatch
2020-08-31T08:46:05.9720630Z
2020-08-31T08:46:05.9722294Z for file: [/home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/downloads/cmake/FindEigen3.cmake]
2020-08-31T08:46:05.9722645Z expected hash: [5ad2b8e1ddbd9f0468b21e9d5343d05eda6b9dd1]
2020-08-31T08:46:05.9722911Z actual hash: [da39a3ee5e6b4b0d3255bfef95601890afd80709]
2020-08-31T08:46:05.9723160Z status: [22;"HTTP response code said error"].
2020-08-31T08:46:05.9723404Z Retrying.
2020-08-31T08:46:05.9723521Z
2020-08-31T08:46:06.0642189Z CMake Error at /home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/ycm_download_cmake_FindEigen3_cmake.cmake:30 (message):
2020-08-31T08:46:06.0643315Z Cannot download file
2020-08-31T08:46:06.0644017Z https://bitbucket.org/eigen/eigen/raw/844c47cfd8d309fe4db5cc21dd7368759d0a7a00/cmake/FindEigen3.cmake
2020-08-31T08:46:06.0644527Z
2020-08-31T08:46:06.0644919Z
2020-08-31T08:46:06.0645465Z Network problem or not existing file.
2020-08-31T08:46:06.0646678Z CMake Error at /home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/ycm_download_cmake_FindEigen3_cmake_real.cmake:9 (file):
2020-08-31T08:46:06.0649478Z file DOWNLOAD HASH mismatch
2020-08-31T08:46:06.0649959Z
2020-08-31T08:46:06.0651471Z 3rdparty/CMakeFiles/3rdparty-eigen.dir/build.make:107: recipe for target '3rdparty/eigen3/cmake/FindEigen3.cmake' failed
2020-08-31T08:46:06.0652103Z
2020-08-31T08:46:06.0652397Z
2020-08-31T08:46:06.0653368Z for file: [/home/runner/work/bipedal-locomotion-framework/bipedal-locomotion-framework/ycm/build/3rdparty/CMakeFiles/3rdparty-eigen.dir/downloads/cmake/FindEigen3.cmake]
2020-08-31T08:46:06.0653877Z expected hash: [5ad2b8e1ddbd9f0468b21e9d5343d05eda6b9dd1]
2020-08-31T08:46:06.0654311Z actual hash: [da39a3ee5e6b4b0d3255bfef95601890afd80709]
2020-08-31T08:46:06.0655726Z status: [22;"HTTP response code said error"]
2020-08-31T08:46:06.0656400Z CMakeFiles/Makefile2:1369: recipe for target '3rdparty/CMakeFiles/3rdparty-eigen.dir/all' failed
2020-08-31T08:46:06.0656987Z
2020-08-31T08:46:06.0657274Z
2020-08-31T08:46:06.0657716Z make[2]: *** [3rdparty/eigen3/cmake/FindEigen3.cmake] Error 1
2020-08-31T08:46:06.0658476Z make[1]: *** [3rdparty/CMakeFiles/3rdparty-eigen.dir/all] Error 2
2020-08-31T08:46:06.0659302Z Makefile:145: recipe for target 'all' failed
2020-08-31T08:46:06.0668412Z make: *** [all] Error 2
2020-08-31T08:46:06.0682286Z ##[error]Process completed with exit code 2.
2020-08-31T08:46:06.0758435Z Post job cleanup.
2020-08-31T08:46:06.1779422Z [command]/usr/bin/git version
2020-08-31T08:46:06.1839184Z git version 2.28.0
2020-08-31T08:46:06.1873522Z [command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
2020-08-31T08:46:06.1913844Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
2020-08-31T08:46:06.2221555Z [command]/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2020-08-31T08:46:06.2256377Z http.https://github.com/.extraheader
2020-08-31T08:46:06.2265085Z [command]/usr/bin/git config --local --unset-all http.https://github.com/.extraheader
2020-08-31T08:46:06.2306348Z [command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
2020-08-31T08:46:06.2639122Z Cleaning up orphan processes
After a meeting with @prashanthr05 @GiulioRomualdi @kouroshD and @isorrentino we converged on the following.
In order to test these implementations, we decided to use Gazebo with the gazebo-yarp-plugins.
These interfaces do not need precise synchronization since, for the time being, we just need to set simple commands and read the output of the sensors. Hence, we thought about keeping Gazebo as a separate process (without visualization). The clock can be controlled as in the Simulator synchronizer of WB-Toolbox.
We identified the following action points:
These action points will be on separate issues.
I built the first application using the IRobotInterface when I run the application on my laptop the application sometimes fails here:
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/src/YarpRobotControl.cpp#L131-L135
Back in time we solved the problem using a timer and checking several times if the yarp interface were able to collect the data. See here.
I would avoid implementing the same trick also here. (Probably we have the same problem with the ISensorBridge implemented by @prashanthr05)
Furthermore the fact that this behavior is completely random bothers me a lot.
Is there someone able to explain to me why this is happening?
@traversaro @S-Dafarra @prashanthr05
While working on a GUI for a separate project, I started using QT. Let me start with the premise that I am not an expert at all with this framework and I just started learning it, but along the way, I started appreciating some features that I believe may be useful in our case.
First of all, Qt is pretty easy and tailored to be used within a CMake project while having multi-platform support. In addition, it is possible to use both in C++ and Python. The documentation is very detailed and, even if there may be some dark spots, online you can find countless tutorials and answers on Stack Overflow on 95% of the possible doubts you may have while using it. Nevertheless, these are not the reasons why I considered using it in this project.
One of the core features in QT is the definition of signals and slots: https://doc.qt.io/qt-5/signalsandslots.html. These allow defining an interface between different objects. Once a signal is "emitted", the corresponding slots on the other objects are called. On their own, they are not so much different from normal interfaces and methods call. The interesting thing is that multiple objects may be called after a single "signal". In addition, threading becomes easy. See for example https://doc.qt.io/qt-5/qthread.html#details where an object can be put in a separate thread with a single method call. In addition, if there is no shared data between objects (they do not point to a third object) mutex are not even necessary (see https://doc.qt.io/qt-5/threads-synchronizing.html).
An example in our case would be the handling of planners and controllers. Planners can be in a separate thread, and once done, they may simply "emit" a signal which is handled by the controller class. Without forgetting that Qt is used to build GUIs. The signal emitted by the planner may be also detected by a logger which displays the trajectories on a GUI.
One of the downsides is that templates are not digested well in a Qt object. See for example https://stackoverflow.com/questions/4397478/qt-templated-q-object-class. The main reason is that Qt requires to autogenerate a lot of stuff, hence the definition of templates makes this passage prohibitive.
I wanted to use this issue to trigger a discussion on this, even if it is not clear to me either which first step we may eventually take in this direction. Also, this partially overlaps with #39.
@traversaro @GiulioRomualdi @prashanthr05 what do you think?
Related discussion: #118 (comment)
Thanks to #13 #18 #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
Starting from #63 we started to use Eigen actively on the framework. As you probably know Eigen suppresses several checks if the consumer library/application is compiled in Release, this may lead to undesired behavior that are not easy to spot. See for instance #85 (comment).
Enabling the Debug tag on CI may help the developer to spot some problems. On the other hand, it will increase the compilation time on the GitHub action.
What do you think @S-Dafarra @prashanthr05 @traversaro?
Discussing with @S-Dafarra we were thinking to rename the repository and the namespaces.
One of the possible solutions is to rename the repo in bipedal-locomotion-framework and change the namespace from BipedalLocomotionController to BLF.
@traversaro @MiladShafiee any idea?
When I try to install the GenericContainer element, I get the following error:
Make Error at src/GenericContainer/cmake_install.cmake:41 (file):
file INSTALL cannot find
"/home/gromualdi/robot-code/bipedal-locomotion-controllers_estimators/src/GenericContainer/include/BipedalLocomotionControllers/GenericVector/TemplateHelpers.h":
No such file or directory.
Call Stack (most recent call first):
src/cmake_install.cmake:42 (include)
cmake_install.cmake:69 (include)
The problem can be easily fixed with the following patch
diff --git a/src/GenericContainer/CMakeLists.txt b/src/GenericContainer/CMakeLists.txt
index 026ec88..e4203de 100644
--- a/src/GenericContainer/CMakeLists.txt
+++ b/src/GenericContainer/CMakeLists.txt
@@ -5,9 +5,7 @@
# set target name
add_bipedal_component(
NAME GenericContainer
- PUBLIC_HEADERS include/BipedalLocomotionControllers/GenericContainer/Vector.h include/BipedalLocomotionControllers/GenericVector/TemplateHelpers.h
+ PUBLIC_HEADERS include/BipedalLocomotionControllers/GenericContainer/Vector.h include/BipedalLocomotionControllers/GenericContainer/TemplateHelpers.h
PUBLIC_LINK_LIBRARIES ${iDynTree_LIBRARIES}
SUBDIRECTORIES tests
IS_INTERFACE ON)This issue is part of a broader discussion initiated with #94
In particular, in case we have to develop an interface which requires a vector as input, we have to decide what to use. We have several possibilities:
eigen vectors, more specifically Eigen::RefGenericContainer::VectorIn this issue, we can share thoughts and find an agreement.
As written in the Eigen documentation, the default storage order of matrices is ColMajor, however in iDynTree the matrices are stored as RowMajor.
This raises a problem when we try to use the Eigen::Ref. Right now, in all the interfaces we use Eigen::Ref<Eigen::MatrixXd> for passing matrices, thanks to this we can write:
void cov(const Ref<const MatrixXf> x, const Ref<const MatrixXf> y, Ref<MatrixXf> C)
{
const float num_observations = static_cast<float>(x.rows());
const RowVectorXf x_mean = x.colwise().sum() / num_observations;
const RowVectorXf y_mean = y.colwise().sum() / num_observations;
C = (x.rowwise() - x_mean).transpose() * (y.rowwise() - y_mean) / num_observations;
}MatrixXf m1, m2, m3
cov(m1, m2, m3);
cov(m1.leftCols<3>(), m2.leftCols<3>(), m3.topLeftCorner<3,3>());The same applies also with maps
float m1[9]. m2[9], m3[9];
Eigen::Map<Eigen::MatrixXf> map1(m1, 3, 3);
Eigen::Map<Eigen::MatrixXf> map2(m3, 3, 3);
Eigen::Map<Eigen::MatrixXf> map3(m3, 3, 3);
cov(map1, map2, map3);Unfortunately iDynTree store the matrices in RowMajor and the following lines of code will not compile
void foo(Eigen::Ref<Eigen::MatrixXd> m)
{
return;
}
int main()
{
iDynTree::MatrixDynSize matrix(2,2);
Eigen::Matrix<double, Eigen::Dynamic, Eigen::Dynamic, Eigen::RowMajor>> map = iDynTree::toEigen(matrix);
foo(map);
}/home/gromualdi/robot-code/test_eigen/eigen.cpp:26:12: error: could not convert ‘map’ from ‘Eigen::Map<Eigen::Matrix<double, -1, -1, 1> >’ to ‘Eigen::Ref<Eigen::Matrix<double, -1, -1> >’
foo(map);
This is a huge problem because we cannot call the functions we implemented so far with Map of RowMajor object (we cannot use iDynTree easily).
Discussing with @S-Dafarra we noticed that it is possible to play with the Eigen::Stride for viewing an RowMajor matrix to a ColMajor one.
For instance:
double array1[6];
for(int i = 0; i < 6; ++i)
array1[i] = i;
cout << Map<MatrixXd, 0, Stride<Dynamic,Dynamic>>(array1, 2, 3, Stride<Dynamic,Dynamic>(1, 3))<< endl;
cout << Map<Eigen::Matrix<double, Eigen::Dynamic, Eigen::Dynamic, Eigen::RowMajor>, 0, Stride<Dynamic,Dynamic>>(array1, 2, 3, Stride<Dynamic,Dynamic>(3, 1)) << endl;gives the following output
0 1 2
3 4 5
0 1 2
3 4 5
Unfortunately, this does not solve our problem since
void foo(Eigen::Ref<Eigen::MatrixXd> m)
{
return;
}
foo( Map<MatrixXd, 0, Stride<Dynamic,Dynamic>>(array1, 2, 3, Stride<Dynamic,Dynamic>(1, 3)));does not compile and give us the following error:
/home/gromualdi/robot-code/test_eigen/manif.cpp: In function ‘int main()’:
/home/gromualdi/robot-code/test_eigen/manif.cpp:26:12: error: could not convert ‘map’ from ‘Eigen::Map<Eigen::Matrix<double, -1, -1, 1> >’ to ‘Eigen::Ref<Eigen::Matrix<double, -1, -1> >’
foo(map);
^
/home/gromualdi/robot-code/test_eigen/manif.cpp:79:9: error: could not convert ‘Eigen::Map<Eigen::Matrix<double, -1, -1>, 0, Eigen::Stride<-1, -1> >(((double*)(& array2)), 2, 3, Eigen::Stride<-1, -1>(1, 3))’ from ‘Eigen::Map<Eigen::Matrix<double, -1, -1>, 0, Eigen::Stride<-1, -1> >’ to ‘Eigen::Ref<Eigen::Matrix<double, -1, -1> >’
foo(Map<MatrixXd, 0, Stride<Dynamic,Dynamic> >
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(array2, 2, 3, Stride<Dynamic,Dynamic>(1, 3)));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So far I found two possible solutions:
We start using only the RowMajor matrices in blf
pros:
iDynTreecons:
manif still working?We templatize everything
pros:
cons:
I notice that we are implementing the initialize() method for each class (i.e. here or here) and in general the class cannot be used till the initialize() method is called.
Probably we can generalize the concept by designing a class named block (or another name). The other classes will inherit from block.
This is an example of the class
class Block
{
protected:
enum class State
{
NotInitialized, Initialized, ...
};
State m_state;
public:
virtual bool initialize(std::weak_ptr<IParameterHandler> handler) {return true;};
void bool close() {return true;};
virtual ~Block();
};This issue is for discussing the possible strategies we can implement.
@traversaro @S-Dafarra @MiladShafiee @prashanthr05
I noticed that every time I need to read the data from a yarp port, I always need the following ingredients
yarp::os::BufferedPort<T> port;
U data; /**< Vector containing the data. */
std::unique_ptr<Smoother> smoother;
std::mutex mutex // <---- Useful if we are going to introduce threads in the final application Where the Smoother is an optional class that smooths the data. In general, it is a low pass filter or a minimum jerk trajectory generator.
Last but not least, a signal may be streamed not only through a yarp port. For instance, the signal may arrive from a file (i.e. @prashanthr05 dataset for testing the estimation)
We can try to abstract the concept of the signal and introduce an interface for streaming data through the network/logfile.
In the dynamical system class the state, state derivative and control input are stored in std::tuple as @S-Dafarra commented in #70 (comment) this may lead to readability problem.
To overcome this limitation, @S-Dafarra suggested some possible implementations of "tagged tuples", where the get uses a string instead of an index:
Another possible solution is to store the state control input and the state derivative in a struct and use this library to convert the struct in a tuple
Copying from #121 (comment),
Aside, in addition to all the pointers, there was one feature I did not implement in the YarpSensorBridge while porting from the legacy RobotSensorBridge which basically runs a dry reading of sensors at the end of setDriversList phase once all the drivers are attached. This dry read polls for sensor measurements upto a timeout period (similar to the recent fix in IRobotControl) helping to identify early failures at the initialisation phase itself, in case there are no measurements available at the lower level.
Should we consider to reimplement it here as well?
The implementation of this in the previous RobotSensorBridge implementation was done with a sensorReadDryRun() method, which also used a similar timeout based check to be called at the end of attaching to every other polydriver device and run a read with a timeout to check if the buffers are not empty. This was actually originally ported from the wholeBodyDynamics device.
The relevant change in IRobotControl was introduced in #118 with the commit 8fc2bef.
With the changes introduced in https://github.com/robotology/idyntree/pull/736/files and possibly an extension to also the iDynTree::Model class, we need to reflect the changes in FloatingBaseEstimators, so that the public API is free of iDynTree objects.
Instead, we will rely on manif and Eigen types.
The IParameterHandler interface library is really useful to set and get the parameters however it has an enormous drawback.
Given the implementation of the interface, a function that has as input the interface has to be template i.e.
template <class Derived>
bool Foo::initialize(const IParameterHandler<derived>& handler)
{
// get the parameters
return true;
}The IParametersHandler is a template class because it is implemented using the CRTP pattern. The pattern is required to implement static polymorphism and consequentially to make the follwing line of codes compiling
class IParametersHandler
{
public:
template <typename T>
virtual bool getParameter(const std::string& parameterName, T& parameter) const = 0;
};
class YarpImplementation : public IParametersHandler
{
public:
template <typename T>
bool getParameter(const std::string& parameterName, T& parameter) const final
{
// custom code
}
}; Indeed class member function template cannot be virtual., and in our case getParameter() is template to be compatible with different types (i.e. iDynTree::VectorDynSize ,int, bool, double, ...).
As discussed with @S-Dafarra having template consumer functions may over-complexify the code.
For this reason, I would like to find a solution to the problem.
Discussing with @traversaro and @S-Dafarra we found two possible solutions:
yarp one and pass the parameter with that implementation.
bool Foo::initialize(const IParameterHandlerYarpImplementation& handler)
{
// get the parameters
return true;
}getParameter() method may remain template and in theory, we guarantee the support to the different datatypes. On the other hand, all the libraries will depend on yarp and this is very sad given the effort to make the libraries yarp free.getParameter() i.e.
class IParametersHandler
{
public:
virtual bool getParameter(const std::string& parameterName, int& parameter) const = 0;
virtual bool getParameter(const std::string& parameterName, bool& parameter) const = 0;
virtual bool getParameter(const std::string& parameterName, double& parameter) const = 0;
...
};
class YarpImplementation : public IParametersHandler
{
public:
bool getParameter(const std::string& parameterName, int& parameter) const final;
bool getParameter(const std::string& parameterName, bool& parameter) const final;
bool getParameter(const std::string& parameterName, double& parameter) const final;
}; This issue is to discuss the actions that we should take for solving the presented problem.
Related discussions: #26 #7 (comment) #13 (comment)
Here I copy some comments taken from #121
@GiulioRomualdi wrote:
It would be nice to change the
getJointPositionsfunction signature from
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c055c48edb86aa9f23fb7cc572a4ea005f1c626b/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridge.h#L229-L230into
Eigen::Ref<const Eigen::VectorXd> getJointPositions(double* receiveTimeInSeconds);It simplifies a lot the usage in the consumer library. For instance you can do
myMagicFunction(m_sensorBridge.getJointPositions());instead of
Eigen::VectorXd joints; m_sensorBridge.getJointPositions(joints); myMagicFunction(joints);The main concern here is how to handle the default implementation in the
SensorBridgeclass.
@S-Dafarra answered:
I like the idea. On the other hand, the interfaces so far, including the original Yarp one, assume that no memory is own. If we want to change this, then I would suggest creating a struct containing all the possible data that can be retrieved by the bridge. Each one of the
get*would return some reference to the underlying structure. The nice point of this is that it would be possible to write anadvancemethod filling up this struct. The problem is that this struct should be implementation dependent. It would require a lot of copies if we define it with Eigen objects. Maybe it would be possible to do that with theVector::Ref, but I am not sure.
Having a BasicImplementation of the IParameterHandler may help a lot in testing different components.
Actually the code is already available in
https://github.com/dic-iit/bipedal-locomotion-framework/blob/c0154c8e50a67749a59849ce3f1c1d622054da01/src/ParametersHandler/tests/ParametersHandlerTest.cpp#L24-L33
We may think to port the class into a separate file and use it.
There is a copy-paste bug in ContactPhaseList::const_iterator ContactPhaseList::cbegin() const function
https://github.com/dic-iit/bipedal-locomotion-framework/blob/557c7c7c9ba1ab71b0daff6ac7120fec1bae9077/src/Planners/src/ContactPhaseList.cpp#L121-L124
/home/gromualdi/robot-code/bipedal-locomotion-framework_planner/src/System/include/BipedalLocomotion/System/Advanceable.h:33:14: error: initializer specified for non-virtual method ‘const T& BipedalLocomotion::System::Advanceable<T>::get() const [with T = BipedalLocomotion::Planners::DCMPlannerState]’
const T& get() const = 0;
^~~
/home/gromualdi/robot-code/bipedal-locomotion-framework_planner/src/System/include/BipedalLocomotion/System/Advanceable.h:39:10: error: initializer specified for non-virtual method ‘bool BipedalLocomotion::System::Advanceable<T>::isValid() const [with T = BipedalLocomotion::Planners::DCMPlannerState]’
bool isValid() const = 0;
^~~~~~~
/home/gromualdi/robot-code/bipedal-locomotion-framework_planner/src/System/include/BipedalLocomotion/System/Advanceable.h:45:10: error: initializer specified for non-virtual method ‘bool BipedalLocomotion::System::Advanceable<T>::advance() [with T = BipedalLocomotion::Planners::DCMPlannerState]’
bool advance() = 0;
^~~~~~~
CppAD is a nice library for automatic differentiation. It is widely used in Pinocchio. In light of the outcome of ami-iit/idynfor#1, I would like to add the support of CppAD on the framework.
The library can be easily installed on Linux and Mac. On windows, the installation of the library is more complex and there seems there are some compilation issues coin-or/CppAD#60.
As already explained in #51 (comment), the Planner component cannot be built on Windows because of a dependency issue on qhull.
I noticed that the libraries created by this repo have a name that is too generic (i.e. libSystem.so)
I would suggest adding a suffix to the library name. i.e. libBipedalLocomotionFrameworkSystem.so
This can be easily done by adding in the AddBipedalLocomotionLibrary.cmake
set_target_properties(${LIBRARY_TARGET_NAME} PROPERTIES OUTPUT_NAME "${PROJECT_NAME}${LIBRARY_TARGET_NAME}")The Windows CI integration is failing with the following error
Starting package 2/8: ace:x64-windows
Building package ace[core]:x64-windows...
-- Downloading https://github.com/DOCGroup/ACE_TAO/releases/download/ACE%2BTAO-6_5_8/ACE-src-6.5.8.zip...
-- Extracting source C:/vcpkg/downloads/ACE-src-6.5.8.zip
-- Using source at C:/vcpkg/buildtrees/ace/src/ACE-src-6-a3686a23cb
-- Downloading http://strawberryperl.com/download/5.30.0.1/strawberry-perl-5.30.0.1-32bit.zip...
-- Building C:/vcpkg/buildtrees/ace/src/ACE-src-6-a3686a23cb/ace/ace.sln for Release
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: msbuild C:/vcpkg/buildtrees/ace/src/ACE-src-6-a3686a23cb/ace/ace.sln /p:Configuration=Release /t:Rebuild /p:Platform=x64 /p:PlatformToolset=v142 /p:VCPkgLocalAppDataDisabled=true /p:UseIntelMKL=No /p:WindowsTargetPlatformVersion=10.0.18362.0 /m /p:ForceImportBeforeCppTargets=C:/vcpkg/scripts/buildsystems/msbuild/vcpkg.targets /p:VcpkgTriplet=x64-windows
Working Directory: C:/vcpkg/buildtrees/ace/x64-windows-rel
Error code: 1
See logs for more information:
C:\vcpkg\buildtrees\ace\build-x64-windows-rel-out.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_msbuild.cmake:119 (vcpkg_execute_required_process)
ports/ace/portfile.cmake:98 (vcpkg_build_msbuild)
Running vcpkg.exe update should solve the problem
https://github.com/dic-iit/bipedal-locomotion-controllers/runs/527453730
In this issue, we will track the problems related to the generation of the python bindings
I think it may be useful to generate Python and Matlab bindings for the libraries developed in this repository.
The prerequisite to generate the Matlab bindings is an experimental version of Swig. This can be found in the repository: https://github.com/robotology-dependencies/swig/
This task does not have a high priority but we should keep it in mind
The visualization is appealing and modern. In this issue, I would like to track the investigation of porting MeshCat in our framework
It took 10.5 minutes (!) on my PC on Ubuntu 20.04. Even without memcheck.
I installed the following dependencies: manif, qhull, casadi, idyntree, yarp. Without passing any custom CMake option I get the following compilation error:
bipedal-locomotion-framework/build on master [!] via 🐍 v3.8.2 (venv)
✦2 ❯ ninja
[45/46] Linking CXX shared library lib/libBipedalLocomotionFrameworkPlanners.so.0.0.1
FAILED: lib/libBipedalLocomotionFrameworkPlanners.so.0.0.1
: && /usr/lib/ccache/clang++-10 -fPIC -fdiagnostics-color=always -O3 -DNDEBUG -shared -Wl,-soname,libBipedalLocomotionFrameworkPlanners.so.0.0.1 -o lib/libBipedalLocomotionFrameworkPlanners.so.0.0.1 src/Planners/CMakeFiles/Planners.dir/src/ConvexHullHelper.cpp.o src/Planners/CMakeFiles/Planners.dir/src/DCMPlanner.cpp.o src/Planners/CMakeFiles/Planners.dir/src/TimeVaryingDCMPlanner.cpp.o src/Planners/CMakeFiles/Planners.dir/src/QuinticSpline.cpp.o src/Planners/CMakeFiles/Planners.dir/src/SwingFootPlanner.cpp.o -Wl,-rpath,/home/dferigo/git/bipedal-locomotion-framework/build/lib:/rl/local/lib:/iit/sources/robotology-superbuild/build/install/lib: lib/libBipedalLocomotionFrameworkSystem.so.0.0.1 lib/libBipedalLocomotionFrameworkContact.so.0.0.1 /rl/local/lib/libqhullcpp.a /rl/local/lib/libqhullstatic_r.a /rl/local/lib/libcasadi.so.3.6 lib/libBipedalLocomotionFrameworkContactModels.so.0.0.1 lib/libBipedalLocomotionFrameworkParametersHandler.so.0.0.1 /iit/sources/robotology-superbuild/build/install/lib/libidyntree-high-level.so /iit/sources/robotology-superbuild/build/install/lib/libidyntree-modelio-urdf.so /iit/sources/robotology-superbuild/build/install/lib/libidyntree-sensors.so /iit/sources/robotology-superbuild/build/install/lib/libidyntree-modelio-xml.so /iit/sources/robotology-superbuild/build/install/lib/libidyntree-model.so /iit/sources/robotology-superbuild/build/install/lib/libidyntree-core.so -lm -ldl && :
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(global_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(stat_r.c.o): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(geom2_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(poly2_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(merge_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(libqhull_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(geom_r.c.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(poly_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(qset_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(mem_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(random_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(usermem_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(io_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /rl/local/lib/libqhullstatic_r.a(user_r.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
I tried to add the following to the main CMakeLists.txt without any change:
# Always use -fPIC
set(CMAKE_POSITION_INDEPENDENT_CODE ON)Disclaimer The title of the issue is deliberately provocative.
In robotology/idyntree#707 I show the possibility to use Eigen in iDynTree public API. The main pro of using Eigen is enabling the linear algebra.
Discussing with @traversaro we realized that even if describing an iDynTree::VectorFixSize<> with Eigen is relatively simple robotology/idyntree#709, implementing the same approach for an iDynTree::VectorDynSize is way less trivial. Indeed in iDynTree, the concept of capacity is widely used. This concept does not have a corresponding in Eigen.
In order to solve #56 and other similar problems, we (@traversaro and I) drew 2 + 1 possible solutions:
Nothing changes We keep the status quo.
Introduce operator+() (and all the others) in iDynTree between matrices and vector
Avoid to use iDynTree in bipedal locomotion framework:
Eigen It will be easy to use the library in other projects. Hopefully, the library will be used also in other labs since Eigen can be considered as numpy for Python. In the past, we already used Eigen instead of iDynTree in osqp-eigen.In order to tackle the second point we should write a simple interface to iDynTree::KinDynComputations that takes as input Eigen Objects. The interface becomes useless as soon as the KinDynComputations class accepts iDynTree::Span
We should make a decision as fast as possible since the code in the repository is increasing day after day. (In theory, we should decide before merging #61 #62)
@dic-iit/dynamic-interaction-control
In general, we adhere to the usage of Eigen types in the public API provided by the libraries in this repository.
However, when it comes to dealing with heterogeneous types of data, which may further be of fixed size or variable size, single-dimensional or multi-dimensional, be classes or structs, it becomes unclear how these types must be handled.
We saw this ambiguity arise with the introduction of the ISensorBridge interface (#87), where we had to deal with,
Bipedal Locomotion Framework also provides the GenericContainer class which was meant to have a unique way to deal with multiple vector implementations that could have also been resized. This was coming in handy when dealing with parameters. Depending on the implementation and on the needs, we may have needed a Yarp::Sig::Vector, or iDynTree::VectorDynSize for example. This was before moving to Eigen in the main API. So, it would be suggestive to use GenericContainer::Vector in case one needs to deal with different vector implementation at the same time, especially in case you need to resize them (something that is not possible with an Eigen::map).
However, GenericContainer::Vector cannot be used for datatypes, for instance, images, that are usually stored as matrices.
Additionally, we must choose the types efficiently so that we do not introduce any additional overheads while converting from one type to another type, and passing it on to the user (who might/might not have to again convert to the desired type). This issue mainly comes into the picture in a SensorBridge scenario, where proper/inexpensive conversions to cv::Mat or pcl::PointCloud must be done.
Given the above pointers, in particular, it is not clear:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.