Open ndehio opened 4 years ago
Hi @ndehio ,
i think i ran in the same problem when i get close to a certain configuration:
I can reproduce this problem every time i execute a certain trajectory. If you have any news/found any solution for this problem i would appreciate your inputs!
Cordially,
Kevin Desormeaux.
You can easily compute the jacobian pseudoinverse via SVD or QRD yourself and derive the end-effector wrench given the joint torques. So, you don't need to rely on this strange libfranka behavior. Maybe you want to have a look at my PhD dissertation, see equations 2.8, 4.7, 4.11 and appendix B https://core.ac.uk/reader/196653490 Feel free to cite it if it helps ;-)
I am controlling my panda (version 4.0.2) via the libfranka interface. Evaluating the robot's state, I noticed that the (estimated) endeffector wrench (see methods K_F_ext_hat_K and O_F_ext_hat_K) sometimes contains only zeros: [0,0,0,0,0,0]. This effect appears for both our two pandas and both for applying velocity-control and torque-control.
I understand that the problematic wrench estimation relates to singularities: it is not possible to infer the full wrench from joint torque measurements if the jacobian becomes rank-deficient, due to the required pseudoinverse. According to my experience, libfranka uses a threshold of 0.08 for the smallest singular value when outputting the zero wrench.
Please add the following features:
However, even in singularities it is possible to compute/estimate a "reduced" end-effector wrench (the wrench estimation is of course missing one Cartesian direction, related to the small singular value). Why don't you provide this one in the robot state? I don't see a need to zero the entire wrench...
For those who are curios, here are two exemplary joint configurations that result in zero end-effector wrench: [1.03634,0.715631,0.222965,-0.620327,0.112605,2.93128,2.06283] and [0.0300161,0.483728,-0.195585,-0.612593,-0.0135165,1.30887,2.04615]