Additional optimization-based solver

[timonegk]

Hi, I recently experimented with some inverse kinematics solvers other than KDL/PickIK/BioIK and stumbled upon RelaxedIK and its derivatives. Because it is implemented in Rust and has a very poor ROS wrapper, I reimplemented the basic algorithm in C++ as a MoveIt plugin. The results are very good and, at least on the examples I already tested, outperform all three solvers mentioned above.

Would you be interested in including this solver as a third mode next to the global and local modes?

Example benchmarking

This quantitative example is with the UR10 robot on a small table, IK is calculated for all red arrows on the table, the robot must not collide with the table.

Success rates (ur10 on small_table):
RelaxedIK: 1.0
BioIK: 1.0
PickIK: 0.88
KDL: 1.0
Solve times (ms) (ur10 on small_table):
RelaxedIK: 2.06 ms ± 1.37 ms
BioIK: 3.31 ms ± 1.91 ms
PickIK: 24.23 ms ± 20.29 ms
KDL: 8.19 ms ± 6.20 ms

Note that PickIK with default parameters only managed to solve 88 of 100 points within the time frame of one second.

[sea-bass]

That's really nice! Do you have a link to your C++ reimplementation?

In my tests, TRAC-IK also works around the same order of magnitude timing as KDL and RelaxedIk, with good results. So those solvers seem to work best unless you need some very complex set of constraints that have no analytical gradients, where BioIK/PickIK can possibly help despite the increased solve times.

Then, there is this standing issue... https://github.com/PickNikRobotics/pick_ik/issues/60

[sea-bass]

As for your question, I think what would be preferable is for your solver implementation to be a standalone repo/plugin, unless you wanted to combine it with the evolutionary algorithm component of PickIK? (Which to me is almost always unnecessary)

[timonegk]

That's really nice! Do you have a link to your C++ reimplementation?

Sure, I just pushed the code to https://github.com/timonegk/relaxed_ik_cpp. The implementation is not very clean yet and some goals that I did not need from the original paper are not implemented yet. But the basic solver works. I might move the repository to another organization in the future, though.

In my tests, TRAC-IK also works around the same order of magnitude timing as KDL and RelaxedIk, with good results. So those solvers seem to work best unless you need some very complex set of constraints that have no analytical gradients, where BioIK/PickIK can possibly help despite the increased solve times.

Analytical gradients are not required for RelaxedIK, the gradients are determined numerically, so this is not necessarily a problem. Still, PickIK might be better at exploration and avoiding local minima.

Then, there is this standing issue... #60

I'm aware of the issue, but this aims to achieve at most bio_ik's performance which is still outperformed by RelaxedIK, so the project might still be relevant to increase overall performance.

As for your question, I think what would be preferable is for your solver implementation to be a standalone repo/plugin, unless you wanted to combine it with the evolutionary algorithm component of PickIK? (Which to me is almost always unnecessary)

My main interest in combining the repositories is that there is a lot of code duplication for different goals and the overall structure. Including RelaxedIK with PickIK might make the project more of a one-fits-all solution and I can imagine that some ideas from RelaxedIK/RangedIK, i.e. the groove and swamp loss, might also be usable with the BioIK algorithm.

In general, this is more of a conceptual question: Does PickIK want to be a universal solution for inverse kinematics that provides different solvers for different needs in a cleanly implemented way? I, personally, would approve of that because I think that the community would profit from a solution that is easily available, not some research code that was written ten years ago and hasn't been changed since, and can quickly be adapted to their needs by changing some parameters.

[sea-bass]

I see, thanks for sharing!

To be honest, we sort of ditched PickIK because we found other solvers worked better, at least in the no-constraints case. So there is no such goal to have this be a standard anything going forward.

BUT if RelaxedIk is also numerical, can drastically improve performance, and you have interest integrating it, that could be grounds for turning this around. I will be happy to review your changes.

[timonegk]

To be honest, we sort of ditched PickIK because we found other solvers worked better, at least in the no-constraints case. So there is no such goal to have this be a standard anything going forward.

Oh, that's sad to hear! To which solvers did you move?

BUT if RelaxedIk is also numerical, can drastically improve performance, and you have interest integrating it, that could be grounds for turning this around. I will be happy to review your changes.

Great! I'll try to integrate it some time soon, but I cannot make any promises...

[sea-bass]

Oh, that's sad to hear! To which solvers did you move?

Mostly TRAC-IK! Its's very nice, but again no custom constraints off the shelf in their open source version