I am doing some tests on ICP algorithms.
The documentation in PCL looks a bit too concise. For example it is not clear to me the meaning of the parameters in the standard ICP pcl::IterativeClosestPoint. What is exactly "epsilon : (difference) between transformations" ?
What is the advantage given by changing the EuclideanFitnessEpsilon?
Would be useful to have some reference for these concepts.
Is the Levemberg-Marquardt ICP an implementation of Fitzgibbon's 2001 paper? If not, is it possible to have a reference ?
Then, I noted that the classic ICP seems a bit slow on my Pc ( i7 quadcore, win 64). Even if I disabled openMP due to a compatibility problem (as suggested by Mourad) i see about 2 sec for two consecutive frames (from XTION pro) when the scene does not change and much more when the scene changes (arriving at one minute). Is it normal?
The clouds contain around 160K points (after Nan elimination), so they are not too big.
I did many similar tests with matlab trying to evaluate the convergence of ICP classic, LM ICP (Fitzgibbon 2001) and the trimmed ICP of Stepanov. I expected a drastic speed up from PCL but with standard ICP my matlab implemetations is faster! Not still tried trimmed ICP or LMICP.
Any suggestion ?
If someone tried to ICP-register a couple of frames from Kinect which is the expected time ?
I do not know exactly what .sum() does but seems obvious, it sums all the entries of the transformation matrix.
Then, if you sum the differences they can give zero even if their absolute values are far from being zero.
I would espect something like (fabs(transformation_ - previous_transformation_)).sum() where fabs here works on all the matrix entries.
I do not see the advantage of using the LM method.
It is not one-shot as in the case of Fitzgibbon work. Here there are iterations of calls to LM each one iterating.
Why using LM, it seems slowler than normal ICP, is its convergence basin bigger?
Hi, I mean that in that work LM is called once.
Then of course LM is an iterative method. In PCL LM is called more than one time, and every time it iterates.
Simply it seems PCL does not implement that solution. It is just another way to find the estimateTransformation (as you said). In this case I do not see the advantage of using LM.
in the paper it's suggested to recalculate the closest points in each step of changing a parameter. So the implementation of pcl seems to be correct. But it's also stated that there isn't any advantage in direct comparision between ICP and LM ICP. But LM allows to use different distance metric (like GICP does).
In my opinion ICP, LM ICP or GICP should not be used for Kinect depth data.
On Thu, Apr 5, 2012 at 4:02 AM, Waltz <[hidden email]> wrote:
> Regarding point 1) PCL implementation seems wrong.
> I see this in the exit test:
> fabs ((transformation_ - previous_transformation_).sum ()) <
> transformation_epsilon_ || ...
> Please verify if this is a bug.
Yeah, that's computing the absolute value of the sum, but it needs to
be the sum of the absolute values. I've created a ticket
(http://dev.pointclouds.org/issues/660), and we'll make sure it gets
fixed for the next release. Thanks!
The score is not the average distance between corresponding points (as one would expect).
It is a kind of variation of average distances between two consecutive iterations.
1) It is not a Score for the registration quality, it is an information for stopping the iterations.
2) It is wrong. Should be a kind of (abs(map_a - map_b)).sum () / nr_elem ( where abs is calculated over all the couples of entries). The current implementation can give zero and exit even if the point are really not registered. Furthermore the correct implementation should be calulating the average distance separately and then the abs( averageDist1 - averageDist2).
note : I don't know what Eigen::VectorXf::MAp does but taking the nr_elem from the distances (where nr_elem is the minimum number of points and hence excluding some points arbitrarily) sounds bad.
please could someone in the developers team have a look to the FitnessScore ?
In the previous post I suspected it was wrong but there was no answer.
Or.. the ticket opened covered both the reports ?