Drop the unreachable Newton preset from the Digit tasks - #7165
Conversation
LocomotionVelocityRoughEnvCfg declares events.base_com as a preset whose newton_mjwarp branch disables the center-of-mass randomization, because Newton does not support it. On tasks that offer Newton the branch rides along with the backend and is never selectable on its own. Digit is PhysX-only, so the branch named no reachable backend: physics=newton_mjwarp is rejected, while presets=newton_mjwarp resolved and merely stripped the randomization from a PhysX run. Collapse the preset to its default on Digit so the task offers only what it can run.
Review feedback on isaac-sim#7165: the six-line rationale is condensed to two, and the per-task preset test is removed.
There was a problem hiding this comment.
Isaac Lab Review Bot
Reviewed the Digit-specific collapse of the inherited base_com preset and its changelog entry. The change narrowly removes the standalone Newton workaround from the three PhysX-only Digit tasks while preserving their default center-of-mass randomization.
- Design and architecture: Applying the override in
DigitRoughEnvCfg.__post_init__keeps the shared locomotion configuration and Newton-capable tasks unchanged. This is appropriately scoped to the Digit configuration. - API: The three Digit tasks will no longer expose or accept
presets=newton_mjwarp. Existing scripts that explicitly pass that token will fail rather than silently disabling randomization on PhysX; the changelog clearly documents this compatibility change. - Implementation: After the superclass initialization,
events.base_comis rebound from the preset wrapper to its defaultEventTerm, then its asset body is configured astorso_base. This preserves the effective default PhysX event while removing the unreachable preset branch.
No blocking issues. No inline issue met the actionable-evidence threshold; the assessment above records the review feedback.
Automated review; human maintainers own approval decisions.
Greptile SummaryThe PR removes an unreachable Newton-specific preset from PhysX-only Digit tasks while retaining center-of-mass randomization with the Digit torso body configuration.
Confidence Score: 5/5The PR appears safe to merge with no actionable defects identified. The preset collapse occurs on an instance-isolated configuration, removes the unwanted preset from discovery, preserves the default event and its Digit-specific body selection, and does not violate assumptions in current Digit subclasses. Important Files Changed
Reviews (1): Last reviewed commit: "Address review: shorten the Digit preset..." | Re-trigger Greptile |
Problem
LocomotionVelocityRoughEnvCfgdeclaresevents.base_comas a preset whosenewton_mjwarpbranch disables the centre-of-mass randomization, because Newton doesnot support it:
On tasks that offer Newton, that branch is a companion: it rides along with the
newton_mjwarpalready on the physics axis and is never selectable on its own.Digit is PhysX-only —
DigitPhysicsCfgdeclares onlyisaacsim_physx,physxanddefault, and its own docstring says so. The inherited branch therefore names noreachable backend:
physics=newton_mjwarppresets=newton_mjwarpPhysxCfg, and silently drops the randomizationSo the three Digit tasks advertised a
presets=newton_mjwarpthat was never a backendswitch. Selecting it gave you PhysX physics with a Newton-only workaround applied.
Affects
IsaacContrib-Velocity-Flat-Digit,IsaacContrib-Velocity-Rough-DigitandIsaacContrib-Tracking-LocoManip-Digit— all three derive fromDigitRoughEnvCfg.Fix
Collapse the preset to its default in
DigitRoughEnvCfg.__post_init__, so the taskoffers only what it can run. One edit covers all three tasks.
Verification
All three tasks now report
presets: [](was['newton_mjwarp']);base_comsurvives with
body_names="torso_base".AnymalCRoughEnvCfgstill carries['default', 'newton_mjwarp']— the sharedconfig and every task that does offer Newton are untouched.
New
test_digit_physics_presets.pyfollows the existingtest_dr_legs_physics_presets.pypattern (offline, no sim). Confirmed the guardfails without the fix and passes with it:
Notes
Found while building a task-discovery API that enumerates each task's runnable backend
combinations — this surfaced as a task declaring a preset it cannot resolve.
Sibling velocity tasks were checked:
Velocity-Flat-AnymalChas the samebase_compreset and
newton_mjwarpon its physics axis, so the companion is correctly pairedthere;
G1andSpotoverridebase_comaway entirely. Digit was the only one thatinherited the companion without the backend.