k_velocity has value of 0 in safety_controller, limiting effort commands to 0

[JohnTGZ]

Within urdf/ur_macro.xacro and other parts of the file, the k_velocity is defined as 0. As a result, if we enable the safety_controller and use the effort interface of the UR robot, the effort command sent to the hardware_interface will be limited to 0.0.
This is because enabling the safety_controller results in the use of soft joint limits where the k_velocity parameter is used to calculate the soft effort limits here with the following code section copied here:

      soft_min_eff = std::clamp(
        -soft_joint_limits.k_velocity * (actual.velocity.value() - soft_min_vel),
        -hard_limits.max_effort, hard_limits.max_effort);

      soft_max_eff = std::clamp(
        -soft_joint_limits.k_velocity * (actual.velocity.value() - soft_max_vel),
        -hard_limits.max_effort, hard_limits.max_effort);

In order to use the safety_controller with effort interfaces, we will need to set k_velocity to an appropriate value. However, it is not immediately obvious what this value should be from the relationships between actual velocity, velocity limit and the effort limit.

[urfeex]

Thank you for pointing that out, we will look into this. Just out of curiosity: Which safety_controller are you talking about? I understand it is a custom implementation using the soft effort limits from the joint_soft_limiter.

Edit: The hardcoded 0.0 definitively comes from a time where we didn't have a joint effort interface. Now that we have it we need to expose it with a somewhat sane default value. I'll mark this as a bug.

Edit 2:
To answer your question: Tuning this might actually depend on the safety margin that you want to configure for your application. The lower the value, the earlier the limiter will start clamping the effort command. Having this value at infinity would effectively always clamp to min_effort / max_effort. That way it could happen that the velocity limits get violated. Having a lower value will enforce an effort limit smaller than the maximum limit.

For example, if your max velocity is 2 rad/sec and the joint is currently moving at 1.8 rad/sec and k_velocity is at 100, the maximum torque would be at 20 Nm ($$-100~\frac{Nm}{rad/sec} * (1.8-2)~rad/sec$$). If the current velocity is at 0, the maximum torque would be 200 Nm. With that calculation either this value or the max joint effort is used to clamp the effort command. (Similar for negative limits).

Keep in mind that the underlying controller on the hardware will have similar methods, so the torque commands sent to the joints might be lower than what you want to achieve, anyway.

[JohnTGZ]

I see, thank you for the very detailed explanation, I think I better understand what is the effect of this k_velocity parameter now. It is primarily used to limit the torque when the joint velocities are near it's specified limits, and it's magnitude affects the safety margin.

Thank you for pointing that out, we will look into this. Just out of curiosity: Which safety_controller are you talking about? I understand it is a custom implementation using the soft effort limits from the joint_soft_limiter.

The safety_controller I was referring to is joint_limits::JointSoftLimiter from ros2_controls (link). I believe that the <safety_controller> tag within the ros2_controls URDF will use this by default.