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

[brettle]

@omichel, I'm considering taking a shot at this. Should the PR target develop or master? Strictly speaking I suppose it would be a new feature, but it's designed to provide a fix for the arguably buggy current behavior. Also it should be very low risk, since it would be backward-compatible and only have an effect if k_p is actually set.

[omichel]

I believe we should target the develop branch with such a change as it actually introduces a new feature, that aims at replacing a design weakness. We are not fixing a bug here.

[brettle]

After further investigation, instead of $k_p$, I propose adding a softIndent property to ContactProperties. If positive, the value would represent the desired amount (in meters) that a Solid (of any mass) resting on a floor under standard gravity should sink into the floor. I can use that to compute a $k_p$ (which varies with the mass and the number of contact points) and the associated critical $k_d$. Those can then be used (along with the time step) to compute ERP and CFM.

I believe a softIndent of 0.001 (ie 1mm) should provide reasonable behavior across a wide range of masses with the default 32ms time step. Smaller values of softIndent will likely require somewhat smaller time steps to avoid simulation instabilities (e.g. jittering), but the time step only needs to decrease in proportion to the square root of the amount that softIndent decreases. So, for example, if a softIndent of 1e-5 (i.e. 0.01mm) is desired, then a time step of 3.2ms will probably be stable.

Anyway, the idea is that softIndent corresponds more closely to something that the user actually cares about (i.e. spatial accuracy) and a single value is likely to work across a very wide range of applications.

Thoughts welcome.

[brettle]

There is an additional wrinkle that applies to both the softIndent option and the $k_p$ option. In both cases, the masses of the contacting Solids is used to compute the ERP and CFM. However, the relevant masses are often not that simple. Consider a robot with 4 wheels that are touching the floor. The correct mass to use at the contact between one of the wheels and the floor is the 1/4 of the mass of the entire robot, not the mass of one of the wheels. Reliably determining the correct mass automatically doesn't seem feasible in the general case of a robot with an arbitrarily complex set of joints.

To address this, I propose adding mass1 and mass2 properties to ContactProperties. If positive, they would be substituted for the mass of the Solid with the corresponding material at the contact when calculating ERP and CFM for the contact joint.

[omichel]

I believe that multiplicating the number of parameters doesn't sound like a move towards more simplification... This will require documenting these extra parameters and may yield to some confusion for users... The original idea sounded great to me. but with these extra parameters, it is not that great... However, I don't have a better idea to suggest.

[brettle]

I now believe I've found a way to implement the softIndent idea without needing the additional mass1 and mass2 fields. I believe I can use the inverses of the "effective" masses that ODE already calculates in the form of $J M^{-1} J^T$.

Moreover, this approach can be used for all joints, not just contact joints. So I propose adding an indent field to WorldInfo that would be used to compute the world's ERP and CFM.

[brettle]

I also believe there is a natural "optimal" value for indent and (softndent) of 4*gravity*basicTimeStep^2/pi^2. I believe that value is the smallest indent that can be achieved at the minimum damping time constant needed to ensure stability. For default values of gravity and basicTimeStep that yields an indent of about 4.07mm, which might be acceptable for human-sized robots.

How would folks feel about making the default behavior to use that value for indent, and thus to compute ERP, CFM, softERP, and softCFM from it? If a user desired a different amount of indent, they could either set it directly, or they could change it by changing the basicTimeStep. If they want the current default behavior (or they want explicit control over ERP and CFM) they would need to set them explicitly.

Side note: Reducing the basicTimeStep by factor of 2 reduces the default indent by a factor of 4, so in some cases users might prefer to adjust the basicTimeStep. That also has the benefit of reducing the damping time constant. Reducing the indent by setting it directly instead of reducing basicTimeStep would increase the damping time constant.

[omichel]

That sounds like a great idea, but naively by replacing two parameters (ERP and CFM) with a single one (indent), I fear that some simulations which were tuned with some specific ERP/CFM couldn't converted to an indent equivalent. We may need a second parameter for this.

[brettle]

How about this:

1. If indent is -1.0, the current behavior will be used (ie using the ERP and CFM values specified, or their defaults).
2. If indent is 0.0, a "recommended" value will be used. I'm still working on what this should be, but I suspect it doesn't need to be the 4*gravity*basicTimeStep^2/pi^2 I mentioned above. That was based on the assumption that for a given basicTimeStep there might be a limit to how small indent could be without causing oscillations. I now think that might not be the case and the real limit might be numerical stability. Anyway, in the worst case we can adjust the "recommended" value later if necessary.
3. If indent is positive, it is the requested amount of indent.

The default would be 0.0, but those upgrading existing worlds could return to the original behavior by simply setting it to -1.0.

Sound good?

[omichel]

Yes, that sounds good to me. We could even make the default value to -1.0 for Webots files older than R2025a (read from the first line of the wbt file) and 0.0 for versions >= R2025a, so that upgrading to the new version should be smooth.

[brettle]

Do you know offhand whether we are currently storing the version number of wbt file anywhere? If you don't know offhand, I can hunt for it, but I thought you might just know.

[omichel]

Sorry, I don't know offhand.