Skip to content

Update task and IK solver to support reduced configuration; add tests… #88

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

wayne-xyz
Copy link

Description

Added support for reduced configuration in the robot control system. This allows working with a subset of joints while maintaining compatibility with the existing task and IK systems.

Changes

  • update the task.py and solv_ik.py
  • Added comprehensive tests for reduced configuration for both test_configuration and test_solve_ik

Testing

  • All tests pass: pytest .

Related Issues

Link of issue

Checklist

  • Code follows the project's style guide Contribute
  • All tests pass
  • CHANGELOG updated
  • No sensitive data in commits
  • Branch is up to date with main

@kevinzakka
Copy link
Owner

Hi @wayne-xyz, first of all, thank you for your PR :)

I'd like to first ask you if you've tried creating a reduced model and instantiating the configuration object on that reduced model, then using qpos indices to correctly take the output of configuration.q and assign it to the main simulation MjData? That's typically my workflow for such a situation. Especially with the maturity of MjSpec, it has become easy to create modular XML entities (e.g., mobile base, arm, gripper) and then compose them into a final MjModel.

@adlarkin
Copy link
Contributor

Chiming in here, but I also believe something related was discussed in #73 - I personally tried approach 1 in Kevin's comment (DampingTask with a high damping cost on joints to immobilize) for a few of my own use cases and have found that it works well if the goal is to emulate running IK on only a subset of joints.

@wayne-xyz
Copy link
Author

wayne-xyz commented Jun 1, 2025

Hi @kevinzakka ,

Thank you so much for your quick reply and the valuable suggestion! I really appreciate you taking the time. This is a great repository, and it's been incredibly helpful and flexible for my use case and studies.

Regarding your suggestion to create a reduced model with MjSpec for the IK configuration: that's indeed a clean and generally preferred approach. My current project, however, is based on bigym and gymnasium. These frameworks have a fairly tight coupling between their environment and mujoco.model , and they seem to be a bit behind the latest MjSpec advancements for dynamic model editing.

In my specific scenario, the simulation involves several entities, but the IK solution only needs to focus on one or two of them. The approach in my PR aims to support this by allowing the IK solver to operate on a configuration with a reducednv , without needing to recompile a structurally different MjModel each time. This was a pragmatic way to handle the constraints imposed by bigym's current model management.

I agree that keeping mink focused and specific to its domain is important. If this feature doesn't align well, I completely understand.

Looking ahead, I am strongly considering refactoring my project to reduce the dependency on bigym precisely to overcome these limitations and better leverage modern MuJoCo features like MjSpec for more flexible model manipulation.

Thanks again for your feedback and for maintaining mink!

@wayne-xyz
Copy link
Author

Chiming in here, but I also believe something related was discussed in #73 - I personally tried approach 1 in Kevin's comment (DampingTask with a high damping cost on joints to immobilize) for a few of my own use cases and have found that it works well if the goal is to emulate running IK on only a subset of joints.

Thanks for bringing up the DampingTask method from #73! Immobilizing joints with high damping is an interesting way to focus IK, and it's good to hear it worked for you.

@Tadinu
Copy link

Tadinu commented Jul 10, 2025

I would give a vote for what @kevinzakka suggested, given its focused functionality, basically we can run mink on various behind-the-scene ghost models then get the ghost outputs selectively fed back to the main MjData.
Practically, the environment almost always has actuated objects (typically free-joints) aside from robots themselves, so maybe it'd burden solver if on every frame solving for the whole main MjModel which includes those objects dofs as well.

For instance, it's also done in a MJX batched ik counterpart of mink:
https://github.com/based-robotics/mjinx

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.

4 participants