I wonder if there is any need to introduce globally optimal hand-eye calibration solver to OpenCV? Existing solvers in OpenCV are analytical and cannot guarantee global optimality, in the case of degeneration or missing measurements. We have just released one library https://github.com/zarathustr/LibQPEP, which was just published in IEEE Transactions on Robotics. This library only requires Eigen for computation so is light weight. Maybe we can make an OpenCV-based version and merge that?

@zarathustr

As a simple OpenCV user, I would definitively support the introduction of state of the art algorithms for PnP functions and Hand-Eye calibration functions.

Hand-Eye calibration is needed when mixing computer vision with robotics, e.g. like visual-servoing tasks.
I have added these functions since there are easy to be ported in C++, but as you have already noticed are analytical and can be easily prone to measurement errors.

I believe Eigen requirement can be ok as long as it is documented and appropriately handled to warn the user if OpenCV has not been compiled with Eigen support.
For sure, a pure C++ porting would be ideal.

About PnP functionality, I think solvePnPGeneric() (in addition to solvePnP() function) can be adapted if you want to return also covariance or if an approach can return multiple solutions.

About Point-to-plane Registration, it fits the OE 33. 3D Module I think.

OpenCV is licensed under the Apache-2.0 license, and thus your code should also comply with it.

There is also #15650 work for a better, class-based, interface of the PnP functions.

I believe moving slowly is the way to go, but in the long term the class-based approach should be adopted.

What about adding Eigen as a private third-party library into OpenCV?
Eigen is pretty standard for Maths, this should simplify the integration of advanced algorithms.