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

Apply IK solution only when the solver succeeded #1266

Merged
merged 10 commits into from Apr 10, 2019
Merged

Apply IK solution only when the solver succeeded #1266

merged 10 commits into from Apr 10, 2019

Conversation

jslee02
Copy link
Member

@jslee02 jslee02 commented Mar 27, 2019

Problem

IK solvers apply solution even when the solver failed to solve.

Solution

Apply solution only on success.

Testing

Added a simple unit test that checks if IK solver changes joint values when the solver failed.


Before creating a pull request

  • Document new methods and classes
  • Format new code files using clang-format

Before merging a pull request

  • Set version target by selecting a milestone on the right side
  • Summarize this change in CHANGELOG.md
  • Add unit test(s) for this change

@jslee02 jslee02 added this to the DART 6.8.0 milestone Mar 27, 2019
@jslee02 jslee02 requested a review from mxgrey March 27, 2019 00:29
@jslee02 jslee02 marked this pull request as ready for review March 27, 2019 00:36
@mxgrey
Copy link
Member

mxgrey commented Mar 27, 2019

Applying the solution during a failure was intentional, because iterative solvers will often do a decent job of getting the end effector close to the target even if it failed to find a solution, and that's often desirable.

My personal view is that if the user wants the solution to be applied conditionally, they can set _applySolution to false and then choose after the fact whether they want the result to be applied based on whether or not it's a valid solution.

Maybe an alternative to make the behavior more clear would be to change the name of the input argument to _applyResult?

@jslee02
Copy link
Member Author

jslee02 commented Mar 27, 2019

Thanks for the clarification. I agree with you about iterative solver, but I'm a bit worried that the current IK implementation accepts any types of nonlinear optimizers. Non-iterative solver or analytic IK solver could return totally incorrect solution if the solution doesn't exist.

My personal view is that if the user wants the solution to be applied conditionally, they can set _applySolution to false and then choose after the fact whether they want the result to be applied based on whether or not it's a valid solution.

Yeah, this is possible, but I'd prefer the opposite. I mean the default behavior to be applying solution on success, and the user should apply solution by calling InverseKinematics::setPositions() if they want to use the incomplete solution from an iterative solver. This is because I think the safe and conservative way should be the default.

I'd like to propose three possible solutions:

(a) No change but renaming _applySolution
(b) Change the default value of _applySolution to false so that the user can pay attention to the behavior when set the parameter.
(c) Change the APIs to be more explicit something like

bool solve(Eigen::VectorXd& position);
bool solveAndApply(Eigen::VectorXd& position, bool allowIncompleteResult = false);
bool solveAndApply(bool allowIncompleteResult = false);

In any case, I think we should document more clear about the behavior.

@mxgrey
Copy link
Member

mxgrey commented Mar 28, 2019

I definitely understand where you're coming from, and I agree that we could make it better with some changes. One concern I have is that I'm sure I've written code that depends on the current behavior of solve(~), and I wouldn't be surprised if others have as well.

I guess we could deprecate the solve(bool) and solve(Eigen::VectorXd&, bool) functions and introduce solveAndApply(~) with the signatures you're suggesting. Then we could add a bool findSolution(Eigen::VectorXd& position) function that finds the solution without applying it.

@jslee02
Copy link
Member Author

jslee02 commented Mar 30, 2019

It sounds good to me! Let me update this PR accordingly.

@jslee02
Copy link
Member Author

jslee02 commented Apr 2, 2019

Done!

@jslee02 jslee02 merged commit b56a14f into master Apr 10, 2019
@jslee02 jslee02 deleted the bugfix/ik branch April 10, 2019 21:14
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.

None yet

2 participants