For everyone wondering about order of magnitude for Friction Parameters

[kingjin94]

If you compare the friction parameters identified for Panda with those of previous robots such as the Kuka LWR (Here: http://dx.doi.org/10.3182/20140824-6-ZA-1003.01079) or the Stäubli TX-90 (here: http://dx.doi.org/10.1016/j.rcim.2014.06.004) you might wonder why the panda has 1 to 2 orders of magnitude less friction (e.g. Panda joint 1: 0.2450 coulomb friction and 0.0665 viscous friction vs. the kuka's joint 1 with 11.6 and 14.4 according to Model C).

These are considerable differences as they dominate the required torques in simulation for the Kuka and Stäubli but are almost negligible for the Panda. If you want to compare energy consumption for a trajectory that might throw you of quite a bit.

My theory is that the Panda was only identified after the link side torque sensor so most of the friction in the motor and gearing was already compensated and hidden by the libfranka controller. Am I right in that assumption?

[marcocognetti]

Hello, I suggest you ask this question to my colleagues that worked more in detail on the friction model : Alexander Oliva: a.a.oliva@tue.nl, Claudio Gaz : c.gaz@kingston.ac.uk. Kind regards, Marco

[Bargez908]

My theory is that the Panda was only identified after the link side torque sensor so most of the friction in the motor and gearing was already compensated and hidden by the libfranka controller. Am I right in that assumption?

Did you find out anything about this? I tried to use those values on mujoco and gazebo but as you said the friction is almost negligible.

[aaoliva]

Hi kingjin94, Bargez908

There are two sources of friction, the motor-side (motor + gearing friction) and the link-side (mainly due to the bearings).
In our work, we have identified the link-side friction, as we have used the link-side torque sensor measurements, as correctly assumed kingjin94. The libfranka runs a friction observer internally that compensates for (most) of the motor-side friction, which is dominant with respect to the link-side friction. However, the motor-side friction is not fully compensated, because the friction observer works like a low-pass filter which introduces a delay in the friction estimation. Fully compensating for the estimated (delayed) friction may inject energy into the system, causing limit cycles or even making the system unstable. The link-side friction compensation we proposed helps to mitigate the problem but it does not compensate for the remaining motor-side effects (which by the way, is not accessible from the libfranka API).

Hope this helps.