Fix DC motor Vmax limiting in voltage input mode - #3490
Closed
giusenso wants to merge 7 commits into
Closed
Conversation
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.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR addresses the issue #3489.
Summary
gainprm[8]stores the input mode:0: voltage1: position2: velocityPreviously:
The condition treated
dcmotorVoltage()as only a PID conversion function. However, that helper has two responsibilities:Vmaxto every voltage, including direct voltage input.For voltage mode, the helper explicitly does:
But because mode
0failed the> 0condition, this code was never reached. Rawctrlwent directly into:Removing the guard makes the helper the canonical terminal-voltage calculation:
V = clip(ctrl)V = clip(PID_position(ctrl))V = clip(PI_velocity(ctrl))It is safe because when
Vmax == 0, the helper returns voltage-modectrlunchanged. Position and velocity behavior is unchanged.The old
ifconflated “requires PID conversion” with “requires voltage processing”; only the first is mode-dependent.Testing
VoltageInputVoltageLimitto verify positive and negative voltage clipping and unchanged in-range inputs.VoltageInputVoltageLimitWithThermalStateto verify torque and thermal dynamics use the same clamped voltage.