-
Notifications
You must be signed in to change notification settings - Fork 80
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
bio_ik produces weird ik solutions #21
Comments
Hi, thanks for reporting.
Could you send us the necessary files to reproduce the issue (URDF, MoveIt configuration, and your test script)? |
I added minimal files to produce the issue to our branch: It contains:
While you won't be able to visualize the robot as most of our robot_description is hosted in private repos, you should still be able to get an idea of what's going on. Just run:
It will run for a while - current ik timeout is quite high - and at the end you will see something like:
The
Let me know whether you can run/reproduce our files - and whether you need additional info. |
Hi, I was able the reproduce the issue and am working on a fix. The problem can appear if there are mimic joints as well as revolute joints with a range of 2*pi or more. In your case, as a temporary workaround, you can simply remove or comment out |
Thanks for looking into it...looking forward to the fix...
But I wonder why this check did not kick in? |
I can confirm that mojin-robotics@3873bc1 prevents bio_ik from returning ik solutions whos FK is off the initial pose in the ik request... Some more observations:
|
If it's a revolute joints with an angular range larger than 2pi and if it's neither a mimic joint nor being mimicked by a different one, the joint limits are first ignored while searching for an IK solution. Afterwards, the result is wrapped to a solution close to the initial pose in line 561 ff. When the wrapping did not happen,
The kinematics configuration in the files you sent me (they were merged into a single
In
That indicates that it's an issue with the goal configuration (
That's to be expected.
Most solvers in |
> `kinematics_solver_search_resolution` doesn't seem to have any effect
In `bio_ik`, the stop criterion can be configured using the parameters `drot`, `dpos` and `dtwist` (default: `1e-5`). As far as I know, `kinematics_solver_search_resolution` was intended for a different purpose.
The `search_resolution` parameter is not relevant here.
It's used to *discretize* one joint range and look for solutions assuming the fixed joint.
A rather irrelevant use-case nowadays.
> `kinematics_solver_attempts` doesn't seem to have any effect either (is deprecated in melodic anyway)
Most solvers in `bio_ik` do their own restarts. `kinematics_solver_attempts` should be set to 1, setting it to a different value only makes it slower.
This parameter was dropped in MoveIt melodic+, exactly because all solvers do their own internal restarts as they see fit.
|
Signed-off-by: Tyler Weaver <[email protected]>
Hi! How can I set It seems that there parameters are not available in Thanks! |
any updates on this fix? I posted #48 as a companion issue. |
we were testing bio_ik as the kinematics plugin for moveit for a custom manipulator (total of 7 joints, including linear and mimic joints)
we observe the following:
❌ in some cases, fk pose of ik_solution is way off the random goal pose both wrt position (up to 0.5 m!) as well as orientation
to give numbers:
of 100 tests, we get like 65 poses where NO_IK_SOLUTION is reported (which is ok - because fully random poses might not be reachable by our manipulator), and of the 35 poses where SUCCESS is reported by compute_ik, about 7 have this weird ik solution, i.e. fk of ik solution differs significantly from the pose in the ik request
has anybody observed something similar?
is bio_ik able to handle linear joints?
is bio_ik able to handle mimich joints?
any idea how we could debug this any further?
would it make sense to add a "fk verification step" that does the fk of ik solution and compares it to the pose in the request and overwrites the outcome in case the pose diff is significant?
@v4hn @philipp1234 @rhaschke
The text was updated successfully, but these errors were encountered: