Skip to content

Fixes DCMotor clipping for negative power and adds actuator tests #2300

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 32 commits into
base: main
Choose a base branch
from

Conversation

jtigue-bdai
Copy link
Collaborator

@jtigue-bdai jtigue-bdai commented Apr 11, 2025

Description

This PR adds tests for actuator initialization, configuration, and computation for Implicit, IdealPD, and DC motor actuators.

This PR also updates the DCMotor model to clip based on a four quadrant DC motor model. This will fix improper clipping in the negative power regions (i.e. positive torque and negative velocity or negative torque and positive velocity).

NOTE: This PR is dependant on the pytest migration in: 2034
This PR includes changes made in 2291 and would be an alternate candidate.

Fixes #2139

Type of change

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

Screenshots

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

@jtigue-bdai jtigue-bdai changed the title Fix DCMotor clipping for negative power and add actuator tests Fixes DCMotor clipping for negative power and adds actuator tests Apr 11, 2025
@kellyguo11
Copy link
Contributor

hmm looks like the DC motor and environment tests are both failing, along with a few others, but not sure if they are all related to this change

@jtigue-bdai
Copy link
Collaborator Author

jtigue-bdai commented May 16, 2025

hmm looks like the DC motor and environment tests are both failing, along with a few others, but not sure if they are all related to this change

It seems there is something happening with the ActuatorNetLSTM actuators in AnymalC that is producing nan values. Will continue investigating.

@Mayankm96 anything about this spark ideas?

@@ -90,7 +90,9 @@ def compute(
self.computed_effort = torques.reshape(self._num_envs, self.num_joints)

# clip the computed effort based on the motor limits
self.applied_effort = self._clip_effort(self.computed_effort)
self.applied_effort = torch.clip(
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm is there a reason why the actuator net doing an additional clipping? It should just use the DC motor characteristics

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is trying to handle the added torque speed curve outside the effort limit that is interacting with the Anymal-C net actuator. I fixed the environment tests but its causing issues in the benchmarking. (see other comment in DC motor)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Mayankm96 I can't seem to get the benchmarking for Anymal-C to resolve with the new DCMotor. Do you know how that environment's ActuatorNetLSTM network was trained? Will we ever get agreement if the DCMotor clipping has changed?

Copy link
Contributor

Choose a reason for hiding this comment

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

maybe @pascal-roth or @ClemensSchwarke might know as well?

Comment on lines +305 to +308
gt_vel_at_effort_lim = self._joint_vel > self._vel_at_effort_lim
lt_vel_at_neg_effort_lim = self._joint_vel < -self._vel_at_effort_lim
clamped[gt_vel_at_effort_lim] = torque_speed_top[gt_vel_at_effort_lim]
clamped[lt_vel_at_neg_effort_lim] = torque_speed_bottom[lt_vel_at_neg_effort_lim]
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we need to do recomputation here since (torque_speed_bottom, torque_speed_top) shouldn't lie outside (-effort_limit, effort_limit) for cases where velocity is higher than the actual velocity limits.

Maybe I misunderstand a bit, but shouldn't just the clipping once be sufficient?

Copy link
Collaborator Author

@jtigue-bdai jtigue-bdai Jun 4, 2025

Choose a reason for hiding this comment

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

what this handles is the event that the joint if forced to higher velocities from outside forces like gravity when landing after a jump. A motor will provide resistivity torque regardless of an "Effort limit". It may damage circuits, motors, or mechanical components when it does it but the actuator will try to resist.

It a pretty specific use case so i could see having this be configurable if people want to model that.

It is likely a cause of the issues I am seeing with the Anymal-C LSTM net actuators in benchmarking.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah might make sense to also draw -satuation_effort and also only shade the region within the velocity limit? Otherwise it may not get confusing that shaded region lays outside the bounds of the joint?

Copy link
Collaborator Author

@jtigue-bdai jtigue-bdai Jun 4, 2025

Choose a reason for hiding this comment

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

I can add the -saturation_effort. What do you mean by shade the region within the velocity limit? Do you mean only the area in red?
image

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.

[Proposal] More thorough testing of actuators
3 participants