Skip to content

Initial support for Mujoco equality constraints#460

Merged
eric-heiden merged 6 commits into
newton-physics:mainfrom
kaloca:feature_equality_constraints
Jul 31, 2025
Merged

Initial support for Mujoco equality constraints#460
eric-heiden merged 6 commits into
newton-physics:mainfrom
kaloca:feature_equality_constraints

Conversation

@kaloca

@kaloca kaloca commented Jul 22, 2025

Copy link
Copy Markdown
Member

Description

Adds support for Mujoco equality constraints. (<equality> tag in MJCF files).

There are currently 5 types of equality constraints in Mujoco: connect, weld, joint, tendon, and flex.

Currently connect, weld, and joint are implemented. The overall structure for other types is already present, but full implementation would depend on Newton supporting the tendon and flex types themselves.

Equality constraints primarily serve as a way to remediate closed kinematic loops and are present in many assets in the Mujoco menagerie. (Issue #331)

Newton Migration Guide

Please ensure the migration guide for warp.sim users is up-to-date with the changes made in this MR.

  • The migration guide in docs/migration.rst is up-to date

Before your PR is "Ready for review"

  • All commits are signed-off to indicate that your contribution adheres to the Developer Certificate of Origin requirements
  • Necessary tests have been added and new examples are tested (see newton/tests/test_examples.py)
  • Documentation is up-to-date
  • Code passes formatting and linting checks with pre-commit run -a

Summary by CodeRabbit

  • New Features

    • Added support for equality constraints (connect, joint, weld) in simulation models.
    • Enabled importing equality constraints from MJCF files.
    • Exposed new public constants for equality constraint types.
    • Extended model builder and solver to handle and simulate equality constraints.
    • Added a comprehensive test and asset for validating equality constraint dynamics.
  • Bug Fixes

    • N/A
  • Tests

    • Introduced new unit tests to verify correct handling and enforcement of equality constraints.
  • Documentation

    • Updated public API to document new equality constraint-related attributes and methods.

@coderabbitai

coderabbitai Bot commented Jul 22, 2025

Copy link
Copy Markdown
Contributor
📝 Walkthrough

Walkthrough

This update introduces support for equality constraints in the Newton simulation framework. It adds new public constants for constraint types, extends the model builder and model data structures to store equality constraints, implements parsing and export of these constraints to and from MuJoCo/MJCF, and provides comprehensive tests and XML assets to validate the new functionality.

Changes

Cohort / File(s) Change Summary
Equality Constraint Constants
newton/sim/joints.py, newton/sim/__init__.py, newton/__init__.py
Added new public constants EQ_CONNECT, EQ_JOINT, and EQ_WELD for equality constraint types. Updated __all__ lists to export these symbols.
ModelBuilder and Model Extensions
newton/sim/builder.py, newton/sim/model.py
Extended ModelBuilder and Model to support equality constraints: added new attributes, public methods for adding constraints, and logic for copying and finalizing constraint data.
MuJoCo Solver Integration
newton/solvers/mujoco/solver_mujoco.py
Modified the MuJoCo solver to extract and convert equality constraints from the Newton model into MuJoCo equality constraints during model conversion.
MJCF Import Enhancements
newton/utils/import_mjcf.py
Updated MJCF parser to optionally import equality constraints from <equality> tags, added a helper for parsing, and extended the main parsing routine and function signature.
Testing and Assets
newton/tests/test_equality_constraints.py, newton/tests/assets/constraints.xml
Added a new unit test for equality constraints and an accompanying MuJoCo XML asset file to validate the implementation, including various constraint types and joint/actuator configurations.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ModelBuilder
    participant Model
    participant MuJoCoSolver
    participant MJCFParser

    User->>ModelBuilder: add_equality_constraint_*(...)
    ModelBuilder->>ModelBuilder: Store constraint attributes in lists

    User->>ModelBuilder: finalize()
    ModelBuilder->>Model: Assign equality constraint arrays and count

    User->>MuJoCoSolver: convert_to_mjc(model)
    MuJoCoSolver->>MuJoCoSolver: Extract equality constraint arrays
    MuJoCoSolver->>MuJoCoSolver: Add constraints to MuJoCo model

    User->>MJCFParser: parse_mjcf(..., skip_equality_constraints=False)
    MJCFParser->>ModelBuilder: add_equality_constraint_* for each parsed constraint
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

  • adenzler-nvidia
  • eric-heiden

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@kaloca kaloca force-pushed the feature_equality_constraints branch 2 times, most recently from 8cfc8c0 to 7301c35 Compare July 22, 2025 23:10

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Nitpick comments (3)
newton/solvers/mujoco/solver_mujoco.py (2)

1622-1631: Remove or document unused equality constraint variables

Several variables are extracted but immediately commented out. This creates unnecessary overhead and makes the code harder to maintain. Either remove these lines entirely or add a TODO comment explaining their future purpose.

 eq_constraint_body1 = model.equality_constraint_body1.numpy()
 eq_constraint_body2 = model.equality_constraint_body2.numpy()
 eq_constraint_anchor1 = model.equality_constraint_anchor1.numpy()
-# eq_constraint_anchor2 = model.equality_constraint_anchor2.numpy()
-# eq_constraint_distance = model.equality_constraint_distance.numpy()
 eq_constraint_joint1 = model.equality_constraint_joint1.numpy()
 eq_constraint_joint2 = model.equality_constraint_joint2.numpy()
 eq_constraint_polycoef = model.equality_constraint_polycoef.numpy()
-# eq_constraint_enabled = model.equality_constraint_enabled.numpy()
+# TODO: Add support for anchor2, distance, and enabled properties when implementing
+# weld, distance, and other constraint types

2020-2039: Consider environment filtering and enabled flag for constraints

The equality constraints should respect the environment filtering logic used elsewhere in the code when separate_envs_to_worlds is True. Also, the equality_constraint_enabled property exists but is commented out - consider using it to allow disabling constraints.

Would you like me to implement the environment filtering logic for equality constraints to ensure they're only added for the selected environment?

newton/sim/builder.py (1)

3530-3556: Consider polycoef array structure and approve the rest.

The equality constraint finalization is well-implemented and follows the established patterns. However, there's a potential issue with the polycoef attribute:

m.equality_constraint_polycoef = wp.array(self.equality_constraint_polycoef, dtype=wp.float32)

Since polycoef is a list of lists (each constraint can have multiple polynomial coefficients), flattening it into a single Warp array might lose the structure. Consider either:

  1. Using a 2D array if all constraints have the same number of coefficients
  2. Storing it as a list of Warp arrays
  3. Adding metadata to track coefficient counts per constraint

The rest of the implementation correctly converts the equality constraint data to appropriate Warp array types and follows the established patterns for model finalization.

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e37f0d9 and 7301c3511b3ad67b557894f5aa443e11f0d513c6.

📒 Files selected for processing (4)
  • newton/sim/builder.py (5 hunks)
  • newton/sim/model.py (2 hunks)
  • newton/solvers/mujoco/solver_mujoco.py (2 hunks)
  • newton/utils/import_mjcf.py (4 hunks)
🧠 Learnings (3)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
newton/sim/model.py (1)

Learnt from: dylanturpin
PR: #450
File: newton/sim/ik.py:1286-1296
Timestamp: 2025-07-21T19:11:04.055Z
Learning: In Newton's IK system, the JointLimitObjective class intentionally only handles joints where DOF count equals coordinate count (1-1 mapping). This is appropriate because joint limits are typically only meaningful for simple joint types like revolute and prismatic joints, not complex joints like ball or free joints where DOF count != coordinate count.

newton/solvers/mujoco/solver_mujoco.py (1)

Learnt from: Kenny-Vilella
PR: #398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
newton/sim/model.py (1)

Learnt from: dylanturpin
PR: #450
File: newton/sim/ik.py:1286-1296
Timestamp: 2025-07-21T19:11:04.055Z
Learning: In Newton's IK system, the JointLimitObjective class intentionally only handles joints where DOF count equals coordinate count (1-1 mapping). This is appropriate because joint limits are typically only meaningful for simple joint types like revolute and prismatic joints, not complex joints like ball or free joints where DOF count != coordinate count.

newton/solvers/mujoco/solver_mujoco.py (1)

Learnt from: Kenny-Vilella
PR: #398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run GPU Unit Tests on AWS EC2 (Pull Request)
🔇 Additional comments (3)
newton/sim/model.py (1)

275-323: LGTM! Clean addition of equality constraint attributes.

The new equality constraint attributes follow the established naming conventions and are properly documented with their expected shapes and types. The initialization as empty lists is appropriate for these dynamic collections.

newton/sim/builder.py (2)

421-432: LGTM! Well-structured equality constraint attributes.

The new equality constraint attributes follow the established naming pattern and data structure conventions in the codebase. The attribute types are appropriate for their intended use (strings for type/key, integers for indices, Vec3 for anchors, etc.).


688-698: LGTM! Proper integration with builder combination.

The equality constraint attributes are correctly added to the more_builder_attrs list, ensuring that when builders are combined using add_builder(), the equality constraint data is properly copied. This follows the established pattern for handling other model attributes.

Comment thread newton/sim/builder.py Outdated
Comment thread newton/solvers/mujoco/solver_mujoco.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
@kaloca kaloca force-pushed the feature_equality_constraints branch from dd0148e to 7ef9a3e Compare July 22, 2025 23:53
@kaloca kaloca self-assigned this Jul 22, 2025

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
newton/tests/test_equality_constraints.py (2)

25-36: Consider improving test organization and method naming.

The test setup is functionally correct, but could be improved:

  1. Move timing parameters to setUp(): The simulation timing parameters should be initialized in a setUp() method rather than within the test method for better test organization.

  2. Test method name could be more descriptive: The method name test_connect_constraint suggests it's testing connect constraints specifically, but the test actually verifies general equality constraint parsing.

Consider this refactor:

class TestEqualityConstraints(unittest.TestCase):
+    def setUp(self):
+        self.sim_time = 0.0
+        self.frame_dt = 1 / 60
+        self.sim_dt = self.frame_dt / 10
+
-    def test_connect_constraint(self):
+    def test_equality_constraints_parsing(self):
-        self.sim_time = 0.0
-        self.frame_dt = 1 / 60
-        self.sim_dt = self.frame_dt / 10
-

62-69: Consider enhancing test coverage with additional assertions.

The current assertion only verifies that equality constraints exist but doesn't validate their correctness. For a more comprehensive test, consider adding assertions to verify:

  • Specific constraint types (connect, joint, etc.)
  • Constraint properties and parameters
  • Expected number of constraints for the 4_bar.xml model

Example additional assertions:

        self.assertGreater(
            self.solver.mj_model.eq_type.shape[0], 0
        )  # check if number of equality constraints in mjModel > 0
+
+        # Verify specific constraint properties
+        eq_types = self.solver.mj_model.eq_type
+        self.assertIn(mujoco.mjtEq.mjEQ_CONNECT, eq_types)  # Verify connect constraint exists
+        self.assertEqual(len([t for t in eq_types if t == mujoco.mjtEq.mjEQ_CONNECT]), 1)  # Expected count

The main execution block with kernel cache clearing is appropriate.

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7301c3511b3ad67b557894f5aa443e11f0d513c6 and 7ef9a3eb54e80de41017f28c53ac2ec5e88de2ba.

📒 Files selected for processing (2)
  • newton/tests/assets/4_bar.xml (1 hunks)
  • newton/tests/test_equality_constraints.py (1 hunks)
🧠 Learnings (1)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
✅ Files skipped from review due to trivial changes (1)
  • newton/tests/assets/4_bar.xml
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run GPU Unit Tests on AWS EC2 (Pull Request)
🔇 Additional comments (2)
newton/tests/test_equality_constraints.py (2)

1-22: LGTM! Clean imports and proper licensing.

The copyright header and imports are well-structured and include only the necessary dependencies for the test.


39-48: MuJoCoSolver use_mujoco flag is now fully supported

The use_mujoco=True option is correctly handled in newton/solvers/mujoco/solver_mujoco.py (it sets self.use_mujoco and exercises the pure MuJoCo backend in step) and is exercised by multiple tests (e.g. test_equality_constraints.py, test_rigid_contact.py, test_up_axis.py, etc.). No further action needed.

Comment thread newton/tests/test_equality_constraints.py Outdated
@eric-heiden eric-heiden linked an issue Jul 23, 2025 that may be closed by this pull request
Comment thread newton/sim/model.py Outdated
Comment thread newton/sim/builder.py Outdated
@adenzler-nvidia

Copy link
Copy Markdown
Member

Thanks for this - 1 question (probably mostly for @eric-heiden..)

Architecturally, did we make a formal decision that a loop joint is treated differently in the newton model? You could argue that for non tree-based solvers, these joints are just joints.. And the featherstone/MuJoCo case is actually the special case. In fact, this is also how USD handles things, that everything is just joints and then you specify the articulation on top of it, as well as the loop joints that are then excluded from the tree and added as constraints. I feel like this needs a conversation with Disney for Kamino, at least. @nvtw @gdaviet probably have comments here as well.

@kaloca kaloca force-pushed the feature_equality_constraints branch from 7ef9a3e to b598927 Compare July 24, 2025 14:24

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

♻️ Duplicate comments (5)
newton/tests/test_equality_constraints.py (1)

42-51: Verify that use_mujoco=True is now supported.

According to previous learnings, the use_mujoco option was unsupported and caused crashes. Please verify that this has been properly implemented and no longer causes issues.

#!/bin/bash
# Description: Check if use_mujoco is still marked as unsupported in the codebase

# Search for any warnings or unsupported messages related to use_mujoco
rg -A 5 "use_mujoco.*unsupported|unsupported.*use_mujoco" 

# Check the MuJoCoSolver implementation for use_mujoco handling
ast-grep --pattern 'class MuJoCoSolver {
  $$$
}'

# Look for any crash-related comments or warnings about use_mujoco
rg -A 5 "use_mujoco.*crash|crash.*use_mujoco"
newton/utils/import_mjcf.py (2)

768-773: Apply consistent body name sanitization.

The connect constraint replaces hyphens with underscores in body names, but other constraint types should do the same for consistency.


817-817: Add verbose check for debug print statement.

The weld constraint debug message should be wrapped with verbose check for consistency.

newton/sim/model.py (1)

277-296: Initialize Warp arrays with None.

According to past review comments, Model attributes that are Warp arrays should be initialized with None.

-        self.equality_constraint_body1 = None
-        self.equality_constraint_body2 = None
-        self.equality_constraint_anchor = None
-        self.equality_constraint_torquescale = None
-        self.equality_constraint_relpose = None
-        self.equality_constraint_joint1 = None
-        self.equality_constraint_joint2 = None
-        self.equality_constraint_polycoef = None
-        self.equality_constraint_enabled = None
+        self.equality_constraint_body1 = None
+        self.equality_constraint_body2 = None
+        self.equality_constraint_anchor = None
+        self.equality_constraint_torquescale = None
+        self.equality_constraint_relpose = None
+        self.equality_constraint_joint1 = None
+        self.equality_constraint_joint2 = None
+        self.equality_constraint_polycoef = None
+        self.equality_constraint_enabled = None

Note: The attributes are already initialized to None, so the code is correct as-is.

newton/solvers/mujoco/solver_mujoco.py (1)

2054-2080: Add error handling and validation for equality constraints

The implementation still lacks proper error handling for invalid indices and unsupported constraint types as previously identified.

🧹 Nitpick comments (1)
newton/sim/model.py (1)

275-297: Consider adding equality constraints to attribute_frequency mapping.

The new equality constraint attributes should be classified in the attribute_frequency dictionary to maintain consistency with other model attributes.

Add the following after line 385:

# attributes per equality constraint
self.attribute_frequency["equality_constraint_type"] = "equality_constraint"
self.attribute_frequency["equality_constraint_body1"] = "equality_constraint"
self.attribute_frequency["equality_constraint_body2"] = "equality_constraint"
self.attribute_frequency["equality_constraint_anchor"] = "equality_constraint"
self.attribute_frequency["equality_constraint_torquescale"] = "equality_constraint"
self.attribute_frequency["equality_constraint_relpose"] = "equality_constraint"
self.attribute_frequency["equality_constraint_joint1"] = "equality_constraint"
self.attribute_frequency["equality_constraint_joint2"] = "equality_constraint"
self.attribute_frequency["equality_constraint_polycoef"] = "equality_constraint"
self.attribute_frequency["equality_constraint_enabled"] = "equality_constraint"
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7ef9a3eb54e80de41017f28c53ac2ec5e88de2ba and b598927e759d3e31b2fc3836dcf1ea3fb37b09f1.

📒 Files selected for processing (6)
  • newton/sim/builder.py (5 hunks)
  • newton/sim/model.py (2 hunks)
  • newton/solvers/mujoco/solver_mujoco.py (2 hunks)
  • newton/tests/assets/constraints.xml (1 hunks)
  • newton/tests/test_equality_constraints.py (1 hunks)
  • newton/utils/import_mjcf.py (4 hunks)
✅ Files skipped from review due to trivial changes (1)
  • newton/tests/assets/constraints.xml
🚧 Files skipped from review as they are similar to previous changes (1)
  • newton/sim/builder.py
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
newton/sim/model.py (1)

Learnt from: dylanturpin
PR: #450
File: newton/sim/ik.py:1286-1296
Timestamp: 2025-07-21T19:11:04.077Z
Learning: In Newton's IK system, the JointLimitObjective class intentionally only handles joints where DOF count equals coordinate count (1-1 mapping). This is appropriate because joint limits are typically only meaningful for simple joint types like revolute and prismatic joints, not complex joints like ball or free joints where DOF count != coordinate count.

newton/tests/test_equality_constraints.py (1)

Learnt from: Kenny-Vilella
PR: #398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

newton/solvers/mujoco/solver_mujoco.py (1)

Learnt from: Kenny-Vilella
PR: #398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

🧬 Code Graph Analysis (1)
newton/utils/import_mjcf.py (1)
newton/sim/builder.py (1)
  • add_equality_constraint (1289-1339)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run GPU Unit Tests on AWS EC2 (Pull Request)

Comment thread newton/solvers/mujoco/solver_mujoco.py Outdated
Comment thread newton/tests/test_equality_constraints.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
@kaloca kaloca force-pushed the feature_equality_constraints branch from b598927 to 5ee4700 Compare July 24, 2025 15:11
@eric-heiden

Copy link
Copy Markdown
Member

Architecturally, did we make a formal decision that a loop joint is treated differently in the newton model? You could argue that for non tree-based solvers, these joints are just joints.. And the featherstone/MuJoCo case is actually the special case.

We definitely need to discuss more how this should be handled architecturally in Newton. We rely on kinematic trees a lot in Newton at the moment so just having loops represented by joints will break kinematics, etc. It may be beneficial to make the definition of which "joint" (or let's call it equality constraint) to be used to close the loop explicitly defined by the user instead of providing some cyclic joint graph to every algorithm (FK/IK, or the MuJoCoSolver converter) in Newton which then has to decide which joint to treat for loop closure, etc.
But we need more opinions on this, including Disney's.

@mmacklin for viz.

@eric-heiden eric-heiden requested review from gdaviet, mmacklin and nvtw July 25, 2025 22:08
@adenzler-nvidia

Copy link
Copy Markdown
Member

Indeed if you look at the model from a solver-centric point of view, the loop joint/equality constraint should just be a different thing in a different array vs the joints that are part of the kinematic tree. I think that would also work well for a purely maximal coordinate solver as for these the model would only contain equality constraints.

It does get difficult at the point where you want to switch solvers with the same model, which I think is a requirement for us. At that point I think there is no way around having everything in the same array/bucket and then have some additional information that you setup at model init time that tells the solver how to use those constraints.

@kaloca kaloca force-pushed the feature_equality_constraints branch 2 times, most recently from 960d776 to a5b60fa Compare July 29, 2025 19:38
@kaloca kaloca requested a review from eric-heiden July 29, 2025 19:43
@kaloca kaloca force-pushed the feature_equality_constraints branch from a5b60fa to 4f8b03b Compare July 29, 2025 19:45
@kaloca kaloca marked this pull request as ready for review July 29, 2025 19:45

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (4)
newton/utils/import_mjcf.py (4)

814-815: Add verbose check for consistency.

The debug print statement should be wrapped with a verbose check for consistency with the rest of the codebase.

-            if verbose:
-                print(f"Weld constraint: {body1_name} to {body2_name}")
+            if verbose:
+                print(f"Weld constraint: {body1_name} to {body2_name}")

Wait, this is already correctly wrapped. Let me check if there are other missing verbose checks in the function.


775-802: Fix undefined variable and improve consistency.

Multiple issues in the connect constraint parsing:

  1. Line 787 uses undefined variable anchor instead of anchor_vec
  2. Body name sanitization should be consistent with other constraint types

Apply this fix:

         if body1_name and anchor:
             if verbose:
-                print(f"Connect constraint: {body1_name} to {body2_name} at anchor {anchor}")
+                print(f"Connect constraint: {body1_name} to {body2_name} at anchor {anchor_vec}")

Also, consider moving the anchor_vec calculation before the verbose print for better code organization.


803-832: Fix incorrect attribute reference and apply consistent naming.

Critical issue: Lines 805-806 incorrectly reference connect.attrib instead of weld.attrib when parsing weld constraints.

Apply this fix:

-        body1_name = connect.attrib.get("body1", "").replace("-", "_") if connect.attrib.get("body1") else None
+        body1_name = weld.attrib.get("body1", "").replace("-", "_") if weld.attrib.get("body1") else None
         body2_name = (
-            connect.attrib.get("body2", "worldbody").replace("-", "_") if connect.attrib.get("body2") else None
+            weld.attrib.get("body2", "worldbody").replace("-", "_") if weld.attrib.get("body2") else None
         )

833-851: Fix undefined variable in joint constraint parsing.

The variable common is used but not defined in the joint constraint parsing section.

Add the missing line:

     for joint in equality.findall("joint"):
+        common = parse_common_attributes(joint)
         joint1_name = joint.attrib.get("joint1")
🧹 Nitpick comments (1)
newton/utils/import_mjcf.py (1)

612-613: Remove leftover debug code.

This debug print statement appears to be leftover development code and should be removed.

-    if body_name == "thigh_right":
-        print(geoms)
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5ee4700adbe2fa69608c63e562ccbdfb08006270 and 4f8b03b91e781e11bcbef718812289abdad94c60.

📒 Files selected for processing (9)
  • newton/__init__.py (2 hunks)
  • newton/sim/__init__.py (1 hunks)
  • newton/sim/builder.py (5 hunks)
  • newton/sim/model.py (2 hunks)
  • newton/sim/types.py (1 hunks)
  • newton/solvers/mujoco/solver_mujoco.py (2 hunks)
  • newton/tests/assets/constraints.xml (1 hunks)
  • newton/tests/test_equality_constraints.py (1 hunks)
  • newton/utils/import_mjcf.py (4 hunks)
✅ Files skipped from review due to trivial changes (3)
  • newton/sim/init.py
  • newton/init.py
  • newton/sim/types.py
🚧 Files skipped from review as they are similar to previous changes (4)
  • newton/tests/test_equality_constraints.py
  • newton/tests/assets/constraints.xml
  • newton/sim/model.py
  • newton/solvers/mujoco/solver_mujoco.py
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Run GPU Benchmarks (Pull Request)
  • GitHub Check: Run GPU Unit Tests on AWS EC2 (Pull Request)
🔇 Additional comments (6)
newton/utils/import_mjcf.py (2)

57-57: LGTM! Parameter addition is well-implemented.

The parse_equality parameter is properly added with a sensible default value and clear documentation.

Also applies to: 86-86


883-888: LGTM! Equality constraint integration is well-placed.

The integration of equality constraint parsing is correctly implemented:

  • Proper conditional check using the parse_equality parameter
  • Well-positioned in the parsing flow after bodies but before collision setup
  • Clear section separation with comments
newton/sim/builder.py (4)

447-458: LGTM! Clean initialization of equality constraint data structures.

The initialization of equality constraint lists follows the established pattern in the ModelBuilder class and covers all necessary attributes for representing Mujoco-style equality constraints. The naming convention is consistent with other constraint types in the codebase.


1313-1363: Good implementation with proper error handling.

The method correctly addresses the previous review concern about name-to-index resolution by adding proper validation (name in self.key_list) before calling .index(). The implementation handles all constraint types with appropriate default values and follows the established pattern of other add_* methods in the class.

The method signature is comprehensive and the documentation clearly explains each parameter's purpose.


714-724: Correct integration with ModelBuilder composition.

The equality constraint attributes are properly added to the more_builder_attrs list, ensuring that constraint data is correctly copied when combining ModelBuilder instances. This maintains consistency with how other constraint types are handled during builder composition.


3749-3775: Proper finalization of equality constraint data.

The constraint data is correctly converted from Python lists to appropriate Warp arrays during model finalization. The data types are well-chosen for GPU computation, and the constraint count is properly set on the model. This follows the established pattern for other constraint types in the finalization process.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (2)
newton/solvers/mujoco/solver_mujoco.py (2)

1656-1665: Add validation for equality constraint attributes before accessing them.

The code directly accesses multiple equality constraint attributes without checking if they exist on the model object. This could cause runtime exceptions if any attributes are missing or not properly initialized.

+        # Validate equality constraint attributes exist
+        constraint_attrs = [
+            'equality_constraint_type', 'equality_constraint_body1', 'equality_constraint_body2',
+            'equality_constraint_anchor', 'equality_constraint_torquescale',
+            'equality_constraint_relpose', 'equality_constraint_joint1',
+            'equality_constraint_joint2', 'equality_constraint_polycoef',
+            'equality_constraint_enabled'
+        ]
+        for attr in constraint_attrs:
+            if not hasattr(model, attr):
+                raise AttributeError(f"Model missing required equality constraint attribute: {attr}")
+
         eq_constraint_type = model.equality_constraint_type.numpy()
         eq_constraint_body1 = model.equality_constraint_body1.numpy()
         eq_constraint_body2 = model.equality_constraint_body2.numpy()

2055-2081: Add comprehensive error handling and validation for equality constraints.

The constraint conversion logic lacks proper error handling and validation:

  1. Direct dictionary access could raise KeyError if indices are invalid
  2. No bounds checking for body/joint indices before accessing model arrays
  3. No explicit handling for unsupported constraint types
  4. No validation of constraint data before use
 for i, typ in enumerate(eq_constraint_type):
     if typ == newton.EQ_CONNECT:
+        # Validate body indices
+        body1_idx = eq_constraint_body1[i]
+        body2_idx = eq_constraint_body2[i]
+        if body1_idx >= len(model.body_key) or body2_idx >= len(model.body_key):
+            print(f"Warning: Invalid body indices in connect constraint {i}")
+            continue
+            
         eq = spec.add_equality(objtype=mujoco.mjtObj.mjOBJ_BODY)
         eq.type = mujoco.mjtEq.mjEQ_CONNECT
         eq.active = eq_constraint_enabled[i]
         eq.name1 = model.body_key[eq_constraint_body1[i]]
         eq.name2 = model.body_key[eq_constraint_body2[i]]
         eq.data[0:3] = eq_constraint_anchor[i]

     elif typ == newton.EQ_JOINT:
+        # Validate joint indices
+        joint1_idx = eq_constraint_joint1[i]
+        joint2_idx = eq_constraint_joint2[i]
+        if joint1_idx >= len(model.joint_key) or joint2_idx >= len(model.joint_key):
+            print(f"Warning: Invalid joint indices in joint constraint {i}")
+            continue
+            
         eq = spec.add_equality(objtype=mujoco.mjtObj.mjOBJ_JOINT)
         eq.type = mujoco.mjtEq.mjEQ_JOINT
         eq.active = eq_constraint_enabled[i]
         eq.name1 = model.joint_key[eq_constraint_joint1[i]]
         eq.name2 = model.joint_key[eq_constraint_joint2[i]]
         eq.data[0:5] = eq_constraint_polycoef[i]

     elif typ == newton.EQ_WELD:
+        # Validate body indices
+        body1_idx = eq_constraint_body1[i]
+        body2_idx = eq_constraint_body2[i]
+        if body1_idx >= len(model.body_key) or body2_idx >= len(model.body_key):
+            print(f"Warning: Invalid body indices in weld constraint {i}")
+            continue
+            
         eq = spec.add_equality(objtype=mujoco.mjtObj.mjOBJ_BODY)
         eq.type = mujoco.mjtEq.mjEQ_WELD
         eq.active = eq_constraint_enabled[i]
         eq.name1 = model.body_key[eq_constraint_body1[i]]
         eq.name2 = model.body_key[eq_constraint_body2[i]]
         eq.data[0:3] = eq_constraint_anchor[i]
         eq.data[3:10] = eq_constraint_relpose[i]
         eq.data[10] = eq_constraint_torquescale[i]
+    
+    else:
+        print(f"Warning: Unknown or unsupported equality constraint type '{typ}' at index {i}")
🧹 Nitpick comments (1)
newton/utils/import_mjcf.py (1)

612-613: Remove leftover debug code.

This debug print statement appears to be leftover development code that should be removed before merging.

-        if body_name == "thigh_right":
-            print(geoms)
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5ee4700adbe2fa69608c63e562ccbdfb08006270 and 4f8b03b91e781e11bcbef718812289abdad94c60.

📒 Files selected for processing (9)
  • newton/__init__.py (2 hunks)
  • newton/sim/__init__.py (1 hunks)
  • newton/sim/builder.py (5 hunks)
  • newton/sim/model.py (2 hunks)
  • newton/sim/types.py (1 hunks)
  • newton/solvers/mujoco/solver_mujoco.py (2 hunks)
  • newton/tests/assets/constraints.xml (1 hunks)
  • newton/tests/test_equality_constraints.py (1 hunks)
  • newton/utils/import_mjcf.py (4 hunks)
✅ Files skipped from review due to trivial changes (3)
  • newton/init.py
  • newton/sim/init.py
  • newton/sim/types.py
🚧 Files skipped from review as they are similar to previous changes (4)
  • newton/tests/assets/constraints.xml
  • newton/tests/test_equality_constraints.py
  • newton/sim/model.py
  • newton/sim/builder.py
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.
newton/solvers/mujoco/solver_mujoco.py (2)

Learnt from: Kenny-Vilella
PR: #398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

Learnt from: adenzler-nvidia
PR: #479
File: newton/solvers/mujoco/solver_mujoco.py:2147-2149
Timestamp: 2025-07-28T15:04:54.360Z
Learning: In the Newton MuJoCo solver implementation, the ls_parallel option may not be available in the pure MuJoCo mjOption structure, despite being documented in newer MuJoCo versions. The user adenzler-nvidia confirmed that mj_model does not have this attribute in their implementation, so ls_parallel should only be set on mjw_model.opt.

🧬 Code Graph Analysis (1)
newton/utils/import_mjcf.py (1)
newton/sim/builder.py (1)
  • add_equality_constraint (1313-1363)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run GPU Benchmarks (Pull Request)
🔇 Additional comments (3)
newton/utils/import_mjcf.py (3)

57-57: LGTM: Well-designed parameter addition.

The new parse_equality parameter with a default value of False provides a clean way to optionally enable equality constraint parsing without affecting existing functionality.

Also applies to: 86-86


766-853: Good implementation with past issues addressed.

The parse_equality_constraints function correctly addresses most of the issues from previous reviews:

✅ Fixed attribute references (using weld.attrib instead of connect.attrib)
✅ Added verbose checks for all debug print statements
✅ Properly defined anchor_vec before use
✅ Consistent body name sanitization with replace("-", "_")
✅ Proper extraction and usage of common attributes

The function handles the three supported constraint types (connect, weld, joint) appropriately and includes helpful warnings for unsupported site-based constraints.


883-888: LGTM: Proper conditional invocation.

The equality constraints parsing is correctly invoked only when both the <equality> element exists in the XML and the parse_equality parameter is enabled. The placement in the parsing flow is appropriate.

@kaloca

kaloca commented Jul 29, 2025

Copy link
Copy Markdown
Member Author

@adenzler-nvidia @eric-heiden

Chiming in on the architecture discussion, is it ok that we introduce these new variables in the Newton model dedicated to a Mujoco-only feature?

If it feels too Mujoco centric I could change the implementation to add an EqualityConstraint warp struct to types.py and have a model.equality_constraints array of Warp structs.

In the USD side, I spoke with Renato Gasoto about the Mjcf to Usd converter and it seems all loop-closing joints are marked with a excludeFromArticulation = 1 attribute. We could use that to filter them out in the initial topological sort and add them to the model later. So we might be able to avoid equality constraints.

@adenzler-nvidia

Copy link
Copy Markdown
Member

Ideally we would have a way to figure out what is an equality constraint at the time we initialize the solver. Then we can store those specific variables on the solver itself.

That requires us not to lose that information coming from the input file and making it through the modelBuilder and finalize. I think that's doable here by just introducing another model field that keeps track of whether a joint has this excludeFromArticulation flag set. I don't know how that will influence everything else though as you now suddenly have joints with dofs in the middle of articulations, so I think this requires a few changes in other places as well that rely on certain orderings.

I do think it's more general and will be a good fit for all the maximal coordinate solvers to have all the joints in the same place in the model. We could put the requirement that the joints of the same tree must be consecutive, if that helps.

Comment thread newton/sim/builder.py Outdated
Comment thread newton/tests/test_equality_constraints.py Outdated
Comment thread newton/utils/import_mjcf.py Outdated
kaloca added 6 commits July 31, 2025 12:36
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
@kaloca kaloca force-pushed the feature_equality_constraints branch from 4f8b03b to 7520245 Compare July 31, 2025 19:52

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
newton/utils/import_mjcf.py (1)

612-613: Remove leftover debug code.

This debug print statement appears to be leftover development code that should be removed before merging.

-        if body_name == "thigh_right":
-            print(geoms)
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4f8b03b91e781e11bcbef718812289abdad94c60 and 7520245.

📒 Files selected for processing (9)
  • newton/__init__.py (2 hunks)
  • newton/sim/__init__.py (2 hunks)
  • newton/sim/builder.py (6 hunks)
  • newton/sim/joints.py (1 hunks)
  • newton/sim/model.py (2 hunks)
  • newton/solvers/mujoco/solver_mujoco.py (2 hunks)
  • newton/tests/assets/constraints.xml (1 hunks)
  • newton/tests/test_equality_constraints.py (1 hunks)
  • newton/utils/import_mjcf.py (4 hunks)
✅ Files skipped from review due to trivial changes (2)
  • newton/sim/joints.py
  • newton/tests/assets/constraints.xml
🚧 Files skipped from review as they are similar to previous changes (5)
  • newton/init.py
  • newton/sim/init.py
  • newton/sim/model.py
  • newton/solvers/mujoco/solver_mujoco.py
  • newton/sim/builder.py
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: the use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crash...
Learnt from: Kenny-Vilella
PR: newton-physics/newton#398
File: newton/examples/example_mujoco.py:352-352
Timestamp: 2025-07-14T03:57:29.670Z
Learning: The use_mujoco option in newton/examples/example_mujoco.py is currently unsupported and causes crashes. The code automatically disables this option with a warning message when users attempt to enable it. This is intentionally kept as a placeholder for future implementation.

Applied to files:

  • newton/tests/test_equality_constraints.py
🧬 Code Graph Analysis (1)
newton/utils/import_mjcf.py (1)
newton/sim/builder.py (3)
  • add_equality_constraint_connect (1363-1392)
  • add_equality_constraint_weld (1425-1460)
  • add_equality_constraint_joint (1394-1423)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: Run GPU Benchmarks (Pull Request)
  • GitHub Check: Run GPU Unit Tests on AWS EC2 (Pull Request)
  • GitHub Check: run-newton-tests / newton-unittests (windows-latest)
🔇 Additional comments (7)
newton/utils/import_mjcf.py (3)

57-57: LGTM! Parameter naming and default value are well chosen.

The skip_equality_constraints parameter with default False correctly implements the suggestion from previous reviews to parse constraints by default unless explicitly disabled.


766-869: LGTM! Implementation addresses previous review feedback effectively.

The parse_equality_constraints function correctly implements:

  • Consistent body name sanitization with replace("-", "_") across all constraint types
  • Proper verbose checks around debug print statements
  • Correct attribute references (weld.attrib vs connect.attrib)
  • Proper variable definitions (common and anchor_vec)
  • Complete parameter extraction and builder integration

The function handles connect, weld, and joint constraints appropriately and includes proper warnings for unsupported site-based constraints.


899-905: LGTM! Clean integration of equality constraint parsing.

The integration follows the established pattern in the codebase with proper conditional checks and clear section organization. The logic correctly respects both the presence of equality elements and the user's preference via skip_equality_constraints.

newton/tests/test_equality_constraints.py (4)

25-40: LGTM! Comprehensive test setup.

The test properly configures simulation parameters and uses the new skip_equality_constraints=False parameter to enable constraint parsing. The use of a dedicated test asset file and relevant parsing options demonstrates good test design.


54-65: LGTM! Active simulation addresses previous feedback.

The implementation now includes a proper simulation loop instead of commented-out code, which directly addresses the previous review feedback. The nested loop structure and state management follow Newton patterns correctly.


66-82: Excellent test assertions that address previous feedback comprehensively.

The test now includes runtime validation that directly addresses previous concerns:

  • Verifies constraints were parsed and exist in the MuJoCo model
  • Validates constraint violations remain within acceptable thresholds (< 0.01)
  • Checks constraint forces are reasonable (< 1000.0)
  • Includes proper error messages with actual values for debugging

This is a significant improvement that tests both parsing correctness and runtime constraint behavior.


43-52: Ignore use_mujoco=True warning.

The MuJoCoSolver implementation in solver_mujoco.py fully supports use_mujoco=True—there are no built-in checks that disable it or emit warnings in the solver itself (the only explicit disablement is in the example script, not in the solver). It’s safe to run equality‐constraint tests with use_mujoco=True.

Likely an incorrect or invalid review comment.

@eric-heiden eric-heiden merged commit 3b112dd into newton-physics:main Jul 31, 2025
12 checks passed
@kaloca kaloca deleted the feature_equality_constraints branch July 31, 2025 21:38
@coderabbitai coderabbitai Bot mentioned this pull request Aug 12, 2025
5 tasks
@coderabbitai coderabbitai Bot mentioned this pull request Aug 21, 2025
5 tasks
@coderabbitai coderabbitai Bot mentioned this pull request Dec 24, 2025
4 tasks
eric-heiden pushed a commit to eric-heiden/newton that referenced this pull request Jan 28, 2026
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
mmacklin pushed a commit to mmacklin/newton that referenced this pull request Apr 7, 2026
Signed-off-by: Gabriel Noya <mega.kaloca@gmail.com>
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.

Handle kinematic loops

4 participants