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

Make linear trajectories depend on velocity instead of time #157

Open
PeterBowman opened this issue Jun 28, 2018 · 2 comments
Open

Make linear trajectories depend on velocity instead of time #157

PeterBowman opened this issue Jun 28, 2018 · 2 comments
Assignees
Labels
blocking Focus on this issue before working on issues that are blocked by it priority: idea

Comments

@PeterBowman
Copy link
Member

PeterBowman commented Jun 28, 2018

Split from #46 and influenced by #121, we'd like to tweak another parameter that governs the CMC (movl command). Currently, generated trajectories obey a duration value passed by the controller, but fail on run time if a maximum specified joint velocity is reached in any joint. This issue is focused on fixing a joint cartesian velocity instead so that the controller may adjust the trajectory duration accordingly. Note that this is how the movj command works (by enforcing isochronous trajectories in all joints) and, conversely, it could depend on duration.

Vaguely related, we could benefit from a dry run mechanism to perform tests: #156.

@PeterBowman PeterBowman added this to ToDo in [ROBOTICSLAB] via automation Jun 28, 2018
@PeterBowman PeterBowman moved this from ToDo to Nice ideas in [ROBOTICSLAB] Jun 28, 2018
@PeterBowman PeterBowman added the blocking Focus on this issue before working on issues that are blocked by it label Jul 19, 2018
@PeterBowman
Copy link
Member Author

Would block #159.

@PeterBowman
Copy link
Member Author

PeterBowman commented Feb 15, 2023

Vaguely related, we could benefit from a dry run mechanism to perform tests: #156.

Joint velocities can be checked offline (i.e. prior to sending motion commands) in MOVL with --enableFailFast (26f8c35), and it's better used along with --usePosdMovl (#193 (comment)).

I believe the velocities that should be actually regarded are the cartesian ones. KDL::VelocityProfile_Trap has a convenient SetProfileVelocity method. Warning: here, newvelocity is a fraction (contained within [0.0, 1.0]) to be applied on the default maximum velocity.

@PeterBowman PeterBowman self-assigned this Feb 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking Focus on this issue before working on issues that are blocked by it priority: idea
Projects
None yet
Development

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

1 participant