robotology / human-dynamics-estimation Goto Github PK

Setup on Windows (HDE modules) and Linux (Rviz):
If you launch Rviz when all the HDE modules on the yarpmanager are running , the module human-effort-bridge module cashes. This implies that you are NOT able to visualize the effort on the model.

HDE (and in particular the human-state-provider module uses a custom-made inverse kinematics library inspired from a pre-release version of iDynTree inverse kinematics library.
Now that the iDynTree inverse kinematics library has been released, I think it make sense to migrate the module to use the idyntree version.
This would greatly simplify the maintainability of the module.

A drawback may be (and should be checked) the increase in complexity and computational cost of the problem to be solved.

Currently, we are setting the joint velocities to zero manually. We need to implement correct joint velocities computation based on the information from the xsens suit.

• First we need to understand how it was implemented in HDEv1 (@claudia-lat mentioned that @lucaTagliapietra implemented a state space filter )
• See what information is needed from the xsens suit through wearables here
• Implement the part of joint velocities computation

@lrapetti @kouroshD @claudia-lat @diegoferigo

iDynTree now offers a MAP solver for the Berdy equations.
We should update the human-dynamics-estimation module to use this class instead of implementing it.

It would be nice to define a clang-format.

I started with this commit 2748cd3, but some things needs to be fine tuned (e.g. multiline pure virtual functions have = 0 in a newline, enforce {} on every if etc)

Also, as it seems not possible to synchronize git hooks across remotes, (and with my initial tests they are creating some issues during commits) we should enforce it at PR level.

To run clang-format on this project one can run the following bash command in the root of the project
find . -path "./build*" -prune -o -iname *.h -o -iname *.cpp | xargs clang-format -i

In this issue we will track the details related to the setting up a new machine from scratch to run HDE demo with FTShoes containing the skin soles. Eventually this will be documented in a wiki page.

@lrapetti @InesSorrentino @claudia-lat @DanielePucci

The joint accelerations are needed for filling in the vector y of the measurements.
For the time being, y is a vector with the entries equal to 0 apart from the external forces readings (force plates + robot). It means that the estimation of the vector d depends only on the forces and it doesn't take into account any joint acceleration contribution!
In MAPest the joint acceleration was computed by using a Savitzky-Golay filter. Clearly it is not possible in the on-line acquisition case.
Suggestions on how to proceed?
@lucaTagliapietra @francesco-romano @DanielePucci @traversaro

To test (at least in a qualitative way) the modules, we should create a yarpdataplayer-friendly test dataset with the data coming from the experiments done in MAPest.
These data can be used as input and output check for each single module.

Trying to make pairs between the fake links introduced here , we noticed that it it can't make correctly the pairs, for all links. Investigating more, on the code of the human state provider in function static void createEndEffectorsPairs we understood that it guarantees that it will find a pair, but it could not guarantee the minimum distance neighborhood (at least) in the case of adding the fake links. Therefore, we modified the code , such that now it can find minimum distance link pairs (but still I can not guarantee that it always find the minimum distance pair of the links). In any case, I suggest later, we can merge this commit, as it have better performance and more predictable output.

After identifying that the wrench transformation is incorrect https://github.com/dic-iit/component_andy/issues/153#issuecomment-479478038, and after implementing new joint sensor VirtualJointKinSensor in ICub wearables device robotology/wearables#32, in this issue we track the details related to updating the HumanWrenchProvider with the correct information coming from the HumanStateProvider and ICub wearable device to compute the correct wrench tranformation from the hands of the robot to the hands of the human.

• namespace and file system structure (e.g. human namespace)
• PIMPL pattern on the main class

This issues summaries all the activities which should take place after the CoDyCo Y4 demo takes place.
I will put here also issues related to other repositories as they have been uncovered during the development of this project.

Human-Dynamics-Estimation

• make the configuration of priors more scalable. At the current state only the use cases needed by the demo have been implemented.
• move the ROS topic creation into the sources.
• rename every context name: from dynamic to dynamics.
• evaluate the possibility of creating a static library for that part of code that is re-used (for the moment on copy-paste modality) in each module.
• make the RViz code in a more compact structure (and clean eventually useless code/variable).
• add header file in RViz code (for the moment it exists only .cpp).
• modify color scale (green - red) in effort visualization through temperature message.
• fix inverse kinematics issues with 48 DoF model.
• c++ code for generating human model by starting from the template (at this stage we create the model by running the Matlab code). Note: for the creation of the model are required the measurements of the Xsens (coming from mvnx parser) and the position of the sensors (done by the Matlab function computeSuitSensorPosition.m).

YARP

• various IDL issues (see YARP#1132 YARP#1143)
• yarpdataplayer enhancements (for offline processing) see YARP#1144
• New yarp::dev interfaces: IMultipleAnalogSensors (for wholebodydynamics and https://github.com/robotology-playground/forcetorque-yarp-devices) , IFrameProvider (for https://github.com/robotology-playground/xsens-mvn) and IMultipleIMUs (for https://github.com/robotology-playground/xsens-mvn)

iDynTree

• Clear documentation issues (at least in Berdy)
• static-analyser issues (also found by valgrind memcheck)
• Berdy enumerations: extend them to support more information and avoid to spread hardcoded information around

wholebodydynamics YARP device

• Add a clean way to publish external force-torque information to ROS (see https://github.com/robotology/codyco-modules/tree/nomerge/wbd_ros)

Misc

• Add to how-to-document-modules how to publish doxygen documentation automatically by using Travis.
• Benchmark state-provider on iCubGenova04 blades vs iCubGenova02 blade

GIven the last activities of Cleaning HDEv2 we deprecated Human-Dynamics-Estimation version 1.

I think it would be good to take the opportunity to archive all the stale branches in robotology/human-dynamics-estimation that were implemented on top of HDEv1:

• feature/floatingBase
• demo/AnDyY1
• feature/floating_base
• imu_lin_acc_in_y
• human_joint_acc_in_y
• all_accelerations_in_y
• ftShoes_only_human
• clang-format
• release/HDEv2

@Yeshasvitvs @diegoferigo @claudia-lat
Is there any particular concern with any of those branches.

CC @traversaro @DanielePucci

In this module, we need to convert the forces from the robot to the human frames.
We then need the human state (given by human-state-provider) and the robot state just for the joints that we need, that initially we can get using the remotecontrolboardremapper device with the IEncoders interface: http://www.yarp.it/classyarp_1_1dev_1_1IEncoders.html#abcfe10041280b99c7c4384c4fd93a9dd .

The human-dynamics-estimation repo originally contains HDEv1 modules. The recent development of HDEv2 is almost done and in the light of this, it is better to clean up HDEv1 related code. As suggested by @traversaro we can delete the files of HDEv1 as there will not be any support for HDEv1. In this issue, we track the details related to the cleaning of HDEv2 by removing HDEv1 related modules, configuration files, urdf files etc.

@diegoferigo @claudia-lat @lrapetti @DanielePucci

To transform the shoes measurements into human frames we need to known the origin and orientation of two frames:

• the heel frame
• the ankle frame

Even if the heel origin depends on the subject, we can put in the related config file a reasonable position vector like this [-0.04; 0; -0.12] m. This reasonability comes from a previous computation with Matlab.

The human-models repository currently contains the subject number and the subject related data. But we cannot store the file indicating name-subject number on this public repo due to GDPR. So, we need to decide on a proper way to store this file such that any new user who wants to do experiments with HDEv2 will know the exact subject to consider for the urdf and online experiments.

@DanielePucci @claudia-lat @lrapetti @kouroshD @traversaro

This issue highlights some of the observations we made during the demo setups of HDE.

Problem: Yarp network cannot be detected on other machines connected to the xsens router network

Solution: Double check that that yarp namespace is correctly set and see if the ip address of the machine where yarpserver is running is correctly set into the <namespace>.conf file. This typically is of the form ip 10000 yarp. Once this is set correctly, yarp detect will be able to discover the yarp server.

Yarp ports cannot be found

Solution: Typically when the main machine on which yarp server is run is connected to the xsens router after switching the router off and on, the yarp ports of newly launched yarp processes (like wearable devices) cannot be discovered. The likely reason for this is due to the fact that a pre running yarp server on the machine may be used to open the ports and are hence not discovered by the newly setup network. A clean solution to avoid this problem is to restart all the machines to be connected to xsens network everytime the xsens router is turned off and on.

@lrapetti please add other missing details we observed today while setting up for tread mill video

@claudia-lat @DanielePucci

I am implementing the reactive pHRI control laws of AnDy deliverable D4.1 by extending the current standup experiment. In this case, how should the base pose of the human to be considered? I have two questions in this regard

• If I recall correctly, with the current standup experiment setup the transformation from the robot to the human is a fixed transformation. What are the links considered on the robot and the human (e.g., root_link of the robot to pelvis of human??)for this fixed transformation? @claudia-lat @lucaTagliapietra @diegoferigo @DanielePucci

• The human-state-provider module gives the values of baseOriginWRTGlobal , baseOrientationWRTGlobal, baseVelocityWRTGlobal as considered in this thrift file. Which human link is considered as the base link in general and in the current standup experiment particularly? @francesco-romano

The repo has proudly fought in the battle, perhaps it is time to move it to robotology?

cc @drdanz

It happened only once, everything was running happily, however during the stand-up demo the visualized robot model "exploded".
The pelvis was consistent with the real robot movement in both translation and orientation. All the other joints of the robot were following the real device behavior in terms of joint angles. However these parts were not following the translation of the pelvis.

The error visualized on the shell where the visualizer was launched was:

[ERROR] [1512133202.111489858]: Ignoring transform with child_frame_id ""  from authority "unknown_publisher" because frame_id not set

After switching off and on everything it never happened again.

cc: @lucaTagliapietra

I've jotted down a preliminary overview of the YARP modules architecture for the estimation of the dynamics in humans.

I Want to install ROS on Mac (Mojave, Version 10.14) in order to visualize the outcomes of HDE, and in my case human state provider, and I have face several issues.
So I post it here the future issues I will face, later, I will add the issues I faced before and how I solved it.

CC @traversaro @diegoferigo @S-Dafarra @lrapetti @claudia-lat

Currently, we tested HDEv2 with human and with human plus icub in simulation but we have never tried to HDEv2 with human and real robot yet. At the moment we are not clear on how to achieve this because xsens is launched on the windows machine that is connected to xsens router which is isolated from IIT network. So, in case of running HDEv2 with human and real icub, should we change the icub server settings so that it will be connected to xsense router or is there any other cleaner way to do it.

In this issue we track the details related to setting up and running HDEv2 with human and real icub.

@S-Dafarra @traversaro @diegoferigo @lrapetti @kouroshD @claudia-lat

I know that everyone is thinking "let's do that when everything is working", but the state "everything is working" is never actually reached, so it is better to write the README as soon as possible.

A nice example of repo README is for example : https://github.com/robotology/superquadric-model .

Things that need to be in the README:

• Dependencies,
• Links to papers,
• Installation procedure (perhaps mentioning the codyco-superbuild or whetever method we will recommend to install the software).
• AppVeyor and Travis badges (see https://github.com/robotology/idyntree ) .

The idea is to have a visualizer for the realtime estimates of joint position, joint torques and external force-torques for both the iCub robot and the humans involved in the Y4 Demo.

The visualization tool used will be RViz (http://wiki.ros.org/rviz).

The estimation results will be published on ROS topics by something (the estimation architecture needs to be defined), using the following ROS types:

• http://docs.ros.org/api/sensor_msgs/html/msg/JointState.html for joint position and torques (in ros jargon, effort),
• http://docs.ros.org/jade/api/geometry_msgs/html/msg/WrenchStamped.html for force plate and external force-torques ,
• http://wiki.ros.org/tf for the relative position between the robot and the human .

The following RViz plugin will be used for visualization:

• http://wiki.ros.org/rviz/DisplayTypes/Effort
• http://wiki.ros.org/rviz/DisplayTypes/Wrench

The ROS topics will be pubblished by the estimation part using the ROS/YARP integration documented in http://www.yarp.it/yarp_with_ros.html , to make sure that the estimation part does not depend in any way on ROS and can be run easily in Windows/macOS/Linux .

cc @MartaLorenzini @diegoferigo

Currently, the teleoperation code base is aligned to work with pairwise IK of HumanStateProvider with some modifications to handle the fake links added to robot model. The updates of integration based IK in HumanStateProvider diverged with respect to the changes done for teleoperation code. After updating the master to HDEv2, we created a new branch feature/teleoperation to align the changes in HumanStateProvider from both integration based IK and teleoperation.

@kouroshD please update the details related to rebasing order for the code alignment

CC @DanielePucci @lrapetti @traversaro @diegoferigo

@diegoferigo & @francesco-romano ?

It seems after docker images

As soon as the repo-structure is merged in master, we should add AppVeyor and Travis integration to make sure that the repo is always correctly compiling.

I think it make sense that we add as soon as possible this repo to codyco-superbuild.

The recent data dump from the online HDE with FT shoes online has ports from HDE and FT shoes in different directories. If all of this data dump is played using yarpdataplayer only the HDE ports are streamed but not the FT ports. But if the directories are separated and played in different yarpdataplayers, all the ports are streamed correctly. This problem is observed once and has to be tested more to be sure. After that the issue can be opened in yarp

Currently hde-readonly-controlboard is not compatible with new HDEv2. In this issue we track the details related to updating it to be compatible with taking joint position, velocity and acceleration data coming from HumanStateProvider and joint torque data coming from HumanDynamicsEstimator to pass the data to matlab simulink

@lrapetti

I report below the steps I'm working on in order to accomplish the third bullet point of Issue #15.

• Find an XML library that could potentially be included in YARP with SAX and Schema Validation support, and a proper license
• Try validating the mvnx file with the schema.xsd provided by Xsens
• Write a SAX parser for XML (mandatory due to the big size of the mvnx file), DOM is not efficient in this case
• Parse a mvnx file inheriting the new XML class
• Ship this feature in a YARP driver

The headers refer to LGPL2+ license, but the repo does not contain a LICENSE.* file. I think you can refer to the blockfactory repo for an example of a repo licensed under LGPL2+.

We decided to use the wiki pages for documenting the HDE usage, which can help a new user to get started quickly. Unfortunately the current possible way to use images, as suggested by github, is to upload the images to the repo and use the url. As @traversaro pointed out this is not a clean solution for a public repository like human-dynamics-estimation, particularly when the amount of images and their sizes are large. An alternative way is considered here, which uses the idea that a wiki of a git repository is itself a git repository. So, in case of future changes to be done for the wiki pages, an user has to clone the wiki repo and add the new images to it and then they can be used in the wiki pages.

@claudia-lat @diegoferigo @lrapetti

This happened just before the codyco year 4 demo and the day before.

I got the following segfault while trying to run yarprobotinterface for a Gazebo 7 simulation:

Below the responsible piece of code, and here the link to the line reported by valgrind:

295 void ControlBoardSubControlBoardAxesDecomposition::fillCompleteJointVectorFromSubControlBoardBuffers(int* full, const RemappedControlBoards& remappedControlBoards)
296 {
297    for(size_t ctrlBrd=0; ctrlBrd < remappedControlBoards.getNrOfSubControlBoards(); ctrlBrd++)
298   {
299        m_counterForControlBoard[ctrlBrd] = 0;
300    }
301
302    for(int j=0; j < m_nrOfControlledAxesInRemappedCtrlBrd; j++)
303    {
304        size_t subIndex=remappedControlBoards.lut[j].subControlBoardIndex;
305        full[j] = m_bufferForSubControlBoardControlModes[subIndex][m_counterForControlBoard[subIndex]];
306        m_counterForControlBoard[subIndex]++;
307    }
308 }

Steps for reproducing the segfault:

yarpserver &
gazebo &
YARP_ROBOT_NAME="icubGazeboSim" yarprobotinterface --config launch-wholebodydynamics.xml

Eventually, I'm not sure if the yarprobotinterface output could be relevant:

TcpConnector::connect fail: Connection refused
Connect [handle=48] at 172.18.0.4:16679
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/right_arm/stateExt:o to /wholeBodyDynamics/right_arm/stateExt:i
 * query "/wholeBodyDynamics/r_leg_ft_sensor"
 * query "/wholeBodyDynamics/left_leg/stateExt:i"
TcpConnector::connect fail: Connection refused
Connect [handle=56] at 172.18.0.4:21031
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/right_leg/analog:o to /wholeBodyDynamics/r_leg_ft_sensor
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:17447
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/left_leg/stateExt:o to /wholeBodyDynamics/left_leg/stateExt:i
 * query "/wholeBodyDynamics/right_leg/stateExt:i"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:18215
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/right_leg/stateExt:o to /wholeBodyDynamics/right_leg/stateExt:i
 * query "/wholeBodyDynamics/l_arm_ft_sensor"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:19495
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/left_arm/analog:o to /wholeBodyDynamics/l_arm_ft_sensor
 * query "/wholeBodyDynamics/l_foot_ft_sensor"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:21543
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/left_foot/analog:o to /wholeBodyDynamics/l_foot_ft_sensor
 * query "/wholeBodyDynamics/head/stateExt:i"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:18983
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/head/stateExt:o to /wholeBodyDynamics/head/stateExt:i
 * query "/wholeBodyDynamics/r_arm_ft_sensor"
 * query "/wholeBodyDynamics/torso/stateExt:i"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:20007
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/right_arm/analog:o to /wholeBodyDynamics/r_arm_ft_sensor
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:15143
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/torso/stateExt:o to /wholeBodyDynamics/torso/stateExt:i
 * query "/wholeBodyDynamics/r_foot_ft_sensor"
 * query "/wholeBodyDynamics/imu"
TcpConnector::connect fail: Connection refused
Connect [handle=51] at 172.18.0.4:19239
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/inertial to /wholeBodyDynamics/imu
TcpConnector::connect fail: Connection refused
Connect [handle=56] at 172.18.0.4:22055
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/right_foot/analog:o to /wholeBodyDynamics/r_foot_ft_sensor
 * query "/wholeBodyDynamics/l_leg_ft_sensor"
 * query "/wholeBodyDynamics/left_arm/stateExt:i"
TcpConnector::connect fail: Connection refused
Connect [handle=48] at 172.18.0.4:20519
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/left_leg/analog:o to /wholeBodyDynamics/l_leg_ft_sensor
TcpConnector::connect fail: Connection refused
Connect [handle=48] at 172.18.0.4:15911
yarp: SocketTwoWayStream::updateAddresses failed getting local address
yarp: Removing output from /icubSim/left_arm/stateExt:o to /wholeBodyDynamics/left_arm/stateExt:i

cc @francesco-romano @traversaro

Missing documentation:

• How to publish the right JointState topic from the robot, see the last 4 commits in https://github.com/francesco-romano/robots-configuration/commits/icub_ros .

We need to understand how to handle the human subject URDF files.

Eventually we will need to handle a high number of subject specific URDF files, but for the time being I think we can agree that for the CoDyCo Y4 demo we will just use 2 or 3 URDF models that we will commit to the repo.

However we need to make sure that the URDF that we install can be found by RViz for visualization purposes and by the YARP modules for estimation purposes . For ROS use, the URDF files need to be contained in a so-called ROS Package, while for YARP use we are quite free because we write the code that finds the URDF file.

In the end, we should be able to install the models in a known location, that can be found by ROS as a package and by our software, without using software that is not available on Windows. The classical way of installing ROS Packages is to use catkin, but this is not viable for us because we need to support Windows.

see https://github.com/robotology/robots-configuration/blob/devel/iCubGenova04/wrappers/motorControl/right_leg-mc_wrapper.xml#L21 vs https://github.com/francesco-romano/robots-configuration/blob/764949bba9316e43d846132e7e4d59414351102d/iCubGenova04/wrappers/motorControl/right_leg-mc_wrapper.xml#L21

As agreed f2f, the first piece of code that @MartaLorenzini will contribute to this repo is the xsens-tf-bridge , that will connect to the xsens driver available at https://github.com/francesco-romano/xsens-mvn and will publish this information in a way such that it can be visualized on RViz .

Open questions for which I will be happy to hear any feedback:

• Location: do you agree with keeping the visualizer code here? I think avoiding having too many repository makes sense.
• Structure: we need to store somewhere the xsens-tf-bridge. I think it make sense to add a visualization folder in the root of the repo, and then put a folder containing xsens-tf-bridge inside the visualization folder.

The xsens-tf-bridge will be implemented as a classical (single threaded) yarp::os::RFModule .

While the inverse kinematics successfully manages to obtain the joint configuration for the full 66 DoF model (i.e. 22 joints of 3 DoF each), when we use the simplified model the IK sometimes fails to obtain a reasonable solution, not only quantitative speaking, but also qualitative speaking, see attached gif

We should create substitutes of the YARP device drivers to be used in offline processing.

After a discussion with @diegoferigo @traversaro we came out with the following ideas:

• AMTI: ports dumped by the yarpdatadumper are enough.
• robot: we'd like to create a new read-only device (i.e. it provides only data and does not accept any command, e.g. implements only IEncoders, etc, and does not implement IPositionControl) which does not automatically connect at startup and just opens the needed ports.
• Xsens: we create a copy of xsens_mvn_remote driver which implements only IFrameProvider to provide streaming data. It also opens a partial .mvnx file with only the information about the model structure (segments, sensors, etc) to provide this kind of information.

Of course the streaming data will be provided by the pair yarpdatadumper/yarpdataplayer.
All the modules (in this repo at least) will need to be able to know which driver open depending on the online/offline mode.

This code

Eigen::SparseMatrix<double, Eigen::RowMajor> A(5,5);
Eigen::SparseVector<double> res(5);
Eigen::SparseVector<double> b(5);
Eigen::SimplicialLLT<Eigen::SparseMatrix<double, Eigen::RowMajor> > dec;
dec.compute(A);
res = dec.solve(b);

does not compile with the following error:

Showing All Issues
/usr/local/include/eigen3/Eigen/src/SparseCholesky/SimplicialCholesky.h:283:60: No matching conversion for functional-style cast from 'const AdjointReturnType' (aka 'const Eigen::Transpose<const Eigen::SparseMatrix<double, 1, int> >') to 'MatrixU' (aka 'TriangularView<const Eigen::Transpose<const Eigen::SparseMatrix<double, 0, int> >, Eigen::Upper>')

while this code successfully compiles:

Eigen::SparseMatrix<double, Eigen::ColMajor> A(5,5);
Eigen::SparseVector<double> res(5);
Eigen::SparseVector<double> b(5);
Eigen::SimplicialLLT<Eigen::SparseMatrix<double, Eigen::ColMajor> > dec;
dec.compute(A);
res = dec.solve(b);

While waiting for column major ordering implementation in iDynTree or more information from eigen (upstream) we switch to LU.

See https://github.com/robotology-playground/human-dynamics-estimation/blob/master/human-state-provider/CMakeLists.txt#L8 .

cc @lucaTagliapietra

When I wanted to install the HDE from this branch (which soon will be merged to the master branch) I faced the following issues:

• I had errors regarding the unorder_map: the compiler was gcc-5 for Ubuntu 16.04, and we upgrade the compiler to gcc-7, and it compiles fine.

• There were problems with eigen3 in humanStateProvide.cpp, we add SYSTEM PRIVATE ${EIGEN3_INCLUDE_DIR} the following lines of the /devices/HumanStateProvider/CMakeLists.txt target_include_directories(HumanStateProvider PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>) and the problem is resolved.

• In HumanDynamicsEstimator.cpp, if we substitute #include <Eigen/SparseCholesky> with #include <eigen3/Eigen/SparseCholesky> , the compiler will not throw warnings anymore.

cc @Yeshasvitvs @lrapetti