Deprecate CFM and ERP in favor of k_p and k_d?

[brettle]

The How to Use ERP and CFM section of the ODE manual, mentions that there is a one-to-one relationship between $(h, ERP, CFM)$ where $h$ is step size, and $(k_p, k_d)$ where $k_p$ is the spring constant and $k_d$ is the damping constant associated with a joint. Since $k_p$ and $k_d$ have more physical meaning, should the various $ERP$ and $CFM$ fields be deprecated in favor of $k_p$ and $k_d$ fields that webots could use (in combination with the step size) to calculate the $ERP$ and $CFM$ values to pass to ODE? This would eliminate the need to adjust $ERP$ and $CFM$ if step size is adjusted.

In addition, could the default $k_d$ be the critical damping constant associated with the provided $k_p$ and the masses of the solids associated with the joint? The hope is that doing so would improve simulation stability, especially across ranges of masses. I get that the critical $k_d$ would be $2 \sqrt{k_p m_1 m_2 / (m_1+m_2)}$.

Taken together, these changes might greatly reduce the time and complexity associated with tuning a simulation. Ideally, users would only need to choose $k_p$ to control the stiffness of the bodies and a time step $h$ to control the speed and accuracy of the simulation.

Has anyone already looked into this? If it's worth pursuing, are there existing worlds that would make good test cases (e.g. have required tuning ERP and CFM)?

[brettle]

On a related note, I don't think it makes sense for ERP and CFM (or $k_p$ and $k_d$) to be the same for HingeJoint and Hinge2Joint stops as it is elsewhere. The units aren't the same. For example $k_p$ is Nm/radian vs N/m.

[omichel]

We never investigated this idea. We originally decided to make a simple mapping of the ODE parameters. But your proposal is very sound and could make the life of user way simpler. For example, we had many users complaining about heavy objects sinking into the ground. So, I believe we could give a shot to this and try to implement it as it doesn't seem difficult to achieve.

In a first step, we could keep the ERP/CFM exposed, but add the stiffness along with them. If the stiffness is set to any value different from -1 (assuming -1 is a meaningless value), we could use it and ignore the ERP/CFM. That would have the advantage of not breaking the backwards compatibility and would allow us to migrate to the new system smoothly if it turns out to be useful.

World files with heavy objects, such as vehicles: cars, trucks, etc. are good candidates to test this approach, as they often require tuning the ERP/CFM. You may also search the world and proto files for non-default ERP/CFM values to identify interesting use-cases.

[ShuffleWire]

I would be an happy user of that use-case (ie heavy object) since I'm working with 4tonnes and more vehicles, for which I had to fine tune parameters. I'm getting close to good value, but this is very try-(die!)-retry methodology... And I still have issue with those parameters...
So I would be very interested xD
Will keep an eye on it