Compensate friction using reference joint velocities

[andreadelprete]

Currently, friction compensation is based on the estimated joint velocities, which we compute using finite differences and low-pass filtering. This gives us a delayed and noisy estimation of the joint velocities, thus deteriorating the quality of the friction compensation. This is especially critical for Coulomb friction (proportional to velocity sign), which we cannot compensate exactly in the zone around zero velocity because it could lead to vibrations and then instability.

An interesting alternative would be to use the reference joint velocities to compensate for friction. While on one side reference velocities may significantly differ from the real velocities, thus introducing errors in the friction compensation, on the other side reference velocities are not subject to noise or delay.

The main issue is probably the fact that our inverse dynamics controller computes desired joint accelerations, but not velocities. Integrating these accelerations we could get reference velocities, but this would have an integral effect in the control, killing its compliance: as long as the task errors are not zero, the desired accelerations are not zero, and so their integral keeps increasing.

The only (expensive) solution I can see at this moment is to solve a second QP in which all task gains are set to zero. This would generate joint accelerations that go to zero as soon as the reference trajectories for the different tasks come to a rest, thus avoiding the above-mentioned integral effect. The problem with this approach is that we should solve two QPs at each control cycle rather than one, which is quite expensive in terms of computation time. Alternative solutions are welcome!

[andreadelprete]

A few days ago we tested this idea on a single joint and it works really well. However, it doesn't seem trivial to apply it in the case of task-space inverse-dynamics control because it is not clear if the idea detailed in the previous post would work well in practice (besides the obvious computational complexity issues).

[TJBetter]

Hello @andreadelprete, thanks for this really great post (and this repo). I wonder if you have make any progress in compensating friction since the last post?

Thank you.

[andreadelprete]

Hi @TJBetter , glad you appreciate it. Unfortunately I have left the Gepetto team at the end of 2017, and I haven't worked on friction compensation since then, therefore the answer is no.