-
Notifications
You must be signed in to change notification settings - Fork 31
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 PostureTask great again #22
Comments
Hello, Can this be related to #21 ? If we directly give least square instead of quadratic cost function to the solver then we will need to do what you said (Porting multi robot, Posture and force tasks to HighLevelTask). |
Hi, As for which abstraction the posture task belongs - I would prefer to allow it to inherit set-point or trajectory task behaviours (this is what is proposed if I understand correctly). As for using JointSelector with the posture task, I think this was somehow possible with the old python bindings through some trick but probably refactoring is the way to go. I think tasks is overdue for an overall refactor and cleanup - so much alternative code. |
Ok, I read #21 too fast. JointSelector has never work with PostureTask since it's kind of impossible to cancel a joint on an Hessian. I'm still a huge fan of this pull request since turning all constraint into a least square one could increase speed and reliability on some solvers. |
My mistake, I found the piece of code I was referring to - it's not using JointSelector. The workaround was to set individual JointStiffness differently so the effect is almost like JointSelector. |
I was playing around with PostureTask to see what it did and found in PostureTask::update |
You are right, this is a real bug. I don't think anyone ever truly used Tasks for spherical joints. Might warrant its own issue as this one is more concerned with refactoring / cleanup. |
Sorry for the clickbait title 😼
Currently
tasks::qp::PostureTask
is a bit of an outlier: it is a directtasks::qp::Task
while most other aretasks::qp::HighLevelTask
. The other offenders are either:TorqueTask
,ContactTask
)The only thing standing in the way of making it a
HighLevelTask
is to define it... Indeed, it already behaves as aSetPointTask
with the assumption that the jacobian is constant, equal to something that looks like the identity:Q
is set toJ
but it is equal toJ^TJ
in that casenormalAcc
is omitted because\dot{J} = 0
Making it a
HighLevelTask
would allow access, among other things toJointsSelector
, and allow to set reference velocity/acceleration.The text was updated successfully, but these errors were encountered: