Skip to content
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

Reverts the setting of joint velocity limits from configuration #1873

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

Mayankm96
Copy link
Contributor

@Mayankm96 Mayankm96 commented Feb 15, 2025

Description

The previous fix in #1654 was checking if effort_limits_sim is None instead of checking cfg.effort_limits_sim for explicit actuators. This did NOT work as effort limits sim is a tensor that gets assigned the value on initialization.

The new fix now adds an implicit/explicit model attribute to the actuator model to ensure the right defaults are getting set. It moves all the implicit actuator warning code to its class to keep the articulation class cleaner.

We also revert the behavior of setting velocity limits for implicit actuators to the state before #1509. Before that change, the parameter velocity_limit was set in the configurations but not getting passed through. The MR #1509 allowed these values to be set which caused many of the assets to not train anymore or behave differently between IsaacLab versions. We now revert this behavior with a warning. If users want to set the limits, they should use the effort_limit_sim and velocity_limit_sim quantities.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Screenshot

The training of Allegro hand environment:

image

Checklist

  • I have run the pre-commit checks with ./isaaclab.sh --format
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have updated the changelog and the corresponding version in the extension's config/extension.toml file
  • I have added my name to the CONTRIBUTORS.md or my name already exists there

@Mayankm96
Copy link
Contributor Author

I will run the training and deploying for a sample set of our environments before merging this in. We really should make this a practice if we change something so burried into our architecture. Otherwise, it breaks so much for everyone.

On the other hand, we also need to add tests for actuators that are non-existent at this point and also the source of all the issues we are having with the recent changes.

@Mayankm96
Copy link
Contributor Author

I see the issues for implicit models not working still remain. The source of that problem is that in the past the users specified the velocity limit but it wasn't getting set. Now that we are setting them, those limits are causing the physics engine to behave differently.

Any suggestions on how to fix that? @jtigue-bdai

Maybe we should throw a warning in implicit if they specified velocity_limit and acknowledge the above and not set anything for velocity limit into the simulation till users actually use velocity_limit_sim?

@jtigue-bdai
Copy link
Collaborator

What environments are you running to check if things are working? Do those with implicit actuator environments have velocity_limit set? If so can we not remove that because they weren't doing anything before?

I'm not against warning the user if they set velocity_limit for implicit and only allow setting via velocity_limit_sim.

The tests I wrote are checking that the "xor" logic of setting limit vs limit_sim is propagating down to the physx level. But if there are still rogue unintended velocity_limit settings then those would get passed down.

My only other thought would be to revert the old change (i.e. don't pass velocity limit down) and then check to make sure that still works.

@Mayankm96 Mayankm96 changed the title Fixes the setting of velocity and effort limits for joints Reverts the setting of joint velocity limits from configuration Feb 20, 2025
@Mayankm96 Mayankm96 self-assigned this Feb 20, 2025
@Mayankm96 Mayankm96 added the bug Something isn't working label Feb 20, 2025
Mayankm96 and others added 2 commits February 20, 2025 19:22
…ator (#1923)

# Description

<!--
Thank you for your interest in sending a pull request. Please make sure
to check the contribution guidelines.

Link:
https://isaac-sim.github.io/IsaacLab/main/source/refs/contributing.html
-->

modifies explicit actuators to pass

<!-- As a practice, it is recommended to open an issue to have
discussions on the proposed pull request.
This makes it easier for the community to keep track of what is being
developed or added, and if a given feature
is demanded by more than one party. -->

## Type of change

<!-- As you go through the list, delete the ones that are not
applicable. -->

- New feature (non-breaking change which adds functionality)

## Checklist

- [ ] I have run the [`pre-commit` checks](https://pre-commit.com/) with
`./isaaclab.sh --format`
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] I have updated the changelog and the corresponding version in the
extension's `config/extension.toml` file
- [ ] I have added my name to the `CONTRIBUTORS.md` or my name already
exists there

<!--
As you go through the checklist above, you can mark something as done by
putting an x character in it

For example,
- [x] I have done this task
- [ ] I have not done this task
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants