Hi all,
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 LevembergMarquardt ICP an implementation of Fitzgibbon's 2001 paper? If not, is it possible to have a reference ? Thank you. 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 ICPregister a couple of frames from Kinect which is the expected time ? Thank you, Waltz 
This post has NOT been accepted by the mailing list yet.
This post was updated on .
Don't know if you've already done it, but try to build it in release mode. It should be faster.
I haven't tried to register frames from Kinect, but I'm using point clouds with approx. 400 000 points and it takes 2025 seconds with GICP on a Core2duo 3 GHz. 
Thank you Mike,
My tests are already compiled in release version. By the way if your GICP takes 25 secs for 400K points I suppose that what I obtain is normal. Waltz 
Hi,
1) Anyone knows the meaning of the epsilon parameter used by ICP ? 2) Is there a reference for the LevembergMarquardt implemetation of ICP? Thank you, Waltz 
1) it's a convergence criteria
2) in source code, it's simply replaces the opmization function from SVD through LM with an function pointer 
Regarding point 1) PCL implementation seems wrong.
I see this in the exit test: fabs ((transformation_  previous_transformation_).sum ()) < transformation_epsilon_  ... 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. Please verify if this is a bug. Waltz 
seems so

Regarding point 2)
I do not see the advantage of using the LM method. It is not oneshot 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? Thank you, Waltz 
in "Robust registration of 2D and 3D point sets" of Fitzgibbo it's neither a "oneshot" (see fig. 3)

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. 
In reply to this post by Waltz
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! Michael _______________________________________________ [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pclusers 
CONTENTS DELETED
The author has deleted this message.

Hi, I was looking for the meaning of FitnessScore and I found:
unsigned int nr_elem = std::min (distances_a.size (), distances_b.size ()); Eigen::VectorXf map_a = Eigen::VectorXf::Map (&distances_a[0], nr_elem); Eigen::VectorXf map_b = Eigen::VectorXf::Map (&distances_b[0], nr_elem); return ((map_a  map_b).sum () / nr_elem); 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. Then : 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 someone creates a another ticket for bug. 
CONTENTS DELETED
The author has deleted this message.

it could mean RMS, Hausdroff distance or any other self defined transformation distance

Hi all,
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 ? Thank you, Waltz 
Administrator

Waltz,
I'll look at it later today. Thanks for the heads up. PS. In general, once a ticket is open, it's best to continue the conversation there so that everything is centralized. Thanks. Cheers, Radu. On 04/20/2012 07:18 AM, Waltz wrote: > Hi all, > > 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 ? > Thank you, > > Waltz > >  > View this message in context: http://www.pclusers.org/ICPseemstooslowsomequestionstp3868061p3926161.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pclusers [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pclusers 
Administrator

In reply to this post by Waltz
Waltz,
It took way longer than expected, as no one bumped the issue on the tracker and we all forgot about it. I just pushed these fixes in trunk (r5980) right in time for 1.6. Thanks for finding the bug! Cheers, Radu. On 04/20/2012 07:18 AM, Waltz wrote: > Hi all, > > 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 ? > Thank you, > > Waltz > >  > View this message in context: http://www.pclusers.org/ICPseemstooslowsomequestionstp3868061p3926161.html > Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pclusers > _______________________________________________ [hidden email] / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pclusers 
Free forum by Nabble  Edit this page 