Gravity Force Removal of FT Readings #709
-
Hello everyone! I am trying to remove the gravitational component of the readings of the FT sensor in the arm. In order to do that I tried two different ways: The first way was by initializing a force vector in the 0th frame as a gravity force vector. As in the 0th frame, the vertical axis is the x-axis points upwards, the gravity force vector along this axis would be equal to -g*(sum of all links mass). Then, a force in the FT sensor frame is computed using the second example of instantiation of the module iDynInv available at https://robotology.github.io/robotology-documentation/doc/html/group__iDynInv.html. The second way was by using the method available at https://robotology.github.io/robotology-documentation/doc/html/idyn_one_chain_tutorial.html, where a force vector is initialized with all zeros in the end effector and also lin_acc[2] = 9.81. Of course I complemented this methods by obtaining the force in the sensor link, as it is made in the method shown above:
I used a simulator in gazebo where I can change the joint angles of the iCub, such as the shoulder pitch. The robot is not doing any activity, just standing. The goal was that the force obtained by the methods shown above would match the force obtained by the FT plugin but that did not happen. What can I be doing wrong? Does anyone have suggestions of what may be making this conversion of forces not possible? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
The dynamic model provided in Anyhow or computing the FT measure induced by gravity, I strongly suggested to use instead The main advantage of using iDynTree is that if you are simulating a given simulation model in Gazebo, you can ensure that exactly the same URDF loaded in Gazebo is loaded also in iDynTree by setting appropriately the std::string modelAbsolutePath = yarp::os::ResourceFinder::getResourceFinderSingleton().findFileByName("model.urdf");
iDynTree::KinDynComputations kinDynComp;
kinDynComp.loadRobotModel(modelAbsolutePath); If you share more info (the simulation model you are using, the rest of your C++ code) I will be happy to provide more inputs. |
Beta Was this translation helpful? Give feedback.
-
Hello @traversaro !! Thank you so much for your quick and helpful answer, I already tried to implement it loading my robot model, however I have a doubt regarding which link to choose, just like what is made in https://github.com/robotology/idyntree/blob/bf15223cb6793c5a54bf367bc996243f9185f0a3/examples/matlab/SixAxisFTOffsetEstimation/SixAxisFTOffsetEstimation.m#L43, where the sole is chosen. If it helps, I can say as well that the model of the robot that I am using is derived from the iCubGazeboV2_5_visuomanip, being the only modifications the addition of the arm FT plugins and skin plugins. I have also other doubt that is regarding the joints position, velocity and acceleration. Is it supposed to be only composed of zeros just like in https://github.com/robotology/idyntree/blob/bf15223cb6793c5a54bf367bc996243f9185f0a3/examples/matlab/SixAxisFTOffsetEstimation/SixAxisFTOffsetEstimation.m#L30? Thank you for all the help! |
Beta Was this translation helpful? Give feedback.
-
Hello @traversaro ! I already implemented the necessary code to extract the gravitational component of the right arm FT sensor measurements however the results I am obtaining are not the best, having some differences:
being Flido the values read from the FT sensor and Fgravity the values obtained using this iDynTree methods. Below I will leave you with the code I am using and if you could take a look to see what I am doing wrong it would really help: Here are the initialization of the joint position, velocity and acceleration arrays and also grav_idyn: https://github.com/diogofbsilva/forceConv/blob/e772f018fb8b46a8cafcab072e8416a0b0306030/forceConv.cpp#L269-L280 Finally here is the rest of the code: https://github.com/diogofbsilva/forceConv/blob/e772f018fb8b46a8cafcab072e8416a0b0306030/forceConv.cpp#L421-L480 Look that I am updating the joint position vector qj with data from the port /icubSim/right_arm/state:o. Note: This repo is not where I am simulating Is there something I am doing wrong? Thank you! |
Beta Was this translation helpful? Give feedback.
-
Hello @traversaro !! Thank you so much! |
Beta Was this translation helpful? Give feedback.
In https://github.com/diogofbsilva/forceConv/blob/e772f018fb8b46a8cafcab072e8416a0b0306030/forceConv.cpp#L348 seems to me that you are trying to set the gravity for the link "torso", but there is no "torso" link in your URDF model? In general, I suggest to check the return values for the functiosn that you call, to understand if they were successful or not.
Furthermore, in https://github.com/diogofbsilva/forceConv/blob/e772f018fb8b46a8cafcab072e8416a0b0306030/forceConv.cpp#L423-L425 you seem to assume that the joint serialization used for the visuomanip model is the one that matches the right arm (at least for the initial joints) but that is not ensure in anyway. To read data from a real …