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

Softstart support? #161

Open
tkevinbest opened this issue Oct 26, 2023 · 1 comment
Open

Softstart support? #161

tkevinbest opened this issue Oct 26, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@tkevinbest
Copy link
Member

🚀 Feature Request

I've used a "soft start" before to make it so torque is applied gradually when the motors first power up. Should we make this a built in part of the repo? I'm thinking something like

osl = OpenSourceLeg(frequency=..., ..., use_soft_start = True, soft_start_time = 1.5)

and then in the write to joints functions, we would just scale by a saturating ramp from 0 to 1 over the soft_start_time. We would scale either the current commands, voltage commands, the stiffness and damping, or the P and D gains depending on mode.

🔈 Motivation

Comfort, lack of scariness. Participants usually don't like it when high-jerk torque profiles are applied.
If you're starting in impedance or position control and you're way away from the desired position, you'll get a very snappy torque right at startup.

@tkevinbest tkevinbest added the enhancement New feature or request label Oct 26, 2023
@imsenthur imsenthur self-assigned this May 8, 2024
@tkevinbest tkevinbest self-assigned this Jun 7, 2024
@tkevinbest
Copy link
Member Author

Made some progress on this. Overall workflow will be

  1. User requests joint.start_torque_ramp(ramp_time) to begin torque ramping from 0 to 100% over ramp_time. This will be allowed in current control mode, position control mode, and impedance control mode.
  2. Each subsequent joint.update() method will update the ramp value and the torque command. If you don't call update, your torque command won't change. Use it correctly!
  3. We need to keep track of the previous command and scale it appropriately - ie we need a copy of requested_torque etc in memory. This means this should probably go in the actuators class.

Tabling this for now until the refactor of the actuators class is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In progress
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants