Open giotherobot opened 8 months ago
With Kp=1000
ergoCub is able to stay upright:
Just to write it down otherwise I forget it, a basic sim2real step (that probably we can do in a second step) is to align the Kp used for position control with the one used on the real robot. Disregarding friction effects, it should boils down to get the gains used on the real robot, and convert their units (accounting for the motor K_t current/torque gain and transmission ration) to the one used in MuJoCo . Francesco Romano (a former member of the lab) did that some time ago for Gazebo, but I can't remember where that code is.
https://github.com/ami-iit/element_llm-task-planner/issues/34#issuecomment-1983422432
For reference @traversaro
Just to write it down otherwise I forget it, a basic sim2real step (that probably we can do in a second step) is to align the Kp used for position control with the one used on the real robot. Disregarding friction effects, it should boils down to get the gains used on the real robot, and convert their units (accounting for the motor K_t current/torque gain and transmission ration) to the one used in MuJoCo . Francesco Romano (a former member of the lab) did that some time ago for Gazebo, but I can't remember where that code is.
For reference @traversaro
I can't find that code unfortunately.
Regardless of the units conversion, where can I find the gains of the gazebo controllers or the oens used in the robot?
Sure! Let's use the ergoCub l_knee
as an example. In both Gazebo Classic and Modern GAzebo, its gains are contained in https://github.com/icub-tech-iit/ergocub-software/blob/2b3dff9b264a7fac89e9608d5e4e40dd24fcba21/urdf/ergoCub/conf/gazebo_ergocub_left_leg.ini#L20. The unit of those values are Nm/[deg] for Kp, and similar units (but with a s somewhere) for Ki and Kd, see https://github.com/robotology/gz-sim-yarp-plugins/blob/1c38e89a3303d987bae80e3b58c296b14105ee86/plugins/controlboard/src/ControlBoard.cpp#L447 and https://github.com/robotology/gz-sim-yarp-plugins/blob/1c38e89a3303d987bae80e3b58c296b14105ee86/plugins/controlboard/src/ControlBoard.cpp#L600-L604 for more details or ask to @xela-95 .
For what regards the real robot, it is a bit more complex. First of all, there are different ways for controlling in position the robot, depending on the output of the position controller, if the output of the position controller is current (that is then sent to a low level current control loop) or PWM (that is directly sent to the motor). The gains for the ergoCubSN001
motor (the one used in IIT robot arena as of April 2024). From https://github.com/ami-iit/robots-configuration/blob/9849c5617ab1528a92ba1193e47496a403aa2724/ergoCubSN001/hardware/mechanicals/left_leg-eb8-j0_3-mec.xml#L9 you get that l_knee
is the fourth axis (i.e. with index 3) of the eb8-j0_3
board. From https://github.com/ami-iit/robots-configuration/blob/9849c5617ab1528a92ba1193e47496a403aa2724/ergoCubSN001/hardware/motorControl/left_leg-eb8-j0_3-mc.xml#L46-L57 it seems that the position loop uses pwm
as output, but I am not sure about this. However, assuming that pwm
is indeed the right one, we need to understand:
metric_units
, but I guess we need to double check this.So, assuming that k_p units is [PWMUnit]/[deg], probably we need to find a k_tau (and a transmission ratio, depending on how k_tau
is defined) for which we need to multiply the gains. I guess we can either ask to @isorrentino and @GiulioRomualdi, or directly ask a question in https://github.com/robotology/community where people from iCub Tech can reply, thanks!
A possible starting point could be https://github.com/ami-iit/element_sensorless-torque-control/issues/114
A possible starting point could be ami-iit/element_sensorless-torque-control#114
Thanks! @isorrentino what is the unit of the ktau in https://github.com/ami-iit/element_sensorless-torque-control/issues/114#issuecomment-1948247808 ? Nm/A, Nm/PWMUnit or something else? Are those Ktau also accounting for the transmission ratio?
Back in time we started an effort to convert the gains from pwm
to metric
. I can't seem to find the issue at the moment, but I remember using an Excel file to convert the gains, so there should be a fixed conversion rule. The problem back in time was that the converted gains worked terribly (we thought about an accuracy issue at the FW level since in metric
the numbers were much lower), so we never switched to metric
.
I can't seem to find the issue at the moment
Found it! https://github.com/ami-iit/component_wholebody-teleoperation/issues/57 (again the importance of documenting things)
Related comment: https://github.com/ami-iit/element_llm-task-planner/issues/71#issuecomment-2111889796
The tuning of the actuator is important for the stability of the simulations.
This can be moved to https://github.com/ami-iit/mujoco-urdf-loader
For now all the actuators in the model have common parameters (
kp=100
).It would be better to tune these.