[Feature request] Registration with constraints

[fferroni]

Hello,

Is it possible (or in the roadmap) to be able to add registration constraints to ICP / ransac? For example, if one is interested in registering a point cloud in only two directions, ignoring the third?

Thanks

[qianyizh]

Can you elaborate the use case? Just want to understand the background better to help us scope out the problem.

[fferroni]

Say for example in the case of a 3D LIDAR scan taken on a ground-plane, where we have a 2D motion, and we are only interested in estimating the transformation in 2 of 3 possible directions.

[qianyizh]

Good point. I think this is a common use case. I encountered this problem myself too. Sometimes the scanner has a gyroscope which provides quite accurate gravity direction and sometimes the north direction too. In this case registration algorithms should be able to use such information.

I am changing the title to feature request. And I think this should be prioritized.

[nicolas-chaulet]

Hi All, Has there been some progress on that? I would actually be very interested in such feature and happy to help as well.

[qianyizh]

No progress based on my knowledge. Unless @syncle is working on something I don't know yet, :)

[YouYue123]

Any plans to make this change?

Something like how cloudcompare did it would be nice

https://www.cloudcompare.org/doc/wiki/index.php?title=ICP

[germanros1987]

It seems the feature request didn't gain enough momentum... It is in our roadmap but with low priority. This could be a nice contribution...

[YouYue123]

I would like to contribute to this feature

But any idea about how to restrict the rotation constrain in Umeyama algorithm for transformation estimation? This is the method Open3D is using for point to point transformation estimation https://github.com/intel-isl/Open3D/blob/master/src/Open3D/Registration/TransformationEstimation.cpp#L60.

Or any other math model I can use for transformation estimation with constraints. I am a bit stuck there.

[germanros1987]

@YouYue123 I guess the most straightforward option would be to re-implement the Umeyama algorithm in its least-square form and add some lagrangians to account for the constraints.

@qianyizh any feedback? Is there anything like that already out there?

[qianyizh]

I think @syncle has a plan to work on this.

[germanros1987]

@qianyizh I think @syncle is going to have his plate full for the short-term. We should try to get this done.

Do you have a technical opinion about this?

[YouYue123]

@germanros1987 will that be something like a Constrained Ordinary Linear Least Square with Lagrange multipliers? Here is what I found http://people.duke.edu/~hpgavin/cee201/constrained-least-squares.pdf

@qianyizh Let me know your thought on this option. That will help a lot thanks!

[germanros1987]

@theNded you are the one working on topics related to this, so I am sending this ball your way.

[theNded]

@YouYue123 Hi, I think we only need to parameterize our rotation as 2D rotations (with only one parameter), while we retain the 3D translation. The critical point is that in many cases we don't know the axis to align to, since the 'world coordinate system' defined by LiDAR does not usually match the 'real world coordinate system' defined by gravity. This is also not easy to do automatically AFAIK. An option is to ask the user to input this calibration -- what do you think?

In other words, the function signature will look like ICP(pcd0, pcd1, axis=some 3d rotation axis). Internally, our rotation is represented by rodrigues(axis, theta) where theta is our parameterization. FYI: Rodrigues rotation formula.

[szx0112]

Hi, any updates in this feature? I am a similar use case but requires to restrict the 3D translations, instead of the rotations, for each estimated pose.

[ssheorey]

Related: #3846

[madsherlock]

For the record, it appears someone implemented this feature, or something very similar, in a fork two years ago, to be used in AlignNet-3D.