The FPFH example produces results, which are off the expected results by almost 100%.
Though there are ~2000 descriptors for each of the pointclouds, only 3 correspondences were found
by the matcher (which seems to be the actual problem here on first glance).
Have you run the unit tests?
[x] Yes
[] No --- then this issue will be closed.
Installed Dependencies
Please report the versions of all dependencies you installed, as well as your OS.
OS: Ubuntu 20.04 LTS
Dependencies:
Eigen3 and Boost installed as instructed
PCL install via the ROS distributation for Ubuntu 20.04 LTS
To Reproduce
Please post the exact steps you executed to reproduce the bug.
I build and executed the teaser_cpp_fpfh example as described in the documentation.
Additional context
Some background to my question:
I am currently investigating loop closure's in a graph based SLAM and need to do a scan-matching between two laserscans.
I want to use teaser-plusplus to produce a good initial estimate between the scans and apply a post-registration with ICP afterwards, as suggested.
To get an initial hang of it, i took a look at the teaser_cpp_fpfh example, which this question is all about:
When building and executing the example, i get the following output for the registration result:
(notice i added a method to make the expected and estimated transform more human readable):
Number of correspondences: 1889
Number of outliers: 1700
Time taken (s): 0.00
As you can clearly see, teaser-plusplus does not even converge in the given example, but terminates early on, because
GNC-TLS terminated because maximum residual at initialization is very small..
I am not sure if this is expected behavior, but the algorithm still proceeds to calculate the final transformation,
which is also completely false (The cloud gets rotated by an average of 3 degrees and the resulting error in the rotation is also almost at 3 degrees - so there is an error of almost 100%).
I am pretty sure, that this is not the expected behavior for this test case and might need some looking into.
If i am completely wrong, please enlighten me! :)
Edit:
I just realized, that the number of correspondences displayed by the output of the algorithm (1889) is not actually the number of correspondences, but the size of the input cloud smile
The actual number of correspondences found by the algorithm is 3 open_mouth
With the actual number of correspondences i mean the the output of the matcher.calculateCorrespondences() function which gets src and target cloud and its respective descriptors as it's input.
Describe the bug
The FPFH example produces results, which are off the expected results by almost 100%. Though there are ~2000 descriptors for each of the pointclouds, only 3 correspondences were found by the matcher (which seems to be the actual problem here on first glance).
Have you run the unit tests?
Installed Dependencies Please report the versions of all dependencies you installed, as well as your OS.
OS: Ubuntu 20.04 LTS Dependencies: Eigen3 and Boost installed as instructed PCL install via the ROS distributation for Ubuntu 20.04 LTS
To Reproduce Please post the exact steps you executed to reproduce the bug.
I build and executed the teaser_cpp_fpfh example as described in the documentation.
Additional context
Some background to my question: I am currently investigating loop closure's in a graph based SLAM and need to do a scan-matching between two laserscans. I want to use teaser-plusplus to produce a good initial estimate between the scans and apply a post-registration with ICP afterwards, as suggested.
To get an initial hang of it, i took a look at the teaser_cpp_fpfh example, which this question is all about: When building and executing the example, i get the following output for the registration result: (notice i added a method to make the expected and estimated transform more human readable):
TEASER++ Results
Expected rotation: 0.996927 0.0668736 -0.0406664 -0.066129 0.997618 0.0194009 0.0418676 -0.0166518 0.998978 Pos: -0.12 | -0.04 | 0.11 Angles: 3.12 | -3.10 | 3.07 Estimated rotation: 0.76 -0.08 -0.64 0.28 -0.86 0.44 -0.59 -0.51 -0.63 Error (deg): 2.62 Pos: -0.10 | 0.11 | 0.14 Angles: 0.61 | -2.44 | -3.04
Expected translation: -0.12 -0.04 0.11 Estimated translation: -0.10 0.11 0.14 Error (m): 0.15
Number of correspondences: 1889 Number of outliers: 1700 Time taken (s): 0.00
As you can clearly see, teaser-plusplus does not even converge in the given example, but terminates early on, because GNC-TLS terminated because maximum residual at initialization is very small.. I am not sure if this is expected behavior, but the algorithm still proceeds to calculate the final transformation, which is also completely false (The cloud gets rotated by an average of 3 degrees and the resulting error in the rotation is also almost at 3 degrees - so there is an error of almost 100%). I am pretty sure, that this is not the expected behavior for this test case and might need some looking into. If i am completely wrong, please enlighten me! :)
Edit: I just realized, that the number of correspondences displayed by the output of the algorithm (1889) is not actually the number of correspondences, but the size of the input cloud smile The actual number of correspondences found by the algorithm is 3 open_mouth With the actual number of correspondences i mean the the output of the matcher.calculateCorrespondences() function which gets src and target cloud and its respective descriptors as it's input.
Cheers