resibots / inria_wbc

Generic whole-body controller based on quadratic programming
14 stars 0 forks source link

Add closed-loop torque control #41

Closed jbmouret closed 3 years ago

jbmouret commented 3 years ago

this requires the yaml-node branch

jbmouret commented 3 years ago

@dalinel @ivanbergonzani should we merge this?

ibergonzani commented 3 years ago

works fine. minor thing: maybe use IWBC ASSERT in case of torque actuation and not closed_loop.

dalinel commented 3 years ago

Tests are failing in torque mode: Talos becomes unstable when pushed Ex : ./test_controller_graphics -a torque -b ../etc/arm.yaml --closed_loop -p 1

It seems that the closed loop makes the qp instable with high model vs reality discrapencies

jbmouret commented 3 years ago

... but this would not a problem of our implementation, right? I think we should simply remove this from the tests if we know they fail.

dalinel commented 3 years ago

Yes I agree it is not an implementation problem, I will modify the tests

dalinel commented 3 years ago

Tests are fine now In my opinion this is ready to merge

jbmouret commented 3 years ago

Did we update the test_project? should we?

ibergonzani commented 3 years ago

example project ris running fine to me, as test_controller and test behaviors

just one question: why use 1/sim_freq instead of 1/control_freq for the spd command computation ?

other than that, I think everything is ready to merge

jbmouret commented 3 years ago

Good question :) The idea is that the SPD should make a correction at each time-step of the simulation since that it is not in the control loop. It's like running 1Khz PIDs with a 500Hz QP controller.

If we do not do this, then the SPD will compute a torque for 500Hz but it will be called 2 times (so a correction that is too high) or will be called only once then have a torque = 0 (so not what we want either)

dalinel commented 3 years ago

I think that in this case, calling the spd controller several times is close to what we have on the real robot So I think we can keep this and if we find a better solution we can implement it in a later PR