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

Add velocity_limit_sim and effort_limit_sim to actuator #1654

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

Conversation

jtigue-bdai
Copy link
Collaborator

@jtigue-bdai jtigue-bdai commented Jan 9, 2025

Description

This PR follows up on Issue 1384 and PR 1509 by seperating actuator limits for calculating computed torques from physics solver limits.

Fixes # (#1384)

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Screenshots

Please attach before and after screenshots of the change if applicable.

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

@jtigue-bdai jtigue-bdai self-assigned this Jan 9, 2025
@jtigue-bdai jtigue-bdai marked this pull request as ready for review January 9, 2025 18:00
@zoctipus
Copy link
Contributor

zoctipus commented Feb 12, 2025

I like this! and enjoyed the insightful discussion in PR1509

I think previous commit that write the velocity limit in actuator cfg to simulation-level velocity limit broke some of my quadrupet training, and I only figured it out because of the commit before that one worked.
I hot fixed it by setting the velocity limit to the value 2* more than factory recommendation for sim to work, but after this fix I can change back the velocity limit back to normal value!

Copy link
Collaborator

@renezurbruegg renezurbruegg left a comment

Choose a reason for hiding this comment

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

Nice, Thank you!
I think this fix/feature is much needed.

self.write_joint_armature_to_sim(actuator.armature, joint_ids=actuator.joint_indices)
self.write_joint_friction_to_sim(actuator.friction, joint_ids=actuator.joint_indices)
else:
# the gains and limits are processed by the actuator model
# we set gains to zero, and torque limit to a high value in simulation to avoid any interference
self.write_joint_stiffness_to_sim(0.0, joint_ids=actuator.joint_indices)
self.write_joint_damping_to_sim(0.0, joint_ids=actuator.joint_indices)
self.write_joint_effort_limit_to_sim(1.0e9, joint_ids=actuator.joint_indices)
self.write_joint_velocity_limit_to_sim(actuator.velocity_limit, joint_ids=actuator.joint_indices)
self.write_joint_effort_limit_to_sim(actuator.effort_limit_sim, joint_ids=actuator.joint_indices)
Copy link
Collaborator

@renezurbruegg renezurbruegg Feb 12, 2025

Choose a reason for hiding this comment

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

This could lead to some breaking changes, since the upper limit of the drives is not 1e9 anymore? Maybe change this to actuator.effort_limit_sim if actuator.effort_limit_sim is not None else 1.0e9 or change the default value from None to 1.0e9?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah good call. I will change the default to 1.0e9

@jtigue-bdai jtigue-bdai force-pushed the jat/fix/velocity_limit_sim branch from c7fef1e to b08422e Compare February 12, 2025 17:35
Comment on lines 54 to 55
If None, the limit is set to the value specified in the USD joint prim. The simulation effort limits prevent
computed torques from exceeding. If effort limits are too tight issues with solver convergence may occur.
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we maybe give a hint here that it is recommended to set these values higher?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Actually I just updated the default behavior based off @renezurbruegg's suggestion. I should update to reflect that.

Co-authored-by: Pascal Roth <57946385+pascal-roth@users.noreply.github.com>
Signed-off-by: James Tigue <166445701+jtigue-bdai@users.noreply.github.com>
Comment on lines +61 to +62
If None, the limit is set to the value specified in the USD joint prim. Resulting solver solutions will constrain
velocities by these limits. If velocity limits are too tight issues with solver convergence may occur.
Copy link
Collaborator

Choose a reason for hiding this comment

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

also here we could give the hint

Signed-off-by: James Tigue <166445701+jtigue-bdai@users.noreply.github.com>
Copy link
Collaborator

@pascal-roth pascal-roth left a comment

Choose a reason for hiding this comment

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

Some smaller comments, otherwise LGTM, lets get this merged soon

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.

5 participants