libpointmatcher
libpointmatcher copied to clipboard
norlab-ulaval
Adding the ability to force 4DOF minimization in the point-to-Gaussian
This adds the possibility to set the point-to-plane to minimize only x,y,z and yaw values.
@kubelvla Is this feature still planned to reach master soon?
I imagine it being used in a SLAM context, to optimize XYZ+Yaw with ICP, and the rest with an IMU, which sounds quite useful!
Is this PR related to what's shown in this video?
I have a bit of a conceptual question: how possible is it to make the ICP optimization operate in arbitrary sub-spaces?
For example, let's say that we want to operate only in x,y,z or only yaw. Would it be very different to implement that?
That depends on the error function you wish to minimize. I've only played with point-to-plane because it has a nice aproximative solution which is easy to modify. In the point-to-point, I presume that modifying the rotation part would be more challenging (but maybe, if we dropped the closed-form solution and replaced it with something aproximative it would become easier), but haven't tried that yet. Removing rotation altogether (doing only x,y,z) from the point-to-point and point-to-plane is straightforward. We are actually exploring all this this summer, mainly focusing on point-to-gaussian.
@vdsmax Could you please eventually add your fix for the point-to-gaussian that you did with the additional measurement noise?
@kubelvla Could this feature be integrated into master for the point to plane in the very short term, and then bring in the implementation for the other error minimizers?
@kubelvla Could this feature be integrated into master for the point to plan, and then bring in the implementation for the other error minimizers?
@vdsmax Could you please eventually add your fix for the point-to-gaussian that you did with the additional measurement noise?
@kubelvla i will add the change today
@YoshuaNava Merged master into this branch. Yet, work on the point-to-gaussian is in progress, we will be working on that this summer. The minimizer needs to be tested more. Should we keep this PR hanging to keep this conversation, or should I close it for now?
@YoshuaNava Merged master into this branch. Yet, work on the point-to-gaussian is in progress, we will be working on that this summer. The minimizer needs to be tested more. Should we keep this PR hanging to keep this conversation, or should I close it for now?
I think we should keep it. The change introduced by this branch is atomic and it should be easy to keep it up to date and work on it.
@kubelvla there seems to be some effort in that PR. Can we do something to progress?
@pomerlef How's Point-to-Gaussian behaving? @vdsmax @simonpierredeschenes have you been using that after I left?
I did not use it on my side unfortunately, but I think @vdsmax did
@pomerlef The 4DOF part is just an implicit part of this pull request, since it is a part of the point-to-plane minimizer. I am not sure if there actually was any more work done on the point-to-gaussian minimization after Max had played with that for some time (was it the Blimp project he used that for?) So the question is whether we want this to be released (with 4DOF or without), or if you want to put some student on it (and then the question is how to generate the gaussian "points" - it was from GPS at some point, that was the motivation for Bab, right?)
The point to Gaussian feature was not used too much. I did some basic tests to see if the mapping was working with this new minimization, but it needs more testing to be release. It was not used in other projects.
I'm actually not sure what to do with this PR. I'll close it. Just re-open it if someone wants to work on it (but from the conversation I doubt it).