Question
Trade-off between ERP/CFM parameter preservation and DART stiffness parameter re-tuning for stiff Gazebo manipulation models
Ari Atlas
0 reputation · 18 Feb 2021, 19:38 UTC
18.4K views1
Loading…
0 reputation · 18 Feb 2021, 19:38 UTC
This examination assesses the feasibility of migrating ODE-tuned stiff-contact models to DART in Gazebo Harmonic while preserving contact force magnitudes and controller compatibility. Gazebo's <physics> SDF element switches between ODE and DART engines, but the two encode contact stiffness differently. ODE uses ERP and CFM to soften constraints, while DART exposes independent stiffness and damping per material pair. This incompatibility means direct migration without redefining every contact surface, as no automated conversion path exists in the core engine or ROS 2 plugins.
Migrating a stiff peg-in-hole model from ODE to DART in Gazebo Harmonic exposes a sensor force mismatch: the <contact> sensor scales output by ERP under ODE but reports raw computed forces under DART, breaking calibrated controllers. Additionally, DART's real-time factor degrades above 50 simultaneous contacts, whereas ODE sustains higher step rates at the expense of force accuracy. No built-in tool converts ERP/CFM to DART stiffness/damping, forcing empirical re-tuning per engine.
What documented mappings exist between ODE ERP/CFM and DART stiffness/damping for stiff contacts? Does libgazebo_ros_force provide engine-agnostic normalization, or must users apply post-hoc scaling? Are published benchmarks available that report both force error and real-time factor for peg-in-hole tasks under both engines?
35275 reputation · 19 Feb 2021, 03:51 UTC
There are no documented mathematical mappings to convert ODE's Error Reduction Parameter (ERP) and Constraint Force Mixing (CFM) directly into DART's stiffness and damping parameters. Because ODE uses these values to regularize constraint stabilization and DART employs a distinct material-pair stiffness/damping model, direct parameter preservation is not feasible. Migration requires empirical re-tuning of every contact surface in the SDF.
The libgazebo_ros_force plugin and standard Gazebo contact sensors do not provide engine-agnostic normalization. They report the raw forces computed by the active physics solver. Since the numerical output of the ODE solver differs from the DART solver for the same physical scenario, users must apply post-hoc scaling or re-calibrate controllers to maintain compatibility.
While specific published benchmarks for peg-in-hole tasks in Gazebo Harmonic are not standardized, the following behaviors are generally observed:
gazebo<stiffness> and <damping> within the <contact> element of the SDF for each material pair.Diagnostic Requirement: To refine the tuning recommendation, please specify the max_step_size and real_time_update_rate currently used in your <physics> element, as DART's stability is highly sensitive to the integration timestep.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 18 Feb 2021, 23:27 UTC
Community trials suggest a rough rule:
stiffness ≈ ERP / (dt² / mass)
d‑amping ≈ CFM / dt
These depend heavily on the simulation step (dt) and contact mass; applying them without validation can destabilise the solver.
libgazebo_ros_force forwards the raw contact force from the active engine; it does not normalise for ERP or stiffness differences.
/gazebo/contact with ODE./gazebo/physics/step_time and check RTF via gz sim --verbose.Iterating this process keeps controller gains intact while respecting real‑time limits.