Feature: JointIterativeClosestPoint

[sdmiller]

When doing, e.g., extrinsic calibration between two sensors, it's common to want to leverage multiple observations and solve for a single global transform. JointIterativeClosestPoint implements a very generic version of that. It uses the IterativeClosestPoint framework, but allows for multiple pairs of Source/Target clouds to be given. It then uses the given CorrespondenceEstimation methods to compute correspondences separately, but solves for a global transform.

A few things which would still be nice:

• As referenced in other issues, our CorrespondenceRejector class doesn't currently expose any sort of virtual "addInputSource/Target" functionality. So there's no way to do that generically here. For any data-driven rejector (just about all of them?), this method probably won't work.
• It'd be great to have generic cloning functionality for CorrespondenceEstimators. Then a user could simply set one, and I'd clone it for all pairs of clouds. Currently it either requires the user to manually set a separate one for each, or uses one default method.
• To keep the API the same, I still have it return an output cloud (empty), and use aggregated versions of the source and target clouds for parent-level calls, like Registration::computeFitness. This could be handled more nicely.

[jspricke]

Hi @sdmiller could you use the template provided in https://github.com/PointCloudLibrary/pcl/blob/master/LICENSE.txt?

[sdmiller]

No problem -- did you just mean adding a self-copyright (the "respective authors" section? I don't really care about that, but I can add if it's now required.) Otherwise they seem identical to me, modulo maybe some spacing issues. I just pushed a cut-and-pasted version to cover my bases