Skip to content

Fix DC motor Vmax limiting in voltage input mode - #3490

Closed
giusenso wants to merge 7 commits into
google-deepmind:mainfrom
giusenso:fix/vmax
Closed

Fix DC motor Vmax limiting in voltage input mode#3490
giusenso wants to merge 7 commits into
google-deepmind:mainfrom
giusenso:fix/vmax

Conversation

@giusenso

Copy link
Copy Markdown
Contributor

This PR addresses the issue #3489.

Summary

gainprm[8] stores the input mode:

  • 0: voltage
  • 1: position
  • 2: velocity

Previously:

if ((int)gainprm[8] > 0) {
  ctrl[uadr] = dcmotorVoltage(...);
}

The condition treated dcmotorVoltage() as only a PID conversion function. However, that helper has two responsibilities:

  1. Convert position/velocity commands into voltage.
  2. Apply Vmax to every voltage, including direct voltage input.

For voltage mode, the helper explicitly does:

voltage = ctrl;
voltage = clip(voltage, -Vmax, Vmax);

But because mode 0 failed the > 0 condition, this code was never reached. Raw ctrl went directly into:

torque = K/R * ctrl - K²/R * velocity

Removing the guard makes the helper the canonical terminal-voltage calculation:

  • Voltage mode: V = clip(ctrl)
  • Position mode: V = clip(PID_position(ctrl))
  • Velocity mode: V = clip(PI_velocity(ctrl))

It is safe because when Vmax == 0, the helper returns voltage-mode ctrl unchanged. Position and velocity behavior is unchanged.

The old if conflated “requires PID conversion” with “requires voltage processing”; only the first is mode-dependent.

Testing

  • Added VoltageInputVoltageLimit to verify positive and negative voltage clipping and unchanged in-range inputs.
  • Added VoltageInputVoltageLimitWithThermalState to verify torque and thermal dynamics use the same clamped voltage.

yuvaltassa and others added 5 commits August 16, 2026 00:05
Three diagnostics that clang does not emit, so they were missed until the
gcc-14 CI jobs, which build with -Werror:

- mji_scl3 takes a restrict-qualified destination, so passing the same array
  as source and destination is undefined. Two calls did: negating the edge
  separating axis, and halving the witness midpoint. The first now negates in
  place, the second forms the midpoint directly.
- Adding const to a pointer to array is not a valid implicit conversion before
  C23. The pointer it qualified was a redundant alias of the clip buffer, and
  is removed.

No functional change: the box-box fuzzer's output hash over 60k configurations
is identical before and after.
- The 25-line comment describing the collider's two stages, the reference and
  incident face convention, and why the manifold is not reduced below the
  clipped polygon. The last paragraph is load-bearing: reducing the patch to
  four points is what an earlier draft did, and it costs two to three orders of
  magnitude of residual motion on stacks of plates.

- contact_net.xml's b1 orientation, from euler="5 4 3" back to "5 5 5". The
  re-posed model does not converge under mjUSESINGLE: SensorTest.ContactNet
  spends minutes in mj_solPrimal instead of hundredths of a second, so the
  single-precision suite never finishes. The original orientation passes in
  both precisions with the current collider, in 0.02s and 0.01s.

No functional change to the collider: the box-box fuzzer's output hash over 60k
configurations is unchanged.
On mjWARN_BADQACC the warning handler resets mjData, which rewinds data->time
to one timestep. A loop conditioned on data->time then cannot terminate: the
model diverges, resets, falls, diverges again, indefinitely. Every step is
sub-millisecond, so it presents as a compute hang rather than a failure, and a
CI job sits in it until the runner is killed. This test hit that under
mjUSESINGLE: 100k steps without data->time reaching 0.2.

Bounding by step count turns the same event into a prompt failure. 80 further
occurrences of the idiom remain across the test suite; they are only latent as
long as their models do not diverge.
@giusenso giusenso closed this Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants